SM4-CBC模式：原理与实现
CBC模式，说白了就是给每个数据块加点“个性”。你想想，ECB模式最大的问题是什么？同样的明文块会产出同样的密文块。这在加密一张图片时尤其明显，轮廓都能看出来。CBC就是来解决这个问题的。
从一根链条说起
CBC的全称是Cipher Block Chaining——密文分组链接。核心思想很简单：让每个明文块在加密之前，先跟上一个块的密文做一次异或。
我刚开始接触这个模式时，总觉得多此一举。直到有一次在项目中做图片加密，ECB模式加密后的头像还能依稀辨认出五官，换成CBC模式后完全就是一坨随机噪声。那一刻我才真正理解了“链接”的意义。
具体流程是这样的：
- 首块明文跟一个初始化向量（IV）做异或
- 然后使用SM4密钥进行加密，得到第一块密文
- 这块密文被保存下来，同时作为下一轮的“向量”
- 第二块明文跟第一块密文异或，再加密
- 以此类推，像链条一样串下去
关键认知：CBC模式中，相同的明文块（比如连续的零字节）在不同位置会产生完全不同的密文块。这是CBC相对于ECB最核心的安全优势。
初始化向量的那些事
IV是CBC模式里绕不开的话题。很多人觉得它就是随便一个初始值，给个全零就行。嗯，这里要注意，大错特错。
IV的三个硬性要求：
- 不可预测：IV不应该被攻击者提前知道或控制。我见过有人用固定IV（比如0x000...000）作为默认配置，这在安全审计中直接被标红。
- 一次一密：同一个密钥下，每次加密都要使用不同的IV。重复使用IV会让CBC退化，你想想看，前几个块的模式就暴露了。
- 随机生成：一般用安全的随机数生成器产生，长度必须等于分组大小。SM4分组是128位，也就是16字节。
个人习惯：我习惯把IV直接拼接在密文前面一起传输。解密时先取前16字节作为IV，后面的才是真正的密文。这样IV跟密文绑定，不会搞丢，也不会弄混。
填充问题——PKCS7的正确姿势
SM4的分组固定16字节。如果最后一个明文块不足16字节怎么办？填满它。
常见的填充方式是PKCS7。规则很简单：缺几个字节，就填数值几。
举个例子：
| 情况 | 明文最后一块 | 填充后 |
|---|---|---|
| 差1字节 | 0x01 0x02 0x03 | 0x01 0x02 0x03 0x01 |
| 差5字节 | 0x01 0x02 0x03 | 0x01 0x02 0x03 0x05 0x05 0x05 0x05 0x05 |
| 正好16字节 | 16字节完整数据 | 附加一整块 0x10 0x10 ... 共16个0x10 |
这个表格里最后一种情况特别容易踩坑。明文长度刚好是16的倍数时，还需要额外填充一整块？是的。为什么？解密时如果没有填充块，你无法区分“最后一个字节0x01是填充还是真实数据”。强制附加一整块，解密时看到16个0x10，就知道这是填充，直接丢弃。
我曾经踩过的坑：早期写CBC解密时，我直接判断最后一个字节的值N，然后从末尾去掉N个字节。结果遇到明文正好以0x01结尾而且后面没有填充的情况，程序错误地去掉了一个合法字节。后来改成“先检查是否至少有一个字节，且所有填充字节的值都必须等于最后一个字节的值”，才算彻底解决。
CBC的加解密步骤
加密过程：
// 伪代码示例
C[0] = SM4_Encrypt(P[0] XOR IV, Key)
C[i] = SM4_Encrypt(P[i] XOR C[i-1], Key) // i >= 1
解密过程：
P[0] = SM4_Decrypt(C[0], Key) XOR IV
P[i] = SM4_Decrypt(C[i], Key) XOR C[i-1] // i >= 1
注意解密时用的是逆操作。加密是“先异或再加密”，解密是“先解密再异或”。这个顺序不能搞反。
CBC模式完整流程图
下面这张图是我自己整理时画的，展示了CBC模式的完整加解密流程。我把IV、明文块、密文块、异或、SM4加密函数以及密文链的关系都画出来了。
CBC的优缺点
优点很明显：
- 相同的明文块在不同位置产生不同的密文，抵抗模式分析
- 错误扩散有限：单个密文块损坏只影响当前块和下一块的解密
- 支持并行解密（但加密不能并行，因为有依赖链）
缺点也得清楚：
- 加密不能并行，速度比ECB慢
- 如果IV不是随机的，安全性大打折扣
- 存在填充攻击（Padding Oracle Attack），解密接口暴露填充校验结果是很危险的
安全红线：不要在解密接口中返回“填充错误”或“MAC校验失败”这种区分性错误信息。攻击者可以利用这种信息结合Padding Oracle Attack一步步还原明文。我以前参与过一个渗透测试项目，目标系统就是因为给了不同的错误码，20分钟内就被还原出了全部Cookie数据。
实际项目中的CBC参数配置
如果你在写SM4接口，CBC模式需要明确这组参数：
| 参数 | 长度 | 说明 |
|---|---|---|
| 密钥key | 16字节 | SM4固定128位 |
| 初始化向量IV | 16字节 | 每次加密随机生成，不可重复使用 |
| 填充方式 | PKCS7 | 业界标准，几乎所有语言都支持 |
| 数据编码 | Base64/Hex | 密文和IV通常需要编码传输 |
我建议的接口设计：加密时返回 base64(iv) + "." + base64(ciphertext)。解密时用"."分割。这样接口传参清晰，不用额外约定存放IV的位置。很多OpenAPI规范里就是这么干的。
写代码时，CBC模式的核心实现大概在50行左右就能完成（语言不同有差异）。关键是把SM4的ECB加密/解密函数作为底层原语，在其上封装异或操作和链式传递。你不用自己重新实现SM4，但CBC的异或链和填充逻辑必须自己处理好。