📚 课程目录第2章密钥生成原理

密钥生成原理：随机数、KDF与冲突概率

聊密钥冲突，咱们得先把钥匙是怎么造出来的搞清楚。

密钥生成听起来像是个黑盒子——扔进去一堆数据，出来一串看似随机的字节。但里头的水很深。我个人习惯把密钥生成拆成三个核心环节：熵的收集、熵的拉伸、以及最终输出。任何一个环节出问题，冲突就可能找上门。

随机数生成：一切的基础

你想想看，如果真随机是完美的，那密钥冲突的概率几乎为零。但现实中，我们用的基本都是伪随机数生成器（PRNG）。

PRNG 的本质是一个确定性算法。给它一个种子，它就能吐出一长串看起来随机的序列。问题来了——如果两个 PRNG 用了同一个种子，或者种子空间太小，它们吐出来的“随机”序列就会一模一样。这就是冲突的根源之一。

我踩过的坑： 早期有个项目，团队直接用 time.time() 做种子。毫秒级精度，看着没问题对吧？但在高并发场景下，两个请求几乎同时到达，种子一模一样。结果生成的两把密钥完全相同。排查了一整天才找到这个 bug。

现代系统一般用操作系统提供的 CSPRNG（密码学安全伪随机数生成器），比如 Linux 的 /dev/urandom。它能从硬件噪声、中断时间等收集真正的熵，保证种子不可预测。

真随机数生成器（TRNG）：依赖物理过程，如电路热噪声、量子效应。慢，但不可预测。
伪随机数生成器（PRNG）：依赖算法和一个初始种子。快，但种子空间有限。
CSPRNG：带密码学安全属性的 PRNG。不仅统计上随机，还得能抵抗攻击者的逆向推导。

密钥派生函数（KDF）：熵的魔术师

有了熵之后，我们通常不会直接用它。为什么呢？因为原始熵可能不够均匀，或者长度不满足要求。这时候就需要 KDF 登场了。

KDF 的核心任务是把输入的“弱熵”（比如用户密码、共享秘密）转换成“强密钥”。它通过反复应用哈希函数或分组密码来混合位，打散任何统计数据上的规律。

我见过一个经典案例：有人直接用 SHA256 对共享秘密做哈希，然后截取前 16 字节当 AES 密钥。这其实不够安全。为什么？因为缺少盐值（salt），而且没有足够的工作因子来抵御暴力破解。

    KDF 的三个关键参数：

    盐值（Salt）：一个随机值，防止彩虹表攻击。同一密码，不同盐值产出不同密钥。
迭代次数：越高，暴力破解成本越大。但也意味着生成密钥更慢。
输出长度：你需要多长的密钥？KDF 可以按需扩展。

常用的 KDF 包括 PBKDF2、scrypt、Argon2。Python 标准库 hashlib 就提供了 PBKDF2 实现。

import hashlib
import os

def derive_key(password: str, salt_length: int = 16, iterations: int = 100000) -> bytes:
    salt = os.urandom(salt_length)
    key = hashlib.pbkdf2_hmac(
        'sha256',
        password.encode('utf-8'),
        salt,
        iterations,
        dklen=32  # 32 字节 = 256 位 AES 密钥
    )
    return key, salt

注意这里的 os.urandom。它是 CSPRNG，用来生成盐值。盐值的存在确保：即使两个用户用相同的密码，最终得到的密钥也完全不同。

警告：不要自己拼凑 KDF！
我曾在代码 review 时发现有人自己写个循环做 1000 次 SHA256 就当 KDF 用。这在密码学上是错的。缺少盐值、缺少内存硬性、迭代次数不合理。请用标准库或经过审计的密码学库。

还有一类 KDF 叫 HKDF（HMAC-based Key Derivation Function）。它适用于密钥已经有一定熵的场景（比如 ECDH 协商后的共享秘密），用来提取和扩展。它更轻量，不引入大量迭代，但需要确保输入已经有了足够的熵。

碰撞概率与生日攻击

冲突的根本原因，说白了就是空间不够大。

生日攻击利用了概率论中的“生日悖论”。如果密钥空间是 N 位，随机生成大约 2^(N/2) 个密钥后，出现一次冲突的概率就接近 50%。也就是说，128 位 AES 密钥空间是 2^128，但生成大约 2^64 个密钥后，你就有对半概率碰到一个重复的。

你可能会问：“2^64 听起来很大啊，现实中能碰到吗？”嗯，其实比你想象的更容易。在分布式系统中，如果你在多台机器上并行生成密钥，并且种子管理不当，局部碰撞可能提前出现。

密钥长度（位）	安全容量（2^(N/2)）	实际碰撞风险
64	2^32 (~40 亿)	高，不适合大规模系统
128	2^64 (~1.8×10^19)	可接受，但有理论风险
256	2^128 (~3.4×10^38)	极低，当前计算能力下安全
512	2^256 (~1.1×10^77)	理论安全，但性能开销大

我在项目中遇到过有人用 64 位随机数做 session ID。系统每天生成几百万个 session，结果不到一周就出现重复了。这就是没有计算碰撞概率的后果。

如何降低冲突概率？

经验告诉我，有四个方向可以出力：

扩大密钥空间：别省那几位。现代系统至少用 128 位，建议 256 位。
保证种子质量：用操作系统提供的 CSPRNG。别用自己的伪随机库。
使用盐值：即使同一份共享秘密，每次派生密钥都加不同的盐值。
检查重复：在数据库里加唯一索引，插入前先查一下。运行时防御。

    总结一下我的核心理念：

    “熵源决定下限，KDF 决定上限，冲突概率决定你是否晚上能睡着觉。”

我曾经在线上环境碰到过一个特别隐蔽的问题：一台虚机重启后，CSPRNG 的熵池被快速耗尽，导致 os.urandom 阻塞。这是个运维坑，但也提醒我们：密码学安全需要系统级关注，不单是代码的事。

好了，关于密钥生成原理，核心就是这些。记住：随机性不是玄学，是数学。理解它，你才能在设计系统时避开那些暗礁。