2. 密钥生成：算法选择、随机数与HSM

密钥生成这事儿，看着简单，其实坑特别多。我见过不少团队，算法选得挺高级，结果随机数没搞好，密钥跟纸糊的似的。今天咱们就掰开揉碎，把对称/非对称算法选择、随机数质量、还有HSM这几个点聊透。

2.1 对称算法 vs 非对称算法：怎么选？

说白了，对称加密快，适合大量数据。非对称加密慢，但能解决密钥分发问题。你想想看，如果两个人隔着网络，怎么安全地共享同一个对称密钥？这时候就得靠非对称算法来协商。

我个人习惯是这么分的：

• 对称算法：AES-256 是首选。别用 DES 或 3DES，那都是上个世纪的东西了。AES 的 GCM 模式自带认证，能防篡改，我项目里基本都用它。
• 非对称算法：RSA 和 ECC 是主流。RSA 至少 2048 位，ECC 推荐 P-256 或 Curve25519。ECC 的密钥短，性能好，移动端场景特别合适。

我记得有一次做金融系统，客户非要 RSA 4096 位。我说没必要，P-256 就够了，性能差好几倍。后来实测，ECC 确实快，而且安全性等价于 RSA 3072 位。嗯，这里要注意：别盲目追求大位数，够用就行。

2.2 随机数质量与熵源

密钥的强度，一半靠算法，一半靠随机数。随机数要是出了问题，算法再强也没用。我曾经遇到过一台嵌入式设备，随机数生成器用的是未初始化的内存，结果每次重启生成的密钥都一样……那叫一个惨。

好的随机数，必须满足两个条件：

1. 不可预测性：攻击者无法通过任何手段推断出下一个随机数。
2. 均匀分布：0 和 1 出现的概率大致相等。

熵源是关键。操作系统自带的 /dev/random 和 /dev/urandom 是常见选择。但要注意：

随机数源	特点	适用场景
/dev/random	阻塞式，熵池不足时会等待	生成长期密钥、证书
/dev/urandom	非阻塞，熵池不足时用伪随机	会话密钥、临时令牌
硬件随机数生成器	基于物理噪声，熵源可靠	HSM、安全芯片

另外，别自己写随机数生成器。标准库里的 secrets（Python）、SecureRandom（Java）、crypto/rand（Go）都够用。自己写的，十有八九有漏洞。

2.3 硬件安全模块（HSM）的使用

HSM 这东西，说白了就是一个专门保护密钥的硬件盒子。密钥存在里面，外面的人拿不到。就算服务器被攻破了，攻击者也读不到 HSM 里的密钥。

我建议，只要涉及根密钥、签名密钥、CA 密钥这类核心资产，必须上 HSM。普通业务密钥可以视情况而定。

HSM 的主要作用：

• 安全存储：密钥以加密形式存储在 HSM 内部，外部无法直接读取。
• 加密运算：签名、解密等操作在 HSM 内部完成，密钥不离开硬件。
• 访问控制：通过 PIN、密钥分割、多因素认证等方式控制使用权限。

使用 HSM 时，有几个要点：

1. 初始化：设置管理员 PIN、备份密钥、密钥分割方案。别把 PIN 写在纸条上贴机器上。
2. 密钥生成：尽量在 HSM 内部生成密钥，不要在外部生成再导入。内部生成的密钥，随机数质量有保障。
3. 备份与恢复：HSM 的密钥备份通常是加密的，需要多个管理员同时在场才能恢复。我见过一个团队，备份密钥丢了，结果 HSM 坏了之后所有数据都解不了……

2.4 密钥生成流程总览

下面这张图，是我自己总结的密钥生成流程。每次做新项目，我都会拿它过一遍。

流程看着简单，但每一步都有讲究。需求分析阶段要搞清楚：密钥用来干嘛？加密数据还是签名？有效期多长？合规要求是什么？这些决定了后续的算法和存储方案。

算法选择时，我建议优先考虑 NIST 或国密标准。别用自己发明的算法，也别用已经过时的。随机数生成这一步，能上硬件熵源就上硬件，实在不行也要用操作系统提供的安全随机数接口。

最后，HSM 生成这一步，是很多团队容易忽略的。他们觉得在软件里生成密钥再导入 HSM 也行。其实不然，密钥在软件里生成时，内存里会有明文副本，攻击者有可能拿到。在 HSM 内部生成，密钥从头到尾都没离开过硬件，安全性高得多。