1. 密码算法选型与安全评估导论
在任何一个需要保护数据机密性、完整性或真实性的系统里，密码算法都不是孤立存在的“数学工具”，而是嵌入到协议、产品、业务流程和合规体系中的安全基础设施。密码算法选型与安全评估，正是围绕“用什么算法、为什么用它、它是否足够安全、如何证明它满足要求”这四个问题展开的系统性工作。本课程的目标，是让读者能够从工程与合规双重视角，独立完成一次可解释、可追溯、可落地的算法选型与安全评估。
一、课程要解决的核心问题
密码算法选型并不是简单地“选一个最安全的算法”。实际工程中，选型至少同时受到四类约束：安全强度（能否抵抗当前与可预见未来的攻击）、性能与资源（吞吐、延迟、内存、功耗、硬件加速支持）、互操作与生态（协议标准、库支持、密钥与证书格式）、合规与监管（是否属于允许使用的算法清单、是否满足等保、密评或行业规范）。这四类约束经常互相冲突，例如某些场景下国密算法是合规刚需，但部分老旧系统缺少硬件加速，性能会明显下降。
因此，本课程要回答的核心问题可以归纳为：给定业务场景、数据生命周期、威胁模型和合规要求，如何选择一组算法与参数，并用可验证的证据说明该选择在目标安全等级下是充分的。这里的“证据”既包括理论安全强度分析，也包括实现层面的侧信道、随机数、密钥管理等评估结论。
二、选型与评估的关系
选型与评估不是两个先后独立的阶段，而是一个相互驱动的闭环。选型给出候选方案，评估暴露候选方案的弱点与边界条件，评估结论又反过来修正选型。一个常见的误区是“先选型、后评估”，结果评估时才发现算法虽然理论安全，但实现库存在填充预言（padding oracle）问题，或密钥长度不满足合规最低要求，导致返工。
更合理的做法是：在选型阶段就同步建立评估要点，例如明确安全强度目标（如128位经典安全强度）、明确必须支持的算法族（对称、非对称、哈希、MAC、KDF）、明确禁止使用的算法（如MD5、SHA-1、DES、RC4、ECB模式），并把这些要求写成可检查的条目。评估阶段则围绕这些条目逐项验证，形成“要求—证据—结论”的对应关系。
三、典型应用场景与算法组合
不同场景对算法的要求差异很大。下面给出几类典型场景及其常见算法组合，作为后续章节展开的锚点。
| 场景 | 核心安全目标 | 典型算法组合 | 关键约束 |
|---|---|---|---|
| HTTPS/TLS 传输 | 机密性、完整性、身份认证 | ECDHE + AES-128-GCM + SHA-256 | 前向保密、握手延迟、证书兼容 |
| 本地数据加密存储 | 机密性、密钥隔离 | AES-256-GCM 或 SM4-GCM + KDF | 密钥不落盘、随机数质量 |
| 数字签名与验签 | 真实性、不可否认 | ECDSA P-256 或 SM2 + SHA-256/SM3 | 签名长度、验签性能、证书链 |
| 口令存储 | 抗离线爆破 | Argon2id / scrypt / PBKDF2-HMAC-SHA256 | 迭代成本、内存成本、盐值唯一 |
| 物联网轻量设备 | 低功耗下的机密性与认证 | SM4 + SM3 + SM2 或 AES-CCM + ECC | RAM/ROM、功耗、硬件加速 |
以“本地数据加密存储”为例，一个可执行的选型片段是：使用 AES-256-GCM，每条记录独立生成 96 位随机 nonce，密钥由主密钥经 HKDF-SHA256 派生，主密钥存放在 HSM 或 TEE 中。评估时要检查：nonce 是否可能重复、GCM 的认证标签是否被截断、密钥派生是否绑定了上下文信息。这些检查点会在后续章节逐一展开。
四、合规要求的基本框架
合规不是选型的“附加项”，而是硬约束。国内常见要求包括：等保2.0对密码技术使用的要求、商用密码应用安全性评估（密评）对算法与密钥管理的要求、以及金融、政务、能源等行业的专项规范。国际上则有 NIST SP 800-57 密钥管理、FIPS 140-3 模块验证、GDPR 对个人数据保护的要求等。
五、本课程的学习路径
后续章节将按照“基础概念—算法族详解—参数与模式—评估方法—工程落地—案例复盘”的顺序推进。每一章都会围绕一个可操作的问题展开，例如“如何为一条业务链路选择对称加密模式”“如何评估一个随机数生成器是否合格”“如何把合规条款映射到具体算法参数”。读者在学习过程中，应始终带着自己系统中的一个真实场景，边学边做选型与评估的草稿，最终形成一份可评审的算法选型报告。