密钥生成：安全随机数、熵源与 OpenSSL 实战
密钥生成这事儿，说起来就四个字「随机数」。但真要把这步做扎实，里面门道多着呢。我记得刚入行那会儿，觉得随机数不就 rand() 嘛，后来吃过大亏才明白——密码学里的随机，跟咱们平时理解的根本不是一回事。
安全随机数：不是随便叫 Random 就安全
你可能会问：计算机里到底有没有真随机？答案是：有，但得看你怎么拿。
一般程序里的 rand()，本质上是个固定算法。你给个种子，它输出一串看起来很乱的数字。但只要种子一样，结果就完全一样。这叫伪随机数生成器。密码学不能用这玩意儿。
常见的密码学安全随机数生成器，底层走的是加密算法。比如 OpenSSL 用的 RAND_bytes()，内部基于 CTR_DRBG 或 HMAC_DRBG，这些都有 NIST 标准背书。说白了，它是用加密算法把一小段真正的随机性「拉伸」成任意长度的、密码学安全的随机流。
我见过有些项目图省事，直接用 Math.random() 去生成密钥……嗯，那是真敢写啊。结果攻防演练的时候，攻击者根据系统启动时间反推种子，一分钟内把密钥空间扫出来了。
熵源：随机数的「燃料」
安全随机数生成器本身不是真随机，它的随机性来自哪儿？来自——熵源。
熵，就是系统中的不确定性。每次你敲键盘的时间间隔、鼠标移动轨迹、磁盘读写延迟、网络包到达时间……这些微观层面的波动，在物理上都是不可精确复现的。操作系统干的其中一件事，就是把这些信息收集起来，放入「熵池」。
cat /proc/sys/kernel/random/entropy_avail 查看当前熵池大小。如果这个值持续低于 128，你的随机数质量就很危险了。
我曾在云环境里遇到过一个坑：新开的容器，熵池几乎为零，RAND_bytes() 直接阻塞挂起，进程卡死。后来怎么解决的？部署了 haveged 守护进程和服务，利用 CPU 时间戳和硬件中断变体来补充熵源。这事儿之后，我习惯在任何生产环境的初始化脚本里，都加一条熵源检查。
| 熵源类型 | 示例 | 是否真随机 | 适用场景 |
|---|---|---|---|
| 物理熵源 | 硬件随机数生成器、量子噪声 | 是 | 密钥生成、证书签发 |
| 环境熵源 | 鼠标、键盘、磁盘延迟 | 是（但速率低） | 启动时种子填充 |
| 软件伪随机 | /dev/urandom、RAND_bytes | 否（但安全） | 日常会话密钥 |
顺带提一句：/dev/random 和 /dev/urandom 怎么选？早期 Linux 上 random 是阻塞的，urandom 不阻塞。现在内核里两者底层都走 chacha20，urandom 在系统初始化后就已经有足够熵了。我个人建议：应用程序用 /dev/urandom 或者 getrandom() 系统调用就够了，真没必要死等那个阻塞的。
使用 OpenSSL 生成密钥对
好，聊完原理，我们上实战。OpenSSL 是密钥生成界的瑞士军刀，但用不对照样翻车。
命令行操作
最基础的，生成一份 RSA 私钥：
openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048
这里我习惯用 genpkey 而非老式 genrsa。为什么？因为 genpkey 是统一接口，支持各种算法，写法也更规范。你可以把 -pkeyopt 换成 rsa_keygen_primes:3 生成多素数 RSA，但注意兼容性问题。
提取公钥：
openssl pkey -in private.pem -pubout -out public.pem
openssl rsa -pubout 去导公钥。它要求输入必须是 RSA 格式的私钥。如果你的私钥是 EC 或 Ed25519，这条命令直接报错。用 pkey 子命令通用的，兼容所有算法。
生成椭圆曲线密钥对呢？也很直接：
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ec_private.pem
openssl pkey -in ec_private.pem -pubout -out ec_public.pem
我个人项目里偏好 P-256，安全性够用，性能也比 P-384 好不少。不过如果是合规需求，像国密 SM2 或者某些政府项目指定要 P-384，那按标准走。但说实在的，P-256 在商用场景里绰绰有余。
代码方式（OpenSSL API）
命令行是调试用的，生产环境得走 API。下面这个片段，生成一个 EC 密钥对并存入 EVP_PKEY：
EVP_PKEY *pkey = NULL;
EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_EC, NULL);
EVP_PKEY_keygen_init(ctx);
EVP_PKEY_CTX_set_ec_paramgen_curve_nid(ctx, NID_X9_62_prime256v1);
EVP_PKEY_keygen(ctx, &pkey);
你注意到没？整个过程没有 rand()，没有 srand()。OpenSSL 内部已经通过 RAND_bytes() 从系统熵池吸够了随机性。你只管调用，不用操心种子的事。
- 通用数字签名：Ed25519（性能极好，密钥小）
- 兼容性优先：RSA 2048（所有设备都支持）
- Web 场景：P-256（浏览器支持好，TLS 1.3 推荐）
- 合规场景：RSA 3072 / P-384
还有一个细节：OpenSSL 3.x 改用了 Provider 架构，默认用 FIPS 兼容的底层。如果你在 3.x 上遇到 genpkey 报错，八成是没指定 -provider 参数。嗯，这里要注意 —— 生产环境升级 OpenSSL 主版本后，一定要回归测试密钥生成流程。
密钥生成的核心逻辑
说到这个流程图，其实核心就一件事：从物理不确定性到密码学密钥的单向管道。熵源是入水口，DRBG 是水泵，密钥生成是取水龙头。你只要保证入水口干净，后面的流程 OpenSSL 都帮你兜底了。
但有一个地方我吃过亏——EVP_PKEY_keygen 在多线程环境下并不线程安全。你要自己给每个线程创建独立的 EVP_PKEY_CTX，或者用锁保护。我当年在网关项目上并行生成上千个会话密钥，上来就垮，排查半天发现是线程间共享上下文导致内部随机状态被破坏。
最后啰嗦一句：密钥生成完了，私钥落盘 private.pem 的时候，记得用 chmod 600。文件权限这件事，我在客户现场见过太多次被低权限用户拖走的案例。你想想看，整个边界安全的基石，就靠这个 pemo 文件，结果权限是 644 —— 那和敞开门请人进来有啥区别？
- 熵源是否充足（entropy_avail > 128）
- 密钥文件权限是否 600
- 密钥格式是否符合目标系统要求（PEM / DER / PKCS#12）
- 是否备份了公钥但是不在代码里硬编码私钥路径
嗯，这就够了。密钥生成这块，拼的不是花哨算法，而是这些看得见摸得着的安全习惯。保证每个环节都有「熵」，保证每个出口都有「权限」，你的密钥边界就站稳了第一步。