如何确保明文和密文的长度是一致的-创新互联
加密之后会变大的问题
做过加密的人都应该有“加密之后文件会变大”的经验。变大就变大吧,对于日常使用和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的参数
-a在参数在openssl里面是对加密或者解密结果的base64的处理,如果是加密就是base64编码,反之是解码。base64会把没3个字节编码为4个字节的科输入字符,如果不小心用到这个选项,你会发现密文长度填充了不少。
重要的事情说三遍,用了-a会变长!用了-a会变长!用了-a会变长!
进一步的学习资料推荐
使用openssl做AES的加密
使用openssl做SSL/TLS/HTTPS的实验
另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
网页名称:如何确保明文和密文的长度是一致的-创新互联
文章URL:http://pwwzsj.com/article/doegjd.html