如何确保明文和密文的长度是一致的

  做过加密的人都应该有“加密之后文件会变大”的经验。变大就变大吧，对于日常使用和APP开发或者服务端开发而言，大个几k字节是无所谓的，但是如果是使用RF（射频）通信，那么大几个字节就会导免费云主机域名致通信失败率的增加，所以对于这样的场景，你就需要确保密文和明文一样长，最好是还能短一点。
  由于短一点是压缩算法的功劳，和加密算法本身没有关系，我们这里不做分析，今天我们以openssl的命令行工具为例来学习如何确保密文长度等于明文长度。  为啥加密之后就会边长呢？为了更安全！那么为了更安全长到哪里了？
    1. 长在填充；
    2. 长在salt；
  填充主要是为了解决分组加密，明文长度不是分组的整数倍的问题，为了简化填充规则，如果明文是分组的倍数，就填充一个整的分组。

上图就是一个明文是128bits的aes-128-cbc的加密样例，填充了整整一个128bits的填充块。
  salt是作为秘钥和IV生成的一个随机因子，为了解决相同的明文和秘钥生成相同的密文的问题，由于salt必须参与到运算中，所以salt通常是以明文的形式拼接在明文的最前面，salt通常是16个字节的长度，前8字节是个固定的magic数，后8个字节是随机数，这样有salt的密文至少会增加一个长度是16个字节的明文头部信息。

上图就是一个有salt的，明文是一个字节的密文是16+1个字节的样例输出。  既然增长是由于填充和salt导致的，那么要保证一样长，那就需要去掉填充和salt，当然去掉填充的前提需要明文的长度是分组的倍数，要不然加密会报错的。

上图是一个nopad和nosalt的截图，我们在看一个对比图，如下：
  -a在参数在openssl里面是对加密或者解密结果的base64的处理，如果是加密就是base64编码，反之是解码。base64会把没3个字节编码为4个字节的科输入字符，如果不小心用到这个选项，你会发现密文长度填充了不少。
  重要的事情说三遍，用了-a会变长！用了-a会变长！用了-a会变长！  使用openssl做AES的加密
  使用openssl做SSL/TLS/HTTPS的实验

相关推荐: linux软件源指的是什么

本文小编为大家详细介绍“linux软件源指的是什么”，内容详细，步骤清晰，细节处理妥当，希望这篇“linux软件源指的是什么”文章能帮助大家解决疑惑，下面跟着小编的思路慢慢深入，一起来学习新知识吧。 在linux中，软件源是指linux系统在线安装的软件包的来…