第二章：密钥生成策略与合规性要求
密钥生成这件事，我见过太多团队栽跟头了。不是选错算法，就是长度不够，回头审计时被查出非合规项——罚钱事小，数据泄露才真要命。
这一章咱们就把算法选择、密钥长度、合规标准这三件事掰开揉碎讲清楚。准备好了？直接进入正题。
2.1 算法选择：不是越新越好，而是越“合规”越好
选算法，我的第一原则是：看合规清单。FIPS 140-3、PCI DSS、GDPR、GM/T 0054……这些标准里写了什么算法你就用什么算法，别自己发明。
我个人习惯把算法分成三类：
- 对称算法：AES 是主力。DES 早该退休了，3DES 也在逐步淘汰。
- 非对称算法：RSA 还能用，但我建议优先上 ECC。SM2 是国标，国内项目必须用它。
- 哈希算法：SHA-256 起步，SHA-512 更安全。MD5 和 SHA-1 别碰了，审计直接判不合格。
2.1.1 对称算法选择清单
| 算法 | 密钥长度（位） | 合规标准 | 状态 |
|---|---|---|---|
| AES | 128, 192, 256 | FIPS 197, ISO 18033-3 | ✅ 强烈推荐 |
| SM4 | 128 | GM/T 0002, GB/T 32907 | ✅ 国标必选 |
| 3DES | 168 | NIST SP 800-67 (弃用中) | ⚠️ 已不推荐 |
| ChaCha20 | 256 | RFC 8439 | ✅ 移动端常用 |
2.1.2 非对称算法与哈希算法
非对称算法里，RSA 和 ECC 是两大主力。ECC 同样的安全强度下密钥更短，性能更好。哈希算法呢？我说个原则：输出长度不能短于 256 位。SHA-256、SHA-3-256、SM3 都是好选择。
2.2 密钥长度：短一寸，风险长一寸
密钥长度这个话题，说白了就是：抗暴力破解的能力。每增加 1 位，需要的尝试次数翻倍。
我建议记下这张对照表，审计时直接拿出来对：
| 算法族 | 最低安全长度 | 推荐长度 | 备注 |
|---|---|---|---|
| AES | 128 位 | 256 位 | 128 位可满足 2030 年前大部分场景 |
| RSA | 2048 位 | 3072 位 | 1024 位已不再安全 |
| ECC | 224 位 | 256 位 | P-256 常用，对应 RSA 3072 |
| SM2 | 256 位 | 256 位 | 国标固定 256 位 |
| DSA | 2048 位 | 2048 位 | 与 RSA 对标 |
关键点： 密钥长度不是越大越好。AES-256 和 AES-128 性能差 40% 左右，但 128 位对绝大多数场景已经够用。我一般默认用 256 位，因为审计通吃，不用纠结。
2.3 合规标准：审计官不会写在脸上的红线
合规这玩意儿，平时觉得麻烦，出事后才叫真麻烦。我列几个你绕不过去的标准：
- FIPS 140-3：美国联邦标准，国际项目必看。要求密钥生成使用 NIST SP 800-133 规定的 DRBG。
- PCI DSS v4.0：支付行业标准。密钥长度、存储、轮换都有硬性规定。
- GM/T 0054：中国密码行业标准。要求使用国家密码管理局批准的算法（SM2/SM3/SM4）。
- GDPR & 等保 2.0：数据保护法规。虽然没有直接规定算法，但要求“适当的安全措施”，目前默认不遵守 FIPS 或国标就是违规。
2.3.1 合规检查清单（我自己的审计备忘录）
- 算法白名单： 配置里只允许 AES-256, ECC P-256, SHA-256, SM2, SM4, SM3。
- 密钥长度校验： 生成代码里加断言，长度不足直接抛异常。
- 随机源验证： 必须使用经过认证的 DRBG（如 CTR_DRBG, Hash_DRBG），别用 rand() 或 math.random。
- 密钥存储： 私钥必须 HSM 或加密存储，不能明文落盘。
- 轮换策略： 密钥有效期，非对称密钥不超过 2 年，对称密钥不超过 1 年（PCI DSS 要求 1 年）。
我曾经踩过的坑： 项目里用了 OpenSSL 的默认随机生成器，没初始化熵源。结果密钥质量不够，硬是通不过 NIST 随机性测试。后来换用硬件随机数发生器才搞定。嗯，这里要注意，随机数质量直接决定密钥是否“真随机”。
2.4 密钥生成策略的完整决策框架
说了这么多，到底怎么下手？我习惯用一个四步框架：
- 定场景：是 TDE 数据加密？TLS 证书？还是代码签名？场景决定了算法族。
- 查合规：国内项目对照 GM/T 0054，国际项目对照 FIPS 140-3，金融类对照 PCI DSS。
- 选算法+长度：按推荐表选，别搞特殊。
- 配随机源：优先用 HSM 或操作系统 /dev/urandom，确保熵足够。
下面这张图概括了本章的核心逻辑。你看完它，心里就有谱了。
2.5 生成策略的落地检查点
光说理论不行，咱们来点实际的。这部分是我在审计时一定会查的代码级检查。
2.5.1 代码示例：合规的密钥生成（Java 版）
// 合规生成 AES-256 密钥
KeyGenerator keyGen = KeyGenerator.getInstance("AES");
keyGen.init(256, SecureRandom.getInstanceStrong());
SecretKey key = keyGen.generateKey();
// 注意：SecureRandom.getInstanceStrong() 在 Linux 下会使用 /dev/random
// 如果阻塞，可以改为 SecureRandom.getInstance("NativePRNGNonBlocking");
// 但必须确保认证过的 DRBG
2.5.2 检查清单
- 算法实例化时是否指定了 Provider？我建议显式指定，避免 JCE 默认 Provider 被篡改。
- 密钥长度是否在配置里硬编码而不是从外部读取？防止注入。
- 生成后是否立即对密钥进行完整性校验（比如 HMAC）？
- 密钥对象是否显式置空？防止内存转储泄露。
小技巧： 你可以在 CI/CD 流水线里加一个密钥合规扫描插件。我曾经写过一个 Jenkins 脚本，自动检查代码中所有 KeyGenerator/KeyPairGenerator 的初始化参数，长度不足就终止构建。省心。
好了，这一章的核心就这些。记住：算法、长度、合规标准——三个点扣成一个闭环，哪个都不能漏。实际项目中，我建议你先把本章的决策框架打印出来贴在工位旁，上手时对照着来，基本不会翻车。