3. 密码算法分类与适用边界
在密码工程中，算法选型的第一步不是比较“谁更安全”，而是先判断当前任务属于哪一类密码学功能。分组密码、流密码、公钥密码、哈希、KDF、MAC、签名、PKE、KEM 这九类对象，分别解决“保密”“完整性”“身份”“密钥派生”“密钥封装”等不同问题。把它们混用，往往不是安全性不足，而是接口语义错位：例如用哈希代替 MAC 做消息认证，用签名代替 KEM 做密钥协商，都会在协议层留下可被利用的缺口。
一、按功能定位划分九类算法
从功能视角看，这九类算法可以归入四条主线：
- 对称加密：分组密码（如 AES、SM4）与流密码（如 ChaCha20、RC4 已不推荐）负责机密性。分组密码按固定块处理，需要工作模式（ECB/CBC/CTR/GCM）配合；流密码按字节或比特生成密钥流，与明文异或。
- 哈希与派生：哈希（SHA-256、SM3）提供单向压缩与抗碰撞；KDF（HKDF、PBKDF2、Argon2）把弱口令或共享秘密扩展为定长密钥，承担“密钥材料加工”职责。
- 消息认证：MAC（HMAC、CMAC、GMAC）用共享密钥验证消息完整性与来源真实性，输出固定标签，验证方必须持有同一密钥。
- 公钥体系：PKE（RSA-OAEP、SM2 加密）用公钥加密、私钥解密；签名（ECDSA、RSA-PSS、SM2 签名）用私钥签名、公钥验证；KEM（RSA-KEM、ECIES、ML-KEM）封装出临时对称密钥，是“密钥协商/封装”的标准化接口。
需要特别区分的是：MAC 与签名都提供完整性，但信任模型不同。MAC 是对称的，双方共享密钥，无法向第三方证明；签名是非对称的，任何人都能用公钥验证，可用于不可否认。KEM 与 PKE 也不同：PKE 直接加密任意明文，KEM 只封装一个对称密钥，通常配合 DEM（数据封装机制）组成混合加密。
二、选型时必须同时看的六个维度
确定功能类别后，还要在同类算法之间做取舍。以下六个维度通常需要同时评估：
| 维度 | 含义 | 示例判断 |
|---|---|---|
| 安全强度 | 目标比特级安全，如 128 bit | AES-128 与 SHA-256 组合可满足 128 bit 对称安全 |
| 性能开销 | 吞吐、延迟、CPU/内存占用 | ChaCha20 在无 AES 指令的移动端更稳 |
| 输出长度 | 密钥、IV、标签、签名的字节数 | GCM 标签建议 128 bit，截断到 96 bit 需评估 |
| 标准合规 | 国密、FIPS、行业规范 | 金融场景优先 SM2/SM3/SM4 或 AES 合规套件 |
| 实现风险 | 侧信道、时序、随机数依赖 | ECDSA 的 nonce 复用会直接泄露私钥 |
| 迁移成本 | 后量子、算法替换、协议兼容 | KEM 可平滑替换密钥协商，签名迁移更复杂 |
三、典型组合与边界判断
实际协议很少单独使用一种算法，而是按“KEM/DH → KDF → 对称加密 + MAC”组合。例如 TLS 1.3 的握手：先用 ECDHE 或 ML-KEM 协商共享秘密，再用 HKDF 派生出握手密钥与应用密钥，最后用 AES-GCM 或 ChaCha20-Poly1305 保护记录层。这里 KDF 不是可选项，它把原始共享秘密转换为多个方向、多个阶段的密钥，避免密钥复用。
边界判断可以抓住三条规则：
- 需要向第三方证明来源，用签名，不用 MAC。
- 只需要双方确认完整性与来源，用 MAC 或 AEAD，不必引入公钥开销。
- 需要把口令变成密钥，必须用慢哈希 KDF（Argon2、PBKDF2），不能直接用 SHA-256。
常见误用：用 SHA-256(消息) 代替 HMAC 做认证。哈希没有密钥，攻击者可以修改消息并重算摘要，无法提供来源真实性。正确做法是 HMAC-SHA256 或直接使用 AES-GCM 这类 AEAD。
四、一个可执行的选型检查清单
下面这份清单可直接用于方案评审，按顺序回答即可缩小候选范围：
1. 任务目标是什么？
- 保密 → 对称加密（分组/流）
- 完整性+来源（双方） → MAC / AEAD
- 不可否认 → 签名
- 密钥分发/协商 → KEM / DH
- 口令或共享秘密加工 → KDF
2. 目标安全强度是多少 bit？
- 128 bit：AES-128、SHA-256、HMAC-SHA256、ECDSA P-256
- 192/256 bit：AES-256、SHA-384/512、SM2/SM3/SM4
3. 运行环境限制？
- 有 AES-NI：AES-GCM 优先
- 无硬件加速/移动端：ChaCha20-Poly1305
- 资源极受限：轻量级算法需单独评估
4. 合规要求？
- 国密场景：SM2/SM3/SM4 + SM9（如适用）
- FIPS 场景：AES、SHA-2/3、HMAC、ECDSA/RSA-PSS
5. 随机数与 nonce 如何管理？
- GCM nonce 不得重复
- ECDSA nonce 必须唯一且不可预测
- KEM 需使用安全随机源
6. 是否考虑后量子迁移？
- 密钥协商：ML-KEM 混合 X25519
- 签名：ML-DSA 或 SLH-DSA 混合传统签名
把这份清单落到具体项目时，建议先固定“功能类别”，再在同类中按安全强度、性能和合规筛选，最后检查随机数、nonce 和密钥生命周期管理。算法本身选对，只是安全的一半；接口语义、参数长度和实现细节同样决定最终边界。