AES

AES, 高级加密规范, 是采纳区块加密的一种规范, 又称Rijndael加密法. 严格上来讲, AES和Rijndael又不是齐全一样, AES的区块长度固定为128比特, 秘钥长度能够是128, 192或者256. Rijndael加密法能够反对更大范畴的区块和密钥长度, Rijndael应用的密钥和区块长度均能够是128，192或256比特. AES是对称加密最风行的算法之一.

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

加密模式 - ECB, CBC

当然了分组明码的加密模式不仅仅是ECB和CBC这两种, 其余的咱们暂不波及.

下面说的AES是一种区块加密的规范, 那加密模式其实能够了解为解决不同区块的形式和分割.

ECB

ECB能够看做最简略的模式, 须要加密的数据依照区块的大小分为N个块, 并对每个块独立的进行加密

此种办法的毛病在于同样的明文块会被加密成雷同的密文块, 因而, 在某些场合, 这种办法不能提供严格的数据保密性. 通过上面图示例子大家就很容易明确了

CBC

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

CBC是最罕用的模式. 他的毛病是加密过程只能是串行的, 无奈并行, 因为每个块的加密要依赖到前一个块的加密后果, 同时在加密的时候明文中的轻微扭转, 会导致前面所有的密文块都发生变化. 但此种模式也是有长处的, 在解密的过程中, 每个块的解密依赖上一个块的加密后果, 所以咱们要解密一个块的时候, 只须要把他后面一个块也一起读取, 就能够实现本块的解密, 所以这个过程是能够并行操作的.

填充模式

AES加密每个块blockSize是128比特, 那如果咱们要加密的数据不是128比特的倍数, 就会存在最初一个分块有余128比特, 那这个块怎么解决, 就用到了填充模式. 上面是罕用的填充模式.

PKCS7 / PKCS5

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

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

咱们以AES(128)为例, 数据块长度为128比特, 16字节, 应用PKCS7填充时, 填充长度为1-16. 留神, 当加密长度是16整数倍时, 反而填充长度是最大的, 要填充16字节. 起因是 "PKCS7" 拆包时会按协定取最初一个字节所表征的数值长度作为数据填充长度, 如果因实在数据长度恰好为16的整数倍而不进行填充, 则拆包时会导致实在数据失落.

举一个blockSize为8字节的例子

| DD DD DD DD DD DD DD DD | DD DD DD DD 04 04 04 04 |

第二个块中有余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最好是再向后读取16个字节.

参考

感激浏览

参考资料

https://zh.wikipedia.org/zh-c...
https://segmentfault.com/a/11...
https://ithelp.ithome.com.tw/...