做过加密的人都应该有“加密之后文件会变大”的经验。变大就变大吧，对于日常使用和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的实验
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
