第四章：SM4的工作模式 —— 不止是加解密那么简单
聊SM4，很多人第一反应就是那个S盒、那个线性变换。没错，这些都是核心。但你想想看，我们实际去加解密一段数据，不是每次只处理16字节。真实场景里，数据可能是几兆、几G，甚至是个网络流。这时候，怎么用迭代块密码去处理不定长的信息？
答案就是：工作模式。
我个人的习惯是，把工作模式看作是一套“操作策略”。块密码是核心引擎，工作模式定义了怎么驱动这个引擎去处理任意长度的数据。咱们做并发监控和容量审计，选错模式，轻则性能血崩，重则安全性出漏子。
嗯，这一章咱们就一次性搞懂SM4最常见的几种模式：ECB、CBC、CTR，还有他们的“亲戚”们。我还会聊聊在项目中遇到的坑。
ECB模式：最直接，但也最危险
ECB全称是电子密码本模式(Electronic Codebook)。说白了，就是把明文按16字节切块，每一块用相同的密钥独立加密。
它最大的优点是简单，并且天然支持并行。多线程加密时，各个块之间谁也不依赖谁。这在并发监控场景下，似乎是个加分项？
小心！ 我的建议是，除非你明确知道自己在做什么，否则千万别在生产环境里单独使用ECB模式。它在安全性上有严重缺陷。
我曾经接手过一个审计项目，客户之前用SM4-ECB加密了一批交易流水文件。数据量很大，但加密速度确实快。直到有一天，安全扫描发现，密文里出现了明显的周期性重复模式。原来，明文里有很多相同的交易金额字段，加密后的结果一模一样。攻击者可以根据这些“指纹”直接推断出数据的结构。
ECB的最大问题：相同的明文块，会生成相同的密文块。这种“确定性”在密码学里是致命弱点。
它适用在哪？极少。偶尔会用在随机数加密或者密钥加密上，因为那些数据本身没有重复模式。对于我们的监控数据，我强烈不建议。
CBC模式：业界常青树，但串行是瓶颈
CBC，密码分组链接模式(Cipher Block Chaining)，是ECB的改良版。它解决了ECB的“相同明文块”问题。
原理是这样的：在加密第一个块之前，先引入一个随机数，叫做初始化向量(IV)。第一个明文块和IV做异或运算，然后去加密。之后，上一块的密文，会成为下一块的加密输入的一部分。
这样一来，即使两个明文块一模一样，由于它们“链接”了不同的前一块密文，最终输出的密文也不会相同。安全性好很多。
一个避坑指南： 我曾经见过一个实现，每次加密都使用固定的IV。这相当于把ECB的缺点又带了回来。IV必须随机生成，而且通常是不需要保密的，但要保证每次加密的IV都是唯一的。
但是CBC有个致命伤：加密过程必须串行。处理第N块，必须等第N-1块的密文算出来。这在并发监控场景下，如果想提高多线程加密的吞吐，CBC模式就成了瓶颈。
解密过程倒是可以并行，因为解密时所有密文块已经在了。但在大多数据生产环节，加密是写入端的操作，串行加密会影响写入速度。
CBC模式最常出现在SSL/TLS 我刚才提到的典型TLS/SSL协议里，很多都在用CBC。但它对错误很敏感，一个块的密文出错，会导致当前块和下一块都解密失败。这也是为什么后来TLS 1.3直接抛弃了CBC。
CTR模式：并发场景的最佳解
CTR，计数器模式(Counter)。这也是我个人最偏爱的模式，尤其在处理大量并发数据流的时候。
它不再用上一块的输出来影响下一块了。它的核心是：生成一个递增的计数器（Counter），将这个计数器和密钥一起输入SM4引擎，生成一个密钥流。然后，用这个密钥流和明文做异或，得到密文。
你看，解密时同理。只要生成相同的密钥流，再和密文异或，就能还原明文。
CTR最大的优点：加密和解密都天然支持并行！每个数据块使用独特的计数器值，互不依赖。无论你是使用八线程还是十六线程，理论上加速比非常接近线性。
还有一个优点，它不需要填充(Padding)。ECB和CBC都要求明文长度是16字节的整数倍，不够就得填充。CTR模式本质上把SM4变成了一个流密码，明文多长，密钥流就只生成多长，不需要额外填充。
在数据库加密、磁盘加密，以及我们正在讨论的并发监控系统中，CTR都是首选。它的错误传播也最小，一个密文块损坏，只会影响到对应的那个明文块，不会像CBC那样连累邻居。
核心总结： 在并发监控与容量审计场景下，如果你对安全性有基本要求，并且需要在多线程环境里榨干CPU的性能，CTR模式几乎是唯一的选择。我见过的一些高性能数据网关，底层都用的是AES-CTR或者SM4-CTR。
如何选择？一张表格说清楚
下面的表格我把最常见的几种模式做了个横向对比。你可以把它当作查询手册。
| 模式 | 安全性 | 并行能力 | 错误传播 | 是否需要IV | 典型应用 |
|---|---|---|---|---|---|
| ECB | 低 | 高（加密/解密都并行） | 无传播 | 否 | 极少使用（仅在特定安全场景） |
| CBC | 高 | 低（加密串行，解密并行） | 有（2个块受影响） | 是（需随机） | 传统传输协议、文件加密 |
| CTR | 高 | 高（加密/解密都并行） | 无传播 | 是（计数器+nonce） | 并发加密、磁盘加密、流加密 |
| CFB / OFB | 中/高 | 中（反馈类型不同） | 有传播 | 是 | 流媒体、通信链路 |
一个实战经验： 我在做容量审计平台时，遇到过需要对上亿条小流量日志做实时加密写入。计数器模式完美支持了高并发写入。只要你确保每个加密请求的计数器（Nonce+Counter）不会重复，就不会出现安全问题。需要特别注意的是计数器重复，一旦两个不同明文使用了相同的密钥和相同的计数器，密钥流就重复了，异或两段密文就能得到明文的异或值，这就破解了。
代码示例：用Python实现SM4-CTR的伪代码
这里我用Python风格写一个SM4-CTR的核心思路。实际生产会用C或者Rust来实现，但逻辑是完全一样的。
class SM4CTR:
def __init__(self, key, nonce):
self.cipher = SM4(key) # SM4核心引擎
self.nonce = nonce # 一个固定值，比如8字节
self.counter = 0 # 一个64位的整数计数器
def _generate_keystream(self, counter_value):
# 将nonce和计数器拼接成128位输入
input_block = self.nonce + counter_value.to_bytes(8, 'big')
# 调用SM4引擎加密，生成一个16字节的密钥流块
return self.cipher.encrypt_block(input_block)
def encrypt(self, plaintext):
ciphertext = bytearray()
for i in range(0, len(plaintext), 16):
keystream = self._generate_keystream(self.counter)
block = plaintext[i:i+16]
# 异或操作
for j in range(len(block)):
ciphertext.append(block[j] ^ keystream[j])
self.counter += 1 # 计数器递增
return bytes(ciphertext)
def decrypt(self, ciphertext):
# 解密和加密完全一样
return self.encrypt(ciphertext)看到没？加密和解密是同一个函数。这就是CTR模式对称性的体现。
关键配置： nonce + counter 的组合必须对每个加密操作唯一。nonce通常是随机生成的，counter从0开始递增。当counter溢出（比如超过64位最大值），必须更换nonce。否则就出事了。这个在并发监控里尤其要注意，因为多个线程可能操作同一个计数器对象。
扩展到其他模式：GCM
最后提一个现代模式：GCM(Galois/Counter Mode)。它本质是CTR模式 + 一个强力的认证标签(GMAC)。CTR只负责加解密，不保证数据在传输过程中没有被篡改。GCM在CTR的基础上，额外计算一个校验和，能够检测数据是否被修改。
在我们剖析并发日志、审计数据时，如果数据需要经过多个微服务流转，不仅需要加密，还需要保证完整性，我个人建议直接上SM4-GCM。它一次性解决加密和认证两个问题，省心省力。
好了，关于SM4工作模式的选择，核心点就这些。选对模式，你的并发监控系统才能跑得既快又稳。记住我的经验：ECB不要用，CBC慎用，CTR优先选，GCM是终极方案。