使用 HKDF 的目的是什么？答案

【问题标题】：What is the purpose of using HKDF?使用 HKDF 的目的是什么？
【发布时间】：2021-01-31 10:26:21
【问题描述】：

我看到了一个代码 sn-p，它通过以下步骤生成 AES 密钥：

生成一个 16 字节的随机值数组。

SecureRandom random = new SecureRandom();
byte[] key = new byte[16];
random.nextBytes(key);

将 HKDF 应用于密钥以生成新的加密密钥。

encrypt_key = KeyDerivation.hkdfSha256(Key,
                           /* inputSalt =*/ null,
                           hkdfInfoString.getBytes("UTF-8"),
                           16);

我很困惑为什么我们需要两个步骤。 SecureRandom 似乎为密钥提供了足够的熵，对吧？两个问题：

我们可以直接使用 1) 中的 key 进行 AES 加密吗？
2) 中的空盐有什么影响？我正在考虑可能额外的步骤 2）是为了保护被泄露的密钥（只是一个猜测）。如果是，空盐是否使目的无效？因为我们可以预先计算出 HKDF 的输入密钥材料与其输出之间的联系。

HKDF 声称盐是可选的，尽管使用随机盐确实可以增强它。我很困惑什么时候需要 HKDF（尤其是没有盐）。如果我们已经有一个具有足够熵的密钥，为什么我们需要它？如果我们有一个没有足够熵的弱密钥，HKDF（没有盐）如何帮助这种情况？我在想象攻击者可以预先计算出弱密钥到生成密钥之间的映射，对吧？

【问题讨论】：

您没有提及您的来源，因此可靠性和上下文不清楚。但对我来说，它看起来像是从一个主密钥派生多个密钥，参见例如here 和 RFC5869 也解释了盐的作用/功能。
是的，16 字节的 SecureRandom 应该包含几乎 128 位的熵，因此您不一定需要 HKDF 来生成单个 128 位 AES 密钥。但是，如果您想从单个全熵 128 位种子生成两个这样的密钥怎么办？如果想同时生成 AES 密钥和 MAC 密钥怎么办？如果您的密钥材料来源是具有 255 位熵的 ECDH 密钥协议怎么办？安全工程方面，将熵的获取与秘密的生成分开具有显着优势。 HKDF 提供了允许这样做的安全属性。

标签： cryptography kdf hkdf

【解决方案1】：

我们可以直接使用 1) 中的密钥进行 AES 加密吗？

是的，你可以。但是，您需要经常更改密钥是有原因的，例如算法/方案限制，不泄漏（主）密钥，扩展密钥材料，派生多个密钥和/或IV值等......以及任何你首先需要KBKDF的东西（HKDF是一个哈希基于密钥的密钥推导函数）。

但是，如果只有一个 128 位密钥是从另一个 128 位密钥派生的，那么我看不到太多好处。这可能有用的唯一情况是，如果您不信任 SecureRandom 实现的安全性，因为当攻击者尝试猜测（显然很弱）的状态时，KDF 会放置另一层 HMAC 以突破随机数生成器。

当然，正如您在问题中指出的那样，攻击者仍然可以猜测随机发生器的状态，但至少攻击者无法通过例如反转计算或获取有关状态的统计信息。

2) 中的空盐有什么影响？我正在考虑一个额外的步骤 2) 是为了保护被泄露的密钥（只是一个猜测）。如果是，空盐是否使目的无效？因为我们可以预先计算出 HKDF 的输入密钥材料和它的输出之间的联系。

不，无论盐是否存在，密钥派生函数都是单向的。该盐用于 HKDF 的安全证明中。但是，实际上并不需要提供足够的安全性。如果您可以添加/存储/传输盐，那么它将有利于安全性，但是有很多 KBKDF 首先（明确地）不允许使用盐。另一方面：像 PBKDF2 这样的基于密码的 KDF 确实需要一个盐来保证安全。

【讨论】：

谢谢！我真的很感谢你的回答。我还不清楚一件事。虽然函数是单向的，但是如果输出泄露，我们可以通过彩虹表搜索输入吗？我的理解是没有盐（随机数），我们可以很容易地预先计算彩虹表来破坏它，不是吗？
只有当输入类似于密码时，Rainbow 表才真正有效。一旦你开始谈论具有 128 位随机性的全尺寸键，那么构建这样的表就不再可行（无论是在所需内存方面还是在查找操作数方面）。