密钥生成策略与安全边界：随机数源、生成算法、合规要求

密钥生成是整个生命周期的起点，也是安全边界最容易塌陷的地方。我刚开始做密码学时，总觉得生成一个密钥嘛，调个库函数就行。直到有一次，产品过FIPS认证，测试人员拿我的随机数输出做了个统计分析……结果你猜怎么着？分布偏移严重，直接被判定为弱密钥。那次教训让我彻底明白——密钥生成不是随便凑一串比特。

随机数源：真随机还是伪随机？

密钥的第一道屏障是随机性。系统里常见的随机数源分为两类：

类型	来源	典型例子	安全边界
真随机数生成器 (TRNG)	物理噪声（热噪声、量子效应）	硬件RNG专用芯片、CPU内置RDRAND	速度慢，但不可预测
伪随机数生成器 (PRNG)	算法 + 种子	/dev/urandom、OpenSSL的RAND_bytes	种子质量决定安全边界

说实话，纯TRNG在嵌入式设备里很奢侈。大多数场景是拿TRNG做种子，喂给PRNG。我见过有人偷懒，直接用rand()生成密钥——那玩意儿种子是当前时间秒级粒度，碰撞概率极高。嗯，这里要注意：种子熵必须大于密钥长度。128位密钥，最少需要128位熵，最好翻倍。

生成算法：对称密钥 vs 非对称密钥

对称密钥

AES-256的密钥就是256位随机比特。生成代码很简单：

# Python 示例
import os
key = os.urandom(32)  # 256位
print(key.hex())

但简单不代表安全。我曾经接手过一个项目，他们把os.urandom放在__init__里，结果多个实例共享了相同种子——因为fork之后子进程继承了相同的随机状态。避坑指南：每次生成都要独立调用RNG，不要缓存。

非对称密钥

RSA需要两个大素数相乘，ECC需要椭圆曲线上的基点倍数。安全边界主要取决于：

• 参数长度：RSA 2048位以下已不推荐，ECC用P-256起步。
• 素数生成：不能用库默认的快速模式——我见过某厂商用openssl genrsa 1024，素数生成耗时不到1秒，说明随机性不够，被破解过。
• 曲线选择：用标准曲线（NIST P-256 / Curve25519），别自己发明。

合规要求：哪些雷不能踩？

不同行业对密钥生成有硬性规定。我把常见的列出来：

标准	要求	常见不合规点
FIPS 140-2/3	使用已认证的DRBG（如AES-CTR DRBG）	直接用urandom而不走FIPS模块
PCI DSS	密钥长度≥128位，不能用软件RNG模拟	在虚拟化环境中没有物理TRNG
GM/T 0005（国密）	SM2/3/4必须使用国家批准的随机数源	用OpenSSL而不是GMT0018硬件
GDPR / eIDAS	密钥生成过程可审计、可验证	没有日志、没有第三方测试报告

你想想看，合规不只是技术问题，更是信任问题。我参与过一个银行项目，审计员要求看随机数源的熵估计报告——幸好我们提前用硬件RNG并记录了启动时的熵池健康状态，否则直接返工三周。

知识框架：密钥生成的安全边界

下面这张图梳理了本章的核心逻辑链：

从随机数源到生成算法，再到合规要求，最后落到安全边界——每一层都可能被攻破。我见过很多安全事件，根源不在加密算法本身，而是生成环节出了纰漏。密钥生成要像对待核材料一样：源头可控、过程可溯、输出可验。