4、密钥生成：随机数生成、熵源、密钥长度与算法选择（AES-256， RSA等）

密钥生成，说白了就是整个TDE体系里最基础也是最要命的一环。你想想看，就算你的加密算法再强，密钥管理流程再规范，只要密钥本身是“弱”的——比如可预测、熵不够、长度不达标——那整个系统就是纸糊的。我在项目中见过太多类似的情况，底层密钥生成没做好，上层再怎么补都补不回来。

4.1 随机数生成：系统到底在用什么产生“不确定性”

计算机是确定性的机器，要让它吐出真正的随机数，其实挺难。我们日常用的随机数，基本分两类：

  • 真随机数：从物理噪声源里提取，比如热噪声、光电效应、用户鼠标移动、磁盘读写时间差。这些没法预测，适合做密钥。
  • 伪随机数：基于一个初始种子，通过算法（比如 CTR_DRBG, Hash_DRBG）扩展出来。如果种子够随机，结果也够安全。但种子泄露，一切白搭。

我个人的习惯是：能用硬件随机数生成器（比如 Intel RDSEED、RDRAND）就尽量用。这些指令直接读取芯片上的物理熵源，比纯软件实现的要放心得多。

核心原则：TDE 里所有密钥材料，必须来源于符合 SP 800-90A/B/C 规范的随机数生成器。别用 rand() 或游戏里的随机，那玩意儿做加密是要出事的。

4.2 熵源：足够乱，才是真的安全

熵源，就是系统用来“变乱”的资源。你可以把它理解成随机数生成器的原料。如果说随机数生成器是一台洗衣机，熵就是扔进去的那堆脏衣服——越乱，洗出来的效果越随机。

常见的熵源有哪些？

  • 硬件熵源：CPU 内置的 RNG、TPM 芯片、专用熵源芯片。我最推荐。这类源通常有厂商自测报告，质量可控。
  • 环境噪声：麦克风采集的底噪、摄像头传感器像素噪声。嗯，这个有点偏门，我在IoT设备上见过用麦克风当熵源的，效果居然还行。
  • 系统熵池：Linux 下的 /dev/random 和 /dev/urandom。前者阻塞，后者非阻塞。TDE 场景我建议用 /dev/urandom 或者 getrandom() 系统调用，只要系统启动后熵池积累够就行。

我曾经遇到过一个客户，他的虚拟机没有硬件熵源，内核熵池一直处于低熵状态。结果呢？生成的密钥在很短时间后就出现了重复——那真是灾难性的。所以，请务必在生产环境里为虚拟机挂载一个 virtio-rng 或类似的虚拟熵源设备。

那熵怎么评估？ 一个简单粗暴的方法：看熵池的大小。Linux 下可以用 cat /proc/sys/kernel/random/entropy_avail 看剩余熵量。如果这个值一直不到 1000，你得警惕。

4.3 密钥长度与算法选择

选密钥长度和选算法，其实是绑定在一起的事。TDE 加密主要面对两类场景：对称加密（数据量大、速度要快）和非对称加密（密钥分发、签名、身份认证）。

4.3.1 对称加密：AES-256 几乎是唯一选项

我个人习惯：只要性能允许，直接用 AES-256。128 位当然也安全，但 256 给了你更好的抗量子计算前预攻击的缓冲。你想想看，密钥长度多一倍，理论上暴力破解的难度就是 2128 倍——这个鸿沟足够让任何攻击者绝望。

算法 密钥长度 模式 推荐场景
AES-256 256 位 GCM / XTS 数据库加密、文件加密、磁盘加密
AES-128 128 位 GCM 性能敏感的嵌入式场景
SM4 128 位 CTR / GCM 国密合规场景
ChaCha20 256 位 Poly1305 无硬件 AES 指令加速的移动端

这里插一句：模式选择也很重要。ECB 模式千万不能用——它会把同样的明文块加密成同样的密文块，这等同于没有加密。我自己在项目里主力用 GCM，自带认证，省去额外算 MAC 的麻烦。

4.3.2 非对称加密：RSA 正在边缘化，但还不能完全抛弃

RSA 我实际已经用得越来越少了。说实话，在 TDE 体系里，它的主要工作是加密对称密钥（密钥封装），而不是加密大量数据。我个人现在的选择是：

  • 密钥分发和加密：用 ECC（椭圆曲线密码学），尤其是 NIST P-256 或者 Curve25519（X25519）。同样的安全强度，ECC 的密钥长度比 RSA 短得多，运算也快。
  • 签名：ECDSA（P-256）或者 Ed25519。RSA 签名太胖，验签也慢。
  • 如果必须用 RSA：密钥长度至少 3072 位，最好 4096 位。2048 位虽然还没被破解，但在量子威胁面前已经不推荐用于长期安全。

避坑建议：在生成 RSA 密钥时，永远不要直接用 OpenSSL 默认的指数。我曾经踩过指数太小导致计算异常的坑。用 openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -pkeyopt rsa_keygen_pubexp:65537 这个配方，稳得很。

4.4 密钥生成的完整流程（附 SVG 图）

好了，把上面所有的点串起来，TDE 里一次安全的密钥生成大致走这么几步：

  1. 收集熵源：从硬件 RNG 或内核熵池收集足够多的随机比特。
  2. 种子：用这些比特构建一个安全的种子。
  3. 实例化 DRBG（确定性随机数生成器）：选一种算法（如 CTR_DRBG），初始化。
  4. 生成密钥字节：从 DRBG 中请求指定长度的字节序列。
  5. 格式化：按密钥规范（如 PKCS#8、RAW）封装。
  6. 输出：交给密钥管理服务（KMS）存入安全存储。

下面这张图，把流程和关键要素都整理了。你可以对照着理解每一步。

密钥生成流程与核心要素 熵源收集 硬件 RNG / 系统熵池 / 环境噪声 DRBG 实例化 算法：CTR_DRBG / Hash_DRBG 种子来自熵源 密钥生成 & 格式化 AES-256 / ECC P-256 RSA-4096 / SM4 安全存储 / KMS 密钥库 / HSM / 密钥管理 服务 关键交付物 对称密钥（256位）— 非对称密钥对（私钥 PKCS#8）— 元数据（算法标识、密钥ID、创建时间） ⚠ 必须避免的错误 × 使用非加密级随机数（rand() / /dev/urandom 未初始化） × 熵源耗尽仍继续生成密钥 — × 密钥长度不满足安全标准 — × 未做密钥完整性校验 实际操作中常用的命令 / 示例 AES-256: openssl rand 32 | base64 — ECC P-256: openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256

4.5 实际操作中的命令示例（Linux环境）

我放几个我每天都会用到的命令，你可以在自己的环境里试试：

# 1. 生成 256 位（32 字节）的对称密钥，输出为 hex
openssl rand -hex 32

# 2. 生成 ECC P-256 私钥，并提取公钥
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out tde_priv.pem
openssl pkey -in tde_priv.pem -pubout -out tde_pub.pem

# 3. 生成 RSA 4096 位私钥
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -pkeyopt rsa_keygen_pubexp:65537 -out rsa_priv.pem

# 4. 检查熵池状态
cat /proc/sys/kernel/random/entropy_avail

我个人习惯：在生成完密钥后，立刻跑一个完整的密钥完整性校验——也就是用密钥加密一段已知的明文，再解密回来，对比是否一致。这一步看着简单，但在生产环境里发现过几次密钥生成后存储损坏的情况。别省。

嗯，到这里，密钥生成这一章的核心内容基本就透了。熵源要乱，算法要对，长度要够——这三条你记住了，后面无论做什么密钥生命周期管理，都稳了。

← 上一章 📖 返回目录 下一章 →