如何使用CryptoJS的AES方法进行加密和解密

首先准备一份明文和秘钥：

var plaintText = 'aaaaaaaaaaaaaaaa'// 明文

var keyStr = 'bbbbbbbbbbbbbbbb'// 一般key为一个字符串

参看官网文档，AES方法是支持AES-128、AES-192和AES-256的，加密过程中使用哪种加密方式取决于传入key的类型，否则就会按照AES-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.

由于Java就是按照128bit给的，但是由于是一个字符串，需要先在前端将其转为128bit的才行。

最开始以为使用CryptoJS.enc.Hex.parse就可以正确地将其转为128bit的key。但是不然...

经过多次尝试，需要使用CryptoJS.enc.Utf8.parse方法才可以将key转为128bit的。好吧，既然说了是多次尝试，那么就不知道原因了，后期再对其进行更深入的研究。

// 字符串类型的key用之前需要用uft8先parse一下才能用

var key = CryptoJS.enc.Utf8.parse(keyStr)

由于后端使用的是PKCS5Padding，但是在使用CryptoJS的时候发现根本没有这个偏移，查询后发现PKCS5Padding和PKCS7Padding是一样的东东，使用时默认就是按照PKCS7Padding进行偏移的。

// 加密

var encryptedData = CryptoJS.AES.encrypt(plaintText, key, {

mode: CryptoJS.mode.ECB,

padding: CryptoJS.pad.Pkcs7

})

由于CryptoJS生成的密文是一个对象，如果直接将其转为字符串是一个Base64编码过的，在encryptedData.ciphertext上的属性转为字符串才是后端需要的格式。

var encryptedBase64Str = encryptedData.toString()

// 输出：'RJcecVhTqCHHnlibzTypzuDvG8kjWC+ot8JuxWVdLgY=

console.log(encryptedBase64Str)

// 需要读取encryptedData上的ciphertext.toString()才能拿到跟Java一样的密文

var encryptedStr = encryptedData.ciphertext.toString()

// 输出：'44971e715853a821c79e589bcd3ca9cee0ef1bc923582fa8b7c26ec5655d2e06

console.log(encryptedStr)

由于加密后的密文为128位的字符串，那么解密时，需要将其转为Base64编码的格式。

那么就需要先使用方法CryptoJS.enc.Hex.parse转为十六进制，再使用CryptoJS.enc.Base64.stringify将其变为Base64编码的字符串，此时才可以传入CryptoJS.AES.decrypt方法中对其进行解密。

// 拿到字符串类型的密文需要先将其用Hex方法parse一下

var encryptedHexStr = CryptoJS.enc.Hex.parse(encryptedStr)

// 将密文转为Base64的字符串

// 只有Base64类型的字符串密文才能对其进行解密

var encryptedBase64Str = CryptoJS.enc.Base64.stringify(encryptedHexStr)

使用转为Base64编码后的字符串即可传入CryptoJS.AES.decrypt方法中进行解密 *** 作。

// 解密

var decryptedData = CryptoJS.AES.decrypt(encryptedBase64Str, key, {

mode: CryptoJS.mode.ECB,

padding: CryptoJS.pad.Pkcs7

})

经过CryptoJS解密后，依然是一个对象，将其变成明文就需要按照Utf8格式转为字符串。

// 解密后，需要按照Utf8的方式将明文转位字符串

var decryptedStr = decryptedData.toString(CryptoJS.enc.Utf8)

console.log(decryptedStr)// 'aaaaaaaaaaaaaaaa'

AES, 高级加密标准, 是采用区块加密的一种标准, 又称Rijndael加密法. 严格上来讲, AES和Rijndael又不是完全一样, AES的区块长度固定为128比特, 秘钥长度可以是128, 192或者256. Rijndael加密法可以支持更大范围的区块和密钥长度, Rijndael使用的密钥和区块长度均可以是128，192或256比特. AES是对称加密最流行的算法之一.

我们不去讨论具体的AES的实现, 因为其中要运用到大量的高等数学知识, 单纯的了解AES流程其实也没什么意义(没有数学基础难以理解), 所以我们今天着重来总结一些使用过程中的小点.

当然了分组密码的加密模式不仅仅是ECB和CBC这两种, 其他的我们暂不涉及.

上面说的AES是一种区块加密的标准, 那加密模式其实可以理解为处理不同区块的方式和联系.

ECB可以看做最简单的模式, 需要加密的数据按照区块的大小分为N个块, 并对每个块独立的进行加密

此种方法的缺点在于同样的明文块会被加密成相同的密文块, 因此, 在某些场合, 这种方法不能提供严格的数据保密性. 通过下面图示例子大家就很容易明白了

我们的项目中使用的就是这种模式, 在CBC模式中, 每个明文块与前一个块的加密结果进行异或后, 在进行加密, 所以每个块的加密都依赖前面块的加密结果的, 同时为了保证第一个块的加密, 在第一个块中需要引入初始化向量iv.

CBC是最常用的模式. 他的缺点是加密过程只能是串行的, 无法并行, 因为每个块的加密要依赖到前一个块的加密结果, 同时在加密的时候明文中的细微改变, 会导致后面所有的密文块都发生变化. 但此种模式也是有优点的, 在解密的过程中, 每个块的解密依赖上一个块的加密结果, 所以我们要解密一个块的时候, 只需要把他前面一个块也一起读取, 就可以完成本块的解密, 所以这个过程是可以并行 *** 作的.

AES加密每个块blockSize是128比特, 那如果我们要加密的数据不是128比特的倍数, 就会存在最后一个分块不足128比特, 那这个块怎么处理, 就用到了填充模式. 下面是常用的填充模式.

PKCS7可用于填充的块大小为1-255比特, 填充方式也很容易理解, 使用需填充长度的数值paddingSize 所表示的ASCII码 paddingChar = chr(paddingSize)对数据进行冗余填充. (后面有解释)

PKCS5只能用来填充8字节的块

我们以AES(128)为例, 数据块长度为128比特, 16字节, 使用PKCS7填充时, 填充长度为1-16. 注意, 当加密长度是16整数倍时, 反而填充长度是最大的, 要填充16字节. 原因是 "PKCS7" 拆包时会按协议取最后一个字节所表征的数值长度作为数据填充长度, 如果因真实数据长度恰好为16的整数倍而不进行填充, 则拆包时会导致真实数据丢失.

举一个blockSize为8字节的例子

第二个块中不足8字节, 差4个字节, 所以用4个4来填充

严格来讲 PKCS5不能用于AES, 因为AES最小是128比特(16字节), 只有在使用DES此类blockSize为64比特算法时, 考虑使用PKCS5

我们的项目最开始加解密库使用了CryptoSwift, 后来发现有性能问题, 就改为使用IDZSwiftCommonCrypto.

这里咱们结合项目中边下边播边解密来提一个点, 具体的可以参考之前写的 边下边播的总结 . 因为播放器支持拖动, 所以我们在拖拽到一个点, 去网络拉取对应数据时, 应做好range的修正, 一般我们都会以range的start和end为基准, 向前后找到包含这个range的所有块范围. 打比方说我们需要的range时10-20, 这是我们应该修正range为0-31, 因为起点10在0-15中, 20 在16-31中. 这是常规的range修正.(第一步 找16倍数点).

但是在实际中, 我们请求一段数据时, 还涉及到解密器的初始化问题, 如果我们是请求的0-31的数据, 因为是从0开始, 所以我们的解密器只需要用key和初始的iv来进行初始化, 那如果经过了第一步的基本range修正后, 我们请求的数据不是从0开始, 那我们则还需要继续往前读取16个字节的数据, 举个例子, 经过第一步修正后的range为16-31, 那我们应该再往前读取16字节, 应该是要0-31 这32个字节数据, 拿到数据后,使用前16个字节(上一个块的密文)当做iv来初始化解密器.

还有一个要注意的点是, 数据解密的过程中, 还有可能会吞掉后面16个字节的数据, 我暂时没看源码, 不知道具体因为什么, 所以保险起见, 我们的range最好是再向后读取6个字节.

感谢阅读

参考资料

https://zh.wikipedia.org/zh-cn/%E9%AB%98%E7%BA%A7%E5%8A%A0%E5%AF%86%E6%A0%87%E5%87%86

https://segmentfault.com/a/1190000019793040

https://ithelp.ithome.com.tw/articles/10250386

---