KDF和PBKDF的软件接口？

Question

我正在研究Krawczyk和Eronen 香港发展基金( RFC 5869 )的实现。从Krawczyk的原始论文中，他识别了密码提取与密钥推导:香港取方案中一个KDF的四个输入。这四项投入是：

1. 基键材料(秘密或种子)
2. 上下文信息(绑定安全参数)
3. 公共盐(可选，提供唯一性)
4. 导出键长度

我正在尝试协调KDF (例如，用于基于Diffie-Hellman的方案)和PBKDF (例如，用于将密码理解为关键材料)之间的差异，以提供通用的软件接口。我认为不同之处在于：

• KDF通常享有较高的熵种子，并且不使用迭代计数。
• PBKDF通常缺乏更高的熵种子，并且使用迭代计数来帮助进行一些攻击。有时它们使用目的字节，有时使用salt等等(目的字节似乎是上下文信息的专门化)。

将PBKDF添加到需求中，我认为列表如下：

1. 基键材料(秘密或种子)
2. 上下文信息(绑定安全参数)
3. 公共盐(可选，提供唯一性)
4. 派生键的长度(可选)
5. 迭代计数

我想确保安全参数以可扩展的方式很好地表示，这就引出了两个问题：

1. 公平地说，PBKDF是KDF的一个专门化吗？
2. 支持上述五个参数的软件接口是否足够？

(不好意思，我要进入软件设计领域。)我需要懂密码学的人的帮助和专业知识，而不是纯软件架构师)。

Answer 1

1. 公平地说，PBKDF是KDF的一个专门化吗？

好的。PBKDF是一个KDF，它使用密码/密码作为熵源。

OTOH，KBKDF (如果您想称之为基于键的KDF )也是KDF的专门化。一种不同的专业化，这就是为什么把它们当作一件事情来看待可能不是一个好主意。

1. 支持上述五个参数的软件接口是否足够？

有几个常见的参数缺失：

1. 许多密码哈希函数有第二个成本参数，指示将使用多少内存。(例如，氪星，大多数来自当前运行的密码散列竞赛。)
2. 另一个相对常见的参数是胡椒粉。如果需要，只需将其作为salt的一部分，但上下文信息参数也是如此。

我也不认为您的参数，即使有上述添加，是最好的方式来定义这样的界面。

首先，我不认为盐应该被排除在外，所以我不明白为什么它应该是可选的。

另一方面，与密码散列的使用方式相比，密钥派生函数的使用方式有很大的不同：

• 使用键派生函数，您将需要一个特定大小的键作为输出。
• 对于密码哈希，获取一个不透明的返回值非常有用，该值可以作为唯一的附加参数传递到验证例程: value ( password，combined_hash) (Cf )。(模块化密码格式。)这样，迭代计数、salt等就可以很容易地与散列一起存储，不同的哈希可以有不同的参数，随着攻击者计算能力的增加，可以随着时间的推移而提升强度。