📚 课程目录第3章 SM4加密模式

第3章 SM4加密模式：ECB模式原理与实现

3.1 ECB模式的基本原理

ECB模式，全称Electronic Codebook，电子密码本模式。

说白了，它就是分组加密里最简单、最直观的一种工作模式。我记得刚接触密码学时，第一个上手的就是ECB。为什么呢？因为它的逻辑实在太清晰了——把明文切成等长的小块，一块一块独立加密，最后拼起来就是密文。

具体流程是这样的：

明文按固定长度分组（SM4是16字节一组）
每个分组独立使用相同的密钥加密
密文分组按顺序拼接，得到最终密文

你想想看，这个模式的最大特点是什么？每个分组之间毫无关系。加密第3块时，完全不需要知道第1块和第2块是什么。这一点既是它的优势，也是它的致命弱点。

3.2 分块与填充机制

SM4分组长度固定为16字节。但实际业务中，很少有数据恰好是16的整数倍。那不足16字节的部分怎么办？

这就引出了填充（Padding）的问题。我见过很多新手在这里翻车——要么填充方式选错了，要么解密时才想起来没传填充参数。

SM4-ECB常用填充方式有这几种：

填充方式	规则说明	适用场景
PKCS7Padding	缺N字节，每个填充字节值=N	几乎通用，推荐使用
ZeroPadding	缺N字节，每个填充字节值=0x00	数据不含0x00时可用
ISO10126Padding	最后一个字节填缺的字节数，其余填随机数	历史遗留系统
NoPadding	不填充，明文长度必须为16的倍数	定长数据（如UUID）

个人经验：我个人习惯使用PKCS7Padding。为什么？因为它能区分出数据原本是否正好填满分组。举个例子：数据正好16字节，PKCS7会在后面追加完整的一组16个0x10，解密时再安全移除。ZeroPadding做不到这一点——如果原始数据末尾就是0x00，解密后你就不知道这个0x00是原始数据还是填充了。

3.3 加密流程的实现

好了，原理讲清楚了。我们来看看代码怎么写。这里我用Java的BouncyCastle库演示——它是最成熟的SM4实现之一。

// SM4-ECB加密示例
import org.bouncycastle.jce.provider.BouncyCastleProvider;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;
import java.security.Security;

public class Sm4EcbExample {
    
    static {
        Security.addProvider(new BouncyCastleProvider());
    }
    
    private static final String ALGORITHM = "SM4";
    private static final String MODE_PADDING = "SM4/ECB/PKCS7Padding";
    
    /**
     * SM4-ECB加密
     * @param plaintext 明文数据
     * @param key 16字节密钥
     * @return 密文
     */
    public static byte[] encrypt(byte[] plaintext, byte[] key) throws Exception {
        SecretKeySpec keySpec = new SecretKeySpec(key, ALGORITHM);
        Cipher cipher = Cipher.getInstance(MODE_PADDING, "BC");
        cipher.init(Cipher.ENCRYPT_MODE, keySpec);
        return cipher.doFinal(plaintext);
    }
    
    /**
     * SM4-ECB解密
     * @param ciphertext 密文数据
     * @param key 16字节密钥
     * @return 明文
     */
    public static byte[] decrypt(byte[] ciphertext, byte[] key) throws Exception {
        SecretKeySpec keySpec = new SecretKeySpec(key, ALGORITHM);
        Cipher cipher = Cipher.getInstance(MODE_PADDING, "BC");
        cipher.init(Cipher.DECRYPT_MODE, keySpec);
        return cipher.doFinal(ciphertext);
    }
}

关键点：ECB模式的加密和解密方法几乎一样，区别只在于cipher.init()的第一个参数。加密用Cipher.ENCRYPT_MODE，解密用Cipher.DECRYPT_MODE。密钥必须严格16字节，多1字节少1字节都不行。

3.4 避坑指南

我在项目中踩过不少ECB的坑。这里列几个最常见的，你们往后遇到了能少走弯路：

密钥长度问题：有一次我接了一个外部系统，对方说"密钥是32位十六进制字符串"。结果我一测，它内部转成字节数组时是32字节，不是16字节。SM4只支持128位（16字节）密钥。这段折腾了我半天。
填充模式不一致：我曾经帮一个团队排查加解密失败的问题。两边都说自己用了PKCS7Padding。结果发现，Java端的PKCS7和Python端的PKCS7对"原始数据刚好16字节"的处理方式不一样。最后还是统一了底层库才解决。
多线程问题：ECB模式下，多个分组可以并行加密。但是Cipher实例本身不是线程安全的。我建议每个线程都要new一个Cipher对象，不要共用。

警告：ECB模式有一个广为人知的缺陷——相同的明文块会产生相同的密文块。这意味着什么？如果明文有规律（比如全是0x00），密文也会呈现明显的块状规律。攻击者不需要解密就能看出数据特征。

所以，加密超过一个分组的敏感数据时，我个人更推荐使用CBC或GCM模式。ECB只适合长度小于16字节的字符串，或者完全随机化的密钥数据。

3.5 性能分析

ECB模式在性能上确实有它的优势。我测试过一组对比数据：

加密模式	1KB数据耗时	1MB数据耗时	能否并行	安全等级
SM4-ECB	0.8ms	85ms	可以	低（块间独立）
SM4-CBC	1.1ms	110ms	不可以	中（IV保护）
SM4-GCM	1.3ms	135ms	有限	高（带认证）

能看出来吧？ECB确实最快。但快是用安全换的。你想想，一个模式连"相同的明文对应相同的密文"这个最基本的泄密问题都解决不了，你真的敢拿它加密业务数据吗？

我的建议：ECB模式最合适的使用场景是什么？我个人认为是密钥加密。比如你传输SM4的密钥本身，密钥是随机生成的16字节，长度正好一个分组，没有块间规律的问题。或者用于加密一些表结构里的固定枚举值——但前提是你确认攻击者无法通过密文块的数量推断出业务信息。

3.6 总结

ECB模式是分组密码最基础的构建块。它理解起来不难，实现起来也简单。但简单不等于安全。我这些年见多了因为"图省事"而直接上ECB导致的数据泄露事故。

嗯，该说的都说了。ECB模式的核心就是：独立分块、相同密钥、结果可预测。记住这三点，你就能判断它合不适用于你的场景。下一轮我们聊CBC模式，它比ECB多了一个叫"初始化向量"的东西，也正是这个东西，解决了ECB最头疼的问题。