從nodejs的AES加密解密之后文件大小不一致的問題談談AES加密中的補位


一、AES補位知識

  針對 AES 加密的實現過程,一般都會用到補位。AES 加密的原數據長度要求是 16 的整數倍,但實際操作過程中並不能保證每次待加密的數據長度都能是 16 的整數倍,所以這時候就需要進行補位,再進行加密才能得到正確的加密數據。

  常用的補位方式主要:NoPadding,zeroPadding,PKCS5Padding,PKCS7Padding四種方式。其中PKCS5Padding和PKCS7Padding使用起來一樣。

  NoPadding:不進行補位操作,保持源數據。

  zeroPadding:末尾補0操作。對於源數據長度不是16的整數倍時,在末尾補0至長度為16的整數倍;

  另外一種情況是源數據長度正好是16的整數倍時,需要在數據末尾補16個0。(需注意!!!!!)

  PKCS5Padding :對於源數據長度不是 16 的整數倍時,在末尾補(16 - src_len % 16) 至長度為16的整數倍;比如差3為16的整數倍,那么就部3個3。

  另外一種情況是源數據長度正好是16的整數倍時,需要在數據末尾補16個16。(需注意!!!!!)

  PKCS7Padding:  與PKCS5Padding使用相同。

二、問題描述:

  之前做大文件的分片AES加密解密,發現office文件,每次打開都會報文件損壞的提示,然后查看原文件和解密后的文件發現兩個文件大小不一致。文件的md5值不一樣。所以猜測文件是有了變化。

  試了很多種方式,比如IV的偏移向量等,發現還是不行,后來看到有個padding(補位)沒用到,所以猜測通過上面的AES補位分析,發現就是因為不滿 16 的倍數時,補了相應字節的原因。

三、解決方案:

  並且后來還發現,比如:

  1、文件為一個分片,文件字節少8成為16的倍數,那么加密之后形成的文件就補位了8個8;然后編輯發現文件最后多了8個BS字符(ASCII碼表看下方)

  2、文件為多個分片,比如3個分片,最后一個分片少9成為16倍數,那么加密之后文件就多了 2*16 + 9 = 41個字節

  了解了補位規則所以處理就簡單了,在解密之后獲取 buffer 最后一個字節的值,比如16-16-9,那么每次分片解密之后,把最后補位的那些16-16-9字節先刪掉之后,再合並成新文件即可。

  親測完美完成,並且加密解密之后文件md5值一樣,所以有效。

  ASCII碼一覽表,ASCII碼對照表:http://c.biancheng.net/c/ascii/


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM