AES前端加密解密傳輸對接失敗的可能原因，使用crypto-js

AES加密解密

使用的是crypto-js進行加密解密。引入方式github上有講解：
https://github.com/brix/crypto-js
文檔地址見： https://cryptojs.gitbook.io/docs/
在前後臺對接中或不同語言對接中需要弄明白的幾點有：

1.首先是密鑰的正確性，以及密鑰決定了數據塊的位數

庫中默認的數據塊是256

CryptoJS supports AES-128, AES-192, and AES-256. It will pick the variant by the size of the key you pass in. If you use a passphrase, then it will generate a 256-bit key.
庫內支持128位 192位 256位的加解密，這取決於你傳入的key（密鑰）的種類，如果你用的是一個密鑰，那麼它將生成256位的key

如果是與java通信，可能需要前臺將密鑰轉爲128位的key

   // 可以讓數據塊爲128位
   key = CryptoJS.enc.Utf8.parse(key);

2.對於這個庫的AES有兩種輸出形式編碼，Hex和Base64。相應的輸入內容進行解密時也有兩種編碼形式。

當輸入Hex的密文進行解密時，如果之前加密的明文數據長度不是8的整數倍就會報錯Malformed UTF-8 data，此時可以將Hex編碼的密文轉爲base64再進行解密，或者使用官方提供的解碼器
如使用官方的解碼工具：

 // secret是等待進行解密的Hex編碼密文
 // Json返回的內容未做長度爲8的整數倍限制，Hex直接解密報錯，CryptoJS.lib.CipherParams
secretText = CryptoJS.lib.CipherParams.create({'ciphertext': CryptoJS.enc.Hex.parse(secret)});

// 轉爲base64來進行解密, 如果需要得到明文，還需要對現有return結果進行toString()
secretText  = CryptoJS.enc.Hex.parse(secret),
secretText = CryptoJS.enc.Base64.stringify(secretText);

如果輸出Base64密文傳輸給後臺，要對特殊的符號進行處理，比如+ 換爲%2b 不然傳輸後後臺拿到的可能是空，後臺拿到密文後再對轉義後的符號換回原符號再進行解密。

3.AES的算法可以設置模式mode和填充padding，與其他平臺對接時需要確保是一致的填充和模式。如果設置了偏移iv也要一致。

官網文檔給出的支持的模式和填充有：
CryptoJS supports the following modes:

1. 密碼分組鏈模式（CBC）(the default)：對於每個待加密的密碼塊在加密前會先與前一個密碼塊的密文異或然後再用加密器加密。第一個明文塊與一個叫初始化向量的數據塊異或。
2. 密文反饋模式 （CFB）： CFB能夠將塊密文（Block Cipher）轉換爲流密文（Stream Cipher）
3. 計數器模式（CTR）：完全的流模式。將瞬時值與計數器連接起來，然後對此進行加密產生密鑰流的一個密鑰塊，再進行XOR操作
4. 輸出反饋模式（OFB）：密碼算法的輸出（指密碼key而不是密文）會反饋到密碼算法的輸入中，通過將明文分組和密碼算法的輸出進行XOR來產生密文分組。
5. 電碼本模式（ECB） ： 將整個明文分成若干段相同的小段，然後對每一小段進行加密。

And CryptoJS supports the following padding schemes:

1. Pkcs7 (the default)
2. Iso97971
3. AnsiX923
4. Iso10126
5. ZeroPadding
6. NoPadding

而填充：拿ECB模式舉例：加密時，如果明文不足16的倍數， 會填充爲16的倍數。

// padding填充採用默認的Pkcs7 (the default) crypto 的mode默認：CBC (the default)
var decrypted = CryptoJS.AES.decrypt(secretText, key, {
     iv: '', // 設置偏移量
     mode: CryptoJS.mode.ECB, // 設置模式
     padding: CryptoJS.pad.AnsiX923 // 設置填充
 });