一、AES 加密報錯：java.security.InvalidAlgorithmParameterException: ECB mode cannot use IV
1、問題背景
AES 加解密需使用的 算法（參數 - 算法名稱/加密模式/數據填充方式），之前我使用的 "AES/EBC/PKCS5Padding" 時，如果采用 偏移向量 會報錯：java.security.InvalidAlgorithmParameterException: ECB mode cannot use IV
原因是 EBC 模式無需 IV，上述報錯的字面意思也很好理解
2、解決方式：
EBC 模式改為 CBC 模式即可（具體如下描述）
二、AES 加密，ECB模式無需IV，pkcs5padding和zeropadding兩種填充方式
1、AES-EBC模式，加密時，如果明文不足16的倍數， 會填充為16的倍數（這里假設填充0），此時分組加密后，得到的密文也是16的倍數。解密時，同樣的分組解密，也就是說，解密后的明文同樣是16的倍數。請問它是如何計算出正確的明文長度的？
舉例：明文：[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14] 15位字節，密文：[x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x] 16位，按照分組解密后，應該是16字節， 他是如何將填充物去掉，得到真正明文15字節的？ 求解惑
2、填充規則 - 重點了解
如果原始數據是N字節的整數倍，則添加一個值為N的額外字節塊。這是必要的，這樣解譯算法就可以確定最后一個塊的最后一個字節是一個pad字節，表示添加的填充字節的數量還是明文消息的一部分。
考慮一個明文消息，它是N字節的整數倍，明文的最后一個字節是01。由於沒有其他信息，解密算法將無法確定最后一個字節是明文字節還是pad字節。
但是，通過在01明文字節之后為每個值N增加N個字節，解譯算法始終可以將最后一個字節視為補碼字節，並從密文的末尾去掉適當數目的補碼字節;
所述要根據最后一個字節的值剝離的字節數
例如{1,2,3,4,5,6,7,8,9}，總共9個數值，取余16后是9，需要補充7個7，則最后數據變為{1,2,3,4,5,6,7,8,9,7,7,7,7,7,7,7}
需要特別注意一種情況：如果數據的個數剛好是16的倍數，那就要在補充16個字節（一定要）。例如{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}，填充后的數據是{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,16,16,16,16,16，16,16,16,16,16,16,16,16,16,16,16}，始終能通過最后一個字節判斷出來 添加了幾位填充物。
三、AES 加密算法中，ECB和CBC模式有什么區別
1、ECB模式 - 電子密本方式：
ECB 其實非常簡單，就是將數據按照8個字節一段進行加密或解密得到一段段的8個字節的密文或者明文，最后一段不足8個字節（一般補0或者F），按照需求補足8個字節進行計算（並行計算），之后按照順序將計算所得的數據連在一起即可，各段數據之間互不影響。
其優點：簡單；有利於並行計算；誤差不會被傳遞；
缺點：不能隱藏明文的模式；可能對明文進行主動攻擊；
2、CBC 模式 - 密文分組鏈接方式 - 安全性更好
其優點：不容易主動攻擊，安全性好於ECB，是SSL、IPSec的標准；
缺點：不利於並行計算；誤差傳遞；需要初始化向量IV；
3、CBC（密文分組鏈接方式）有點麻煩，它的實現機制使加密的各段數據之間有了聯系。其實現的機理、加密步驟如下：
首先將數據按照8個字節一組進行分組得到D1、D2…Dn（若數據不是8的整數倍，用指定的PADDING數據補位）
第一組數據D1與初始化向量 IV 異或后的結果進行DES加密得到第一組密文C1（初始化向量IV為全零）
第二組數據D2與第一組的加密結果C1異或以后的結果進行DES加密，得到第二組密文C2
之后的數據以此類推，得到Cn
按順序連為C1C2C3…Cn即為加密結果。