如何確保明文和密文的長度是一致的

加密之后會變大的問題

??做過加密的人都應該有“加密之后文件會變大”的經(jīng)驗。變大就變大吧，對于日常使用和APP開發(fā)或者服務端開發(fā)而言，大個幾k字節(jié)是無所謂的，但是如果是使用RF（射頻）通信，那么大幾個字節(jié)就會導致通信失敗率的增加，所以對于這樣的場景，你就需要確保密文和明文一樣長，最好是還能短一點。
??由于短一點是壓縮算法的功勞，和加密算法本身沒有關系，我們這里不做分析，今天我們以openssl的命令行工具為例來學習如何確保密文長度等于明文長度。

為啥密文會比明文長

??為啥加密之后就會邊長呢？為了更安全！那么為了更安全長到哪里了？
????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ù)

??-a在參數(shù)在openssl里面是對加密或者解密結(jié)果的base64的處理，如果是加密就是base64編碼，反之是解碼。base64會把沒3個字節(jié)編碼為4個字節(jié)的科輸入字符，如果不小心用到這個選項，你會發(fā)現(xiàn)密文長度填充了不少。
??重要的事情說三遍，用了-a會變長！用了-a會變長！用了-a會變長！

進一步的學習資料推薦

  使用openssl做AES的加密
  使用openssl做SSL/TLS/HTTPS的實驗