从 Diffie-Hellman 输出中选择加密密钥
我在 Java 中与一些来自 < a href="http://www.ietf.org/rfc/rfc3526.txt" rel="noreferrer">RFC 3526。我的输出是一个相当大的字节数组。 将输出的前 448 位（56 字节）用作河豚密钥是否安全？我应该以任何方式转换字节，还是为密钥选择任何特定字节？
I implemented Diffie–Hellman key exchange in Java with some large groups from RFC 3526. My output is a fairly large array of bytes. Is it safe to use the first 448 bits (56 bytes) of the output for a blowfish key? Should I transform the bytes in any way, or pick any specific bytes for the key?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从理论上来说，不，它不安全。并不是说我可以查明真正的攻击；但 Diffie-Hellman 密钥交换的输出是由 q 个元素组成的组中的一个元素，最多提供 sqrt(q) 安全性。截断该元素的部分编码看起来不是一个好主意......
“正确”的方法是使用单向密钥派生函数。简而言之，使用良好的哈希函数处理 Diffie-Hellman 输出，例如 SHA-256 并使用哈希结果作为密钥。对于 Diffie-Hellman 步骤，哈希时间可以忽略不计。 Java 已经包含了 SHA-256 和 SHA-512 的良好实现，如果您希望与非常旧的 Java 实现（例如 Internet Explorer 5.5 附带的 Microsoft JVM）兼容，那么您可以使用 SHA-2 的独立 Java 实现例如 sphlib 中的那个。或者可能从规范中重新实现它（这并不难）： FIPS 180-3（PDF 文件）。
如果您的密钥需要超过 128 位，那么这意味着您是 2050 年左右的时间旅行者；假设您使用适当的对称加密方案，128 位（远远）足以暂时保护您。
说到这里：河豚已经不再推荐了。它有 64 位块，这意味着当加密数据长度达到几 GB 时就会出现问题，而现在这个大小还不算大。您最好使用 128 位分组密码，例如 AES。此外，在任何严格的对称加密系统中，您都需要密钥完整性检查。这可以通过 MAC（消息身份验证代码）来完成，例如 HMAC，它本身构建通过哈希函数（话又说回来，很容易实现，并且 sphlib 中有一个 Java 实现）。或者，更好的是，在组合加密/MAC 模式下使用 AES，这将为您处理棘手的细节（因为正确使用分组密码并不容易）；查找 CWC 和 GCM（两者均无专利；后者已获得 NIST 批准）。
From a theoretical point of view, no, it is not safe. Not that I could pinpoint an actual attack; but the output of a Diffie-Hellman key exchange is an element of a group consisting in q elements and offering sqrt(q) security at most. Truncating parts of the encoding of that element does not look like a good idea...
The "proper" way is to use a one-way key derivation function. In simple words, process the Diffie-Hellman output with a good hash function such as SHA-256 and use the hash result as key. Hashing time will be negligible with regards to the Diffie-Hellman step. Java already includes fine implementations of SHA-256 and SHA-512, and if you are after compatibility with very old Java implementations (e.g. the Microsoft JVM which was coming with Internet Explorer 5.5) then you can use an independent Java implementation of SHA-2 such as the one in sphlib. Or possibly reimplement it from the spec (that's not hard): FIPS 180-3 (a PDF file).
If you need more than 128 bits for your key then this means that you are a time-traveler from year 2050 or so; 128 bits are (much) more than enough to protect you for the time being, assuming that you use a proper symmetric encryption scheme.
Speaking of which: Blowfish is not really recommended anymore. It has 64-bit blocks, which implies trouble when the encrypted data length reaches a few gigabytes, a size which is not that big nowadays. You would be better off using a 128-bit block cipher such as the AES. Also, in any serious symmetric encryption system you will need a keyed integrity check. This can be done with a MAC (Message Authentication Code) such as HMAC, itself built over a hash function (then again, easy to implement, and there is a Java implementation in sphlib). Or, even better, use the AES in a combined encryption/MAC mode which will handle the tricky details for you (because using a block cipher properly is not easy); lookup CWC and GCM (both are patent-free; the latter has been approved by NIST).
您提出的解决方案取决于 Diffie-Hellman 交换的最高有效位是否是硬核。有一些已知的小结果表明最重要的位是不可预测的，但我不知道有一篇论文足以证明您的方法是正确的。
然而，有几个关于从 Diffie-Hellman 密钥派生密钥的建议。
例如，一篇不错的论文是 NIST SP 800-135。到目前为止，这只是一个草案，可以在此处找到。然而，它审查了一些现有标准。当然，使用标准总是比自己开发更好。
尽管 Thomas Pornin 的提议看起来很合理，但它仍然是一个临时解决方案。为了安全起见，您可能不应该使用它。相反，我会使用已经分析过的东西（例如 TLS 版本 1.2 中使用的密钥派生方案）。
The solution that you propose depends on whether the most significant bits of a Diffie-Hellman exchange are hard core. There are some small results known that show that the most significant bits are unpredictable, but I'm not aware of a paper that is strong enough to show that your approach is correct.
However, there are several proposals for a key derivation from Diffie-Hellman keys.
E.g. a nice paper is NIST SP 800-135. So far this is only a draft and can be found here. However, it reviews some existing standards. Of course, using a standard is always preferable to develop it yourself.
While Thomas Pornin's proposal looks reasonable it is nonetheless an ad hoc solution. And to be on the safe side you should probably not use it. Rather I'd use something that has been analyzed (e.g. the key derivation scheme use in TLS version 1.2).