如何确保明文和密文的长度是一致的
加密之后会变大的问题
做过加密的人都应该有“加密之后文件会变大”的经验。变大就变大吧,对于日常使用和APP开发或者服务端开发而言,大个几k字节是无所谓的,但是如果是使用RF(射频)通信,那么大几个字节就会导致通信失败率的增加,所以对于这样的场景,你就需要确保密文和明文一样长,最好是还能短一点。
由于短一点是压缩算法的功劳,和加密算法本身没有关系,我们这里不做分析,今天我们以openssl的命令行工具为例来学习如何确保密文长度等于明文长度。
成都创新互联专注为客户提供全方位的互联网综合服务,包含不限于成都做网站、网站设计、隆尧网络推广、微信平台小程序开发、隆尧网络营销、隆尧企业策划、隆尧品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等,从售前售中售后,我们都将竭诚为您服务,您的肯定,是我们最大的嘉奖;成都创新互联为所有大学生创业者提供隆尧建站搭建服务,24小时服务热线:18982081108,官方网址:www.cdcxhl.com
为啥密文会比明文长
为啥加密之后就会边长呢?为了更安全!那么为了更安全长到哪里了?
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的实验
文章标题:如何确保明文和密文的长度是一致的
网站路径:http://myzitong.com/article/jpsosj.html