A. 关于AES加解密中CBC模式的IV初始化向量的安全性问题
前段时间，在研究HLS的AES加密，由于一个地方电视台的HLS流有AES加密，在查看了相关的加解密方案后发现使用的是简单的AES的CBC模式，在CBC的模式下，会设置一个IV，初始化向量。但是我在解密的时候，使用了一个由于理解错误而产生的一个错误IV居然也能解密视频并进行播放，于是就有了这篇张文章。
虽然有五种加密，但是常用的还是CBC，CBC的全称Cipher Block Chaining ，有点类似于区块链哈，我们先来看下加密方式
上面的图片从左往右看，初始化IV只有在第一个块加密的时候才会用到，而第N个块的加密IV则是用的N-1(N>1)个加密后的二进制数组。
CBC的解密则也是从左往右看，但是加密时IV在解密时候，只会用于对第一个块进行解密，其他块的解密则是使用上一块的加密二进制作为IV进行解密操作。
通过上面的分析就能知道，加密的时候，iv会影响所有数据的加密结果，而解密时，iv只会影响第一个加密块的解密结果，其他块的解密可以直接通过分隔加密数据获取正确是N-1块的IV。
这也就印证了为什么ff能播放我用错误的iv解密出来的视频流数据，因为第一块的大小存储大概是id3 的数据，ff直接丢掉id3的数据，直接解码后面的视频数据 ，ff 应该是识别h264编码头开始解码视频。
那么从这点可以看出，在使用了key的情况下，IV对整个数据的保密性没有太大的作用。
再来说说我是怎么发现这个问题，因为错误的IV只会影响第一个块的数据，我在第一次尝试解密后，直接用ff进行播放，ff能够解码并且播放成功，但是相对于其他未加密的HLS流来说，播放我解密后的数据会有3-5s的延时，这让我很是头疼，后来我就通过 ffplay -v trace 打印播放解密的日志，发现视频数据的id3信息丢失了，那么出问题出在第一个块。然后再次研究m3u8加解密IV的赋值方法，后发来经过多次试验，正确赋值IV，解密出来的数据能够及时播放。再后来，就出现了这篇文章的来由。
由此带来的延展，针对iv在CBC模式下的弱用，AES提供了更多的模式可供选择，详细的可以到wiki上了解。
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
B. AES加解密使用总结
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
C. 关于分组密码CBC模式与CTR模式的对比
在对称分组密码体制中 CBC模式（密文分组链接模式） 与 CTR模式（计数器模式） 是安全性最高且举圆最常用的两种模式，在这两种模式中前一分组会以不同的形式影响下一分组的加密过程，因此这两种模式的安全性相对较高。
在项目研发过程中，需求是要在嵌入式节点间实现实时安全通信，而CTR模式能够支持并行加解密过程计算，因而 在项目中选择CTR模式的SM4对称加密算法。
以下对于分组密码中CBC模式以及CTR模式的原理进行简贺毁单介绍：
CBC模式的全称是Cipher Block Chaining模式（密文分组链接模式），之所以叫这个名字，是因为密文分组像链条一样相互连接在一起。首先将明文分组与前一个密文禅答备分组进行XOR运算，然后再进行加密。 注：对于第一个分组需要构造一个长度为分组长度的初始向量IV。
1）能够隐蔽明文的数据模式，相同的明文对应的密文一般是不同的；
2）无法单独对中间的明文分组进行加密。例如，如果要生成密文分组3，必须按序生成密文分组1和密文分组2。
CTR模式全称counter模式（计数器模式）。CTR模式通过对逐次累加的计数器加密来生成密钥分组与明文分组异或产生密文分组。
CTR模式的解密过程将明文分组与密文分组位置调换即可。
从原理图中可以看出：
1）能够隐蔽明文的数据模式，相同的明文对应的密文一般是不同的；
2）CTR模式中可以以任意顺序对分组进行加密和解密，能够以任意顺序处理分组，意味着能够实现并行计算。使用并行计算，CTR模式的加解密是非常快的。
D. AES共有ECB，CBC，CFB，OFB，CTR五种模式分别有什么区别
转：
JCE中AES支持五中模式：CBC，CFB，ECB，OFB，PCBC；支持三种填充：NoPadding，PKCS5Padding，ISO10126Padding。不支持SSL3Padding。不支持“NONE”模式。
其中AES/ECB/NoPadding和我现在使用的AESUtil得出的结果相同(在16的整数倍情况下)。
不带模式和填充来获取AES算法的时候，其默认使用ECB/PKCS5Padding。
算法/模式/填充
16字节加密后数据长度 不满16字节加密后长度
AES/CBC/NoPadding
16
不支持
AES/CBC/PKCS5Padding
32
16
AES/CBC/ISO10126Padding
32
16
AES/CFB/NoPadding
16
原始数据长度
AES/CFB/PKCS5Padding
32
16
AES/CFB/ISO10126Padding
32
16
AES/ECB/NoPadding
16
不支持
AES/ECB/PKCS5Padding
32
16
AES/ECB/ISO10126Padding
32
16
AES/OFB/NoPadding
16
原始数据长度
AES/OFB/PKCS5Padding
32
16
AES/OFB/ISO10126Padding
32
16
AES/PCBC/NoPadding
16
不支持
AES/PCBC/PKCS5Padding
32
16
AES/PCBC/ISO10126Padding
32
16
可以看到，在原始数据长度为16的整数倍时，假如原始数据长度等于16*n，则使用NoPadding时加密后数据长度等于16*n，其它情况下加密数据长度等于16*(n+1)。在不足16的整数倍的情况下，假如原始数据长度等于16*n+m[其中m小于16]，除了NoPadding填充之外的任何方式，加密数据长度都等于16*(n+1)；NoPadding填充情况下，CBC、ECB和PCBC三种模式是不支持的，CFB、OFB两种模式下则加密数据长度等于原始数据长度。
E. 密码技术（四、二）之分组模式（CBC模式）
CBC模式是指将前一个密文分组与当前明文分组的内容混合起来进行加密，这样就可以避免ECB模式的弱点。
CBC模式的全称Cipher Block Chaining 模式（密文分组组链接模式），之所以叫这个名字是因为密文分组是像链条一样相互连接在一起。
在CBC模式中，首先将明文分组与前一个密文分组进行XOR运算，然后再进行加密。
ECB模式 和 CBC模式比较
当加密第一个明文分组是，由于不存在“前一个密文分组”，因此需要事先准备一个长度为一个分组的比特序列来替代“前一个密文分组”，这个比特序列称为 初始化向量 ，通常缩写为IV。每次加密时都会随机产生一个不同的比特序列来作为初始化向量。
明文分组在加密之前一定会与“前一个密文分组”进行XOR运算，因此即便明文分组1和2的值是相等的，密文分组1和2的值也不一定是相等的。这样一来,ECB模式的缺陷在CBC模式中就不存在了。
在CBC模式找那个，我们无法单独对一个中间的明文分组进行加密。例如，如果要生成密文分组3，则至少需要凑齐明文分组1、2、3才行。
假设CBC模式加密的密文分组中有一个分组损坏了。在这种情况下，只要密文分组的长度没有发生编号，则解密时，最多只会影响2个分组受到数据损坏的影响。
假设CBC模式的密文分组中有一些比特缺失了，那么此时即便只缺失了1比特，也会导致密文分组的长度发生变化，此后的分组发生错位，这样一来，缺失比特的位置之后的密文分组也就全部无法解密了。
假设主动攻击者Mallory的目的是通过修改密文来操纵解密后的明文。如果Mallory能够对初始化向量中的任意比特进行反转，则明文分组中相应的比特也会被反转。这是因为在CBC模式的解密过程中，第一个明文分组会和初始化向量进行XOR运算。
这样，Mallory 就可以对初始化向量进行攻击，但是想要对密文分组也进行同样的攻击就非常困难了。
填充提示攻击 （Padding Oracle Attack）是一种利用分组密码中的填充部分来进行攻击的方法。在分组密码中，当明文长度不为分组长度的整数倍时，需要在最后一个分组填充一些数据使其凑满一个分组的长度。在填充提示攻击中，攻击者会反复发送一段密文，每次发送时都对填充的数据进行少许改变。由于接收者在无法正确解密时会返回一个错误消息，攻击者通过这一错误消息就可以获得一部分与明文相关的信息。这一攻击方式并不仅限于CBC模式，而是适用于所有需要进行分组填充的模式。2014年对SSL3.0造成重大影响的POODLE攻击实际上就是一种填充攻击。要防御这种攻击，需要对密文进行认证，确保这段密文的确是由合法的发送者在制定明文内容的前提下生成的。
初始化向量必须使用不可预测的随机数。然后在SSL/TSL1.0的版本协议中，初始向量并没有使用不可预测的随机数，而是使用了上一次CBC模式加密时的最后一个分组。为了防御攻击者对此进行攻击，TSL1.1以上的版本中改为了必须显式得传送初始化向量。
确保互联网安全的通信协议之一SSL/TSL,就是使用CBC模式来确保通信的机密性的，如使用CBC模式三重DES的3DES_EDE_CBC以及CBC模式256比特AES的AES_256_CBC等。
分组密码中海油一种模式叫作CTS模式（Cipher Text Stealing模式）。在分组密码中，当明文长度不能被分组长度整除时，最后一个分组就需要进行填充。CTS模式是使用最后一个分组的其哪一个密文分组数据来讲信息填充的，它通常和ECB模式以及CBC模式配合使用。根据最后一个分组的发送顺序不同，CTS模式有几种不同的变体（CBC-CS1、CBC-CS2、CBC-CS3）。
该系列的主要内容来自《图解密码技术第三版》
我只是知识的搬运工
文章中的插图来源于原着
F. 密码学基础（二）：对称加密
加密和解密使用相同的秘钥称为对称加密。
DES：已经淘汰
3DES：相对于DES有所加强，但是仍然存在较大风险
AES：全新的对称加密算法。
特点决定使用场景，对称加密拥有如下特点：
速度快，可用于频率很高的加密场景。
使用同一个秘钥进行加密和解密。
可选按照128、192、256位为一组的加密方式，加密后的输出值为所选分组位数的倍数。密钥的长度不同，推荐加密轮数也不同，加密强度也更强。
例如：
AES加密结果的长度由原字符串长度决定：一个字符为1byte=4bit，一个字符串为n+1byte，因为最后一位为' '，所以当字符串长度小于等于15时，AES128得到的16进制结果为32位，也就是32 4=128byte，当长度超过15时，就是64位为128 2byte。
因为对称加密速度快的特点，对称加密被广泛运用在各种加密场所中。但是因为其需要传递秘钥，一旦秘钥被截获或者泄露，其加密就会玩完全破解，所以AES一般和RSA一起使用。
因为RSA不用传递秘钥，加密速度慢，所以一般使用RSA加密AES中锁使用的秘钥后，再传递秘钥，保证秘钥的安全。秘钥安全传递成功后，一直使用AES对会话中的信息进行加密，以此来解决AES和RSA的缺点并完美发挥两者的优点，其中相对经典的例子就是HTTPS加密，后文会专门研究。
本文针对ECB模式下的AES算法进行大概讲解，针对每一步的详细算法不再该文讨论范围内。
128位的明文被分成16个字节的明文矩阵，然后将明文矩阵转化成状态矩阵，以“abcdefghijklmnop”的明文为例：
同样的，128位密钥被分成16组的状态矩阵。与明文不同的是，密文会以列为单位，生成最初的4x8x4=128的秘钥，也就是一个组中有4个元素，每个元素由每列中的4个秘钥叠加而成，其中矩阵中的每个秘钥为1个字节也就是8位。
生成初始的w[0]、w[1]、w[2]、w[3]原始密钥之后，通过密钥编排函数，该密钥矩阵被扩展成一个44个组成的序列W[0],W[1], … ,W[43]。该序列的前4个元素W[0],W[1],W[2],W[3]是原始密钥，用于加密运算中的初始密钥加，后面40个字分为10组，每组4个32位的字段组成，总共为128位，分别用于10轮加密运算中的轮密钥加密，如下图所示：
之所以把这一步单独提出来，是因为ECB和CBC模式中主要的区别就在这一步。
ECB模式中，初始秘钥扩展后生成秘钥组后(w0-w43)，明文根据当前轮数取出w[i,i+3]进行加密操作。
CBC模式中，则使用前一轮的密文(明文加密之后的值)和当前的明文进行异或操作之后再进行加密操作。如图所示：
根据不同位数分组，官方推荐的加密轮数：
轮操作加密的第1轮到第9轮的轮函数一样，包括4个操作：字节代换、行位移、列混合和轮密钥加。最后一轮迭代不执行列混合。
当第一组加密完成时，后面的组循环进行加密操作知道所有的组都完成加密操作。
一般会将结果转化成base64位，此时在iOS中应该使用base64编码的方式进行解码操作，而不是UTF-8。
base64是一种编码方式，常用语传输8bit字节码。其编码原理如下所示：
将原数据按照3个字节取为一组，即为3x8=24位
将3x8=24的数据分为4x6=24的数据，也就是分为了4组
将4个组中的数据分别在高位补上2个0，也就成了8x4=32，所以原数据增大了三分之一。
根据base64编码表对数据进行转换，如果要编码的二进制数据不是3的倍数，最后会剩下1个或2个字节怎么办，Base64用x00字节在末尾补足后，再在编码的末尾加上1个或2个=号，表示补了多少字节，解码的时候，会自动去掉。
举个栗子：Man最后的结果就是TWFu。
计算机中所有的数据都是以0和1的二进制来存储，而所有的文字都是通过ascii表转化而来进而显示成对应的语言。但是ascii表中存在许多不可见字符，这些不可见字符在数据传输时，有可能经过不同硬件上各种类型的路由，在转义时容易发生错误，所以规定了64个可见字符（a-z、A-Z、0-9、+、/）,通过base64转码之后，所有的二进制数据都是可见的。
ECB和CBC是两种加密工作模式。其相同点都是在开始轮加密之前，将明文和密文按照128/192/256进行分组。以128位为例，明文和密文都分为16组，每组1个字节为8位。
ECB工作模式中，每一组的明文和密文相互独立，每一组的明文通过对应该组的密文加密后生成密文，不影响其他组。
CBC工作模式中，后一组的明文在加密之前先使用前一组的密文进行异或运算后再和对应该组的密文进行加密操作生成密文。
为简单的分组加密。将明文和密文分成若干组后，使用密文对明文进行加密生成密文
CBC
加密：
解密：