??做過加密的人都應該有“加密之后文件會變大”的經(jīng)驗。變大就變大吧，對于日常使用和APP開發(fā)或者服務端開發(fā)而言，大個幾k字節(jié)是無所謂的，但是如果是使用RF（射頻）通信，那么大幾個字節(jié)就會導致通信失敗率的增加，所以對于這樣的場景，你就需要確保密文和明文一樣長，最好是還能短一點。
?由于短一點是壓縮算法的功勞，和加密算法本身沒有關系，我們這里不做分析，今天我們以openssl的命令行工具為例來學習如何確保密文長度等于明文長度。
成都創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務，包含不限于成都做網(wǎng)站、網(wǎng)站設計、隆堯網(wǎng)絡推廣、微信平臺小程序開發(fā)、隆堯網(wǎng)絡營銷、隆堯企業(yè)策劃、隆堯品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；成都創(chuàng)新互聯(lián)為所有大學生創(chuàng)業(yè)者提供隆堯建站搭建服務，24小時服務熱線：18982081108，官方網(wǎng)址：www.cdcxhl.com
??為啥加密之后就會邊長呢？為了更安全！那么為了更安全長到哪里了？
???1. 長在填充；
???2. 長在salt；
?填充主要是為了解決分組加密，明文長度不是分組的整數(shù)倍的問題，為了簡化填充規(guī)則，如果明文是分組的倍數(shù)，就填充一個整的分組。
上圖就是一個明文是128bits的aes-128-cbc的加密樣例，填充了整整一個128bits的填充塊。
?salt是作為秘鑰和IV生成的一個隨機因子，為了解決相同的明文和秘鑰生成相同的密文的問題，由于salt必須參與到運算中，所以salt通常是以明文的形式拼接在明文的最前面，salt通常是16個字節(jié)的長度，前8字節(jié)是個固定的magic數(shù)，后8個字節(jié)是隨機數(shù)，這樣有salt的密文至少會增加一個長度是16個字節(jié)的明文頭部信息。
上圖就是一個有salt的，明文是一個字節(jié)的密文是16+1個字節(jié)的樣例輸出。
??既然增長是由于填充和salt導致的，那么要保證一樣長，那就需要去掉填充和salt，當然去掉填充的前提需要明文的長度是分組的倍數(shù)，要不然加密會報錯的。
上圖是一個nopad和nosalt的截圖，我們在看一個對比圖，如下：
??-a在參數(shù)在openssl里面是對加密或者解密結(jié)果的base64的處理，如果是加密就是base64編碼，反之是解碼。base64會把沒3個字節(jié)編碼為4個字節(jié)的科輸入字符，如果不小心用到這個選項，你會發(fā)現(xiàn)密文長度填充了不少。
?重要的事情說三遍，用了-a會變長！用了-a會變長！用了-a會變長！
使用openssl做AES的加密
使用openssl做SSL/TLS/HTTPS的實驗
重慶分公司
重慶分公司
