密钥派生函数（KDF）概述

聊到密钥派生函数，我得先说说自己刚入行时踩过的一个坑。那时候我负责做一个用户登录系统，觉得把密码直接哈希一下存起来就完事了。结果被安全审计的人骂得狗血淋头——他们问我：「你这哈希函数跑一次只要几微秒，攻击者每秒能试几百万个密码，你扛得住吗？」

嗯，从那以后我才真正理解了 KDF 的价值。

为什么需要 KDF？

说白了，现实世界里的密码和密钥，跟密码学算法要求的「完美密钥」差距太大了。你想想看：

• 用户密码：长度短、熵值低，通常只有 20-30 比特的随机性
• DH 协商的共享秘密：虽然数学上安全，但分布不均匀，存在大量「0」比特
• 原始随机数：可能不符合特定算法的密钥格式要求（比如 DES 的奇偶校验位）

KDF 要解决的核心问题就三个：

1. 熵提取：把低熵的输入「拉伸」成高熵的输出
2. 长度适配：把任意长度的输入变成你需要的固定长度密钥
3. 抗暴力破解：通过增加计算成本，让攻击者试密码的速度慢下来

KDF 的应用场景

我在实际项目中，KDF 主要出现在两个地方。咱们一个一个说。

场景一：密码存储

这是最经典的应用。我记得 2017 年帮一家金融科技公司做安全审计，他们的用户表里存的还是 MD5 哈希。我跟他们技术总监说：「你这密码库，拿到手就是明文。」他不信，我当场用彩虹表跑了一下，80% 的密码在 10 分钟内就还原出来了。

正确的密码存储流程应该是这样的：

注册时：
用户密码 → KDF(密码 + 盐) → 存储哈希值和盐

登录时：
用户输入密码 → KDF(输入密码 + 存储的盐) → 比对哈希值

这里有几个关键点：

• 必须加盐：每个用户用不同的随机盐，防止彩虹表攻击
• 必须慢：KDF 的计算参数要调得足够慢，让暴力破解变得不划算
• 必须抗 GPU：选择内存硬化的算法，让 GPU 并行计算的优势失效

算法	设计目标	内存消耗	推荐场景
bcrypt	抗 GPU 并行	固定 4KB	Web 应用密码存储
scrypt	内存硬化	可配置（通常 16MB+）	高安全要求的密码存储
Argon2id	综合最优	可配置	新项目首选（2015 年密码哈希竞赛冠军）
PBKDF2	标准兼容	极低	兼容旧系统（不推荐新项目）

场景二：密钥协商

另一个常见场景是密钥协商后的派生。比如你和服务器通过 ECDH 交换了一个共享秘密，但这个秘密不能直接当对称密钥用——原因我之前说了，分布不均匀。

标准的做法是用 KDF 把共享秘密「提炼」成真正的会话密钥：

共享秘密 = ECDH(私钥, 对方公钥)
会话密钥 = KDF(共享秘密 || 协议标识 || 会话ID || 随机数, 输出长度=256位)

这里 KDF 还承担了一个额外职责——上下文绑定。把协议标识、会话 ID 这些信息掺进去，就能保证：

• 不同协议之间派生出的密钥不同
• 不同会话之间派生出的密钥不同
• 即使共享秘密相同，最终密钥也不同

我参与过的一个 IoT 项目就吃过这个亏。设备和服务端用同一个共享秘密派生了加密密钥和认证密钥，但没做上下文分离。结果加密报文和认证标签用的密钥一模一样——攻击者只要拿到一个，另一个也等于暴露了。

KDF 的核心逻辑

说了这么多，咱们用一张图把 KDF 的整体逻辑串起来：

这张图把 KDF 的输入、处理、输出和安全边界都画清楚了。你注意看那个红色虚线框——它代表安全边界。边界之外的东西（输入、盐、参数）攻击者可能拿到，但边界之内的 KDF 核心必须保证：就算攻击者拿到了输出，他也推不出输入。

选型建议

最后，我根据自己这些年踩过的坑，给几个实际选型建议：

• 密码存储：无脑选 Argon2id。如果环境不支持，退而求其次用 bcrypt。别用 PBKDF2，除非你要兼容十几年前的旧系统。
• 密钥协商派生：用 HKDF。它是 HMAC 基础上设计的，安全性有充分证明，而且 RFC 5869 把各种细节都规定好了。
• 参数调优：别用默认参数。我见过太多项目直接用库的默认值，结果要么太慢（用户登录要等 3 秒），要么太快（攻击者一秒试 10 万个密码）。花点时间做性能测试，找到你的硬件能承受的「最慢可接受值」。