openssl 應用密碼學

加密之後會變大的問題

  做過加密的人都應該有“加密之後文件會變大”的經驗。變大就變大吧，對於日常使用和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會變長！

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