AES的加密模式总结

date

May 7, 2020

slug

2020-05-07-AES-encryption-algo

status

Published

分组密码 vs 流密码

总的来讲，我们所使用的密码算法可以分为分组密码算法和流密码算法两种。

分组密码：加密算法执行一次只能对一段固定长度的明文进行加密，得到一段固定长度的密文。

这一段固定长度的明文就是一个分组（Block），而这个明文的长度就是分组长度。

分组密码算法的分组长度、密钥长度、以及密文长度不一定是一样的；例如AES128的分组长度为128bit，可以使用128/192/256bit的密钥，一次可以加密16字节的明文，生成16字节的密文；

流密码：对数据流进行连续处理的密码算法。

流密码中一般以1bit、8bit或者32bit为单位进行加密和解密；

比较典型的流加密算法是RC4，之前一度应用在WiFi的WEP、WPA1加密认证算法甚至TLS实现中，但在应用中已经发现该算法存在多处严重漏洞，因此RFC7465已经禁止在TLS中使用RC4；

在目前各个领域中所广泛使用的对称密码算法（例如DES，3DES，AES等）大部分都是分组密码算法，而所有的非对称加密算法的内部都使用分组密码进行加解密。

分组加密算法的加密模式定义与分类

加密模式的定义：

分组加密算法一次只能对固定长度的明文进行加密，因此如果要加密的明文长度超过分组长度，就需要把待加密的明文按照分组长度进行分段，如何对一个长的明文的多个分段进行加密操作，就称为这个加密算法的加密模式。

最直接的办法就是把各个分段独立进行加密，这就是以下所说的ECB模式，加密风险和漏洞很大，在实际应用中不建议使用；

分组密码算法的主要加密模式：

ECB模式；

CBC模式；

CFB模式；

OFB模式；

CTR模式；

ECB模式

ECB：Electronic CodeBook，电子密码本模式；

基本思路：对各个固定长度的明文分组进行独立的加解密。各个分组之间加解密操作无关，因此相同的明文分组会被加密为相同的密文分组，类似于一个巨大的“明文分组-->密文分组”的对照表，因此称之为电子密码本模式。

CBC模式

CBC：Cipher Block Chaining，密文分组链接模式；

在加解密操作的过程中，密文分组像链条一样连接在一起；CBC模式下进行加密操作的时候，会把要加密的明文分组与前一个密文分组进行XOR操作，然后再进行加密；解密的时候则刚好相反，对要解密的密文分组先进行解密操作，然后把解密之后的中间明文与前一个密文分组进行XOR，得到最终解密完成的明文；

初始化向量IV

从以上CBC模式的加解密流程上可以看到，对于每一个Block的加解密的执行而言需要依赖于前一个Block加密所产生的密文；但是对于第一个Block的加解密而言，因为不存在前一个Block密文，这样就需要一个初始化向量（Initialization Vector）来启动第一个Block的加解密，一般简称IV；

一般而言，每次执行加解密操作的时候都会随机产生一个不同的比特序列来作为初始化向量，因此在加解密执行之前首先需要有一个机制来同步两端的IV，确保第一个Block正确的加解密。

使用CBC模式进行加解密操作，如果在解密端一个密文Block的数据损坏或者丢失，会影响到当前Block以及下一个Block的正常解密，后续Block的解密不受影响；

同样的道理，如果解密端没有正确的IV的话，那么会导致第一个Block解密失败，但是后续的Block是可以正确解密的；

确保互联网访问安全的SSL/TLS，使用的加密模式就是CBC模式；

CFB模式

CFB：Cipher FeedBack，密文反馈模式。

具体的执行流程与CBC模式类似，只不过CFB模式每次是对上一个Block的密文进行加密操作然后与下一个Block的明文进行异或。

加密端：对上个Block产生的密文Block，执行对称加密，然后把对称加密运行的结果与当前Block的明文进行XOR运算，即得到当前Block的密文；

解密端：对上一个Block产生的密文内容执行对称加密操作，然后把对称加密运算的结果与当前Block的密文内容进行XOR运算，即得到当前Block的明文；

从以上流程图可以看出，CFB模式很重要的一点就是：对于一个明文Block的加密而言，实际上并没有针对这个Block的明文内容执行对称加密算法的运算（执行对称加密运算的是上一个block的密文分组），但是却存在一个XOR的运算，也就是说实际上这个XOR的操作就充当了对明文分组进行加密的角色。

CFB模式对于初始化向量的要求与CBC模式是一致的，都需要在每次进行加解密运算之前生成一个两端一致的随机比特序列作为初始化向量IV。

因为CFB模式下没有对明文Block进行对称加密运算来进行保护，在解密的时候也只是简单的通过XOR来恢复出来明文Block的内容，因此可以对这种模式实施重放攻击。

攻击者可以连续截获多个连续片段的密文数据，然后把这些连续片段的数据替换/植入到新的通信/数据内容中，这样在解密端除了替换的第一个密文Block会解密失败以外，后续的密文Block都会被正确解密，从而混入到原始的通信/数据中。

对于这种类型的攻击，需要依赖于对整个消息增加完整性认证码MIC来解决问题。

OFB模式

OFB：Output-Feedback，输出反馈模式。

OFB与CFB类似，只不过CFB模式中，对称加密算法的输入是上一个Block的密文；而OFB模式中对称加密算法的输入是该算法上次运算的输出结果。

加密端：从初始化向量IV开始，使用IV作为对称加密算法的输入执行对称加密运算，然后把对称加密运算的结果（该运算结果同时作为下个Block加密操作中对称加密算法的输入）与待加密的Block明文进行XOR运算得到密文Block；

解密端：从初始化向量IV开始，使用IV作为对称加密算法的输入执行对称加密运算，然后把对称加密运算的结果（该运算结果同时作为下个Block解密操作中对称加密算法的输入）与待解密的Block密文进行XOR运算得到明文Block；

OFB模式对于初始化向量的要求，与CBC、CFB模式一致，一般都需要在每次执行加解密操作时生成一个不同的随机序列作为初始化向量。

OFB模式的执行速度非常快。

从以上OFB模式执行加解密的流程图上可以看出，在加解密执行的过程中，XOR操作的执行速度是非常快的，而执行XOR操作所需要的密钥流（也就是对称加密算法连续多次执行的运算结果）本身与明文密文分组的内容无关，完全可以事先基于密码算法、密钥和初始化向量运算生成，这样在加解密的执行过程中实际上只需要对预先生成的密钥流和明文/密文Block进行XOR操作就可以了，因此其执行速度是非常快的。

OFB模式对于数据的完整性和顺序要求非常严格。

OFB模式的密钥流（也就是对称加密算法连续多次执行的运算结果）有非常强的顺序性，加密操作和解密操作使用的明文和密文Block必须按照顺序一一对应，如果解密端进行解密的密文数据发生顺序错误或者部分数据丢失，将会导致其后的数据解密全部出错；但是如果只是某个密文Block内部的数据发生错误，那么对于这个Block的解密所发生错误只会影响当前Block，不会对下一个Block的解密造成影响；

这一点与CBC、CFB模式形成鲜明对比，后两者如果出现顺序错乱或者部分数据丢失的情况，只会影响当前和下一个Block，不会导致后续所有的Block的解密错误；但如果是某个密文Block内部的数据发生错误，CBC和CFB模式下解密不仅会导致当前Block解密错误，还会引起下个Block也解密错误。

CTR模式

CTR：CounTeR，计数器模式。

与OFB模式类似，区别是：

OFB模式中对称加密算法的输入，来自于该算法上次执行的输出；

而CTR模式中对称加密算法的输入，则来自于一个累积计数器的值。

累积计数器的生成与累积

CTR模式在开始运行之前需要在加解密两端协商一个初始的随机Nonce。这个Nonce包含两个部分：例如前8个字节为固定的随机化Nonce，在此后的运算累积中保持不变，后8个字节则每执行一次运算累加1。通过这种办法可以确保计数器的值每次都不同，然后把这个计数器的值送入对称加密算法中执行加密运算得到的密钥流也各不相同。

Nonce例子：66 1F 98 CD 37 A3 8B 4B 00 00 00 00 00 00 00 01；前8个字节保持不变，后8个字节逐次累积；

计算速度方面，因为CTR模式与OFB模式的计算流程基本一致，因此CTR模式的运算速度也非常快；而且CTR模式用到的nonce和分组序号可以直接计算出来，这样就可以实现并行运算，在支持并行计算的系统中，CTR模式的运算速度比无法支持并行运算的OFB要更胜一筹。

容错性方面，CTR模式与OFB模式基本一致，如果一个Block中的部分数据出错在，只会导致这个Block的数据解码出现错误，不会放大到后续的Block。

参考文档：

《图解密码技术第三版》第四章；