从Diffie-Hellman输出中选择一个加密密钥

我在Java中实现了Diffie–Hellman key exchange，其中有一些大型组RFC 3526。我的输出是一个相当大的字节数组。 使用河豚键的输出的第一个448位（56字节）安全吗？我是否应该以任何方式转换字节，或者为键选取任何特定的字节？从Diffie-Hellman输出中选择一个加密密钥

来源

2010-10-06 Eric Lathrop

从理论的角度来看，不，它不安全。并不是我可以指出实际的攻击;但是Diffie-Hellman密钥交换的输出是由q元素组成的组中的一个元素，并且最多提供sqrt（q）安全性。截断该元素的编码部分看起来不是一个好主意...

“正确的”方法是使用单向密钥导出函数。简而言之，使用散列函数（如SHA-256）处理Diffie-Hellman输出，并使用散列结果作为关键字。关于Diffie-Hellman步骤，散列时间可以忽略不计。 Java已经包含了SHA-256和SHA-512的良好实现，并且如果你是在兼容非常古老的Java实现之后（例如随Internet Explorer 5.5提供的Microsoft JVM），那么你可以使用独立的SHA-2 Java实现如sphlib中的一个。或者可能从spec中重新实现（这并不难）：FIPS 180-3 (a PDF file)。

如果你需要超过128位的密钥，那么这意味着你是2050年左右的时间旅行者;假设您使用适当的对称加密方案，128位（远远）足以保护您。

说起来：河豚不是真的推荐了。它有64位块，这意味着当加密的数据长度达到几千兆字节时会产生麻烦，现在的大小并不那么大。你最好使用128位块密码，如AES。而且，在任何严重的对称加密系统中，您都需要密钥完整性检查。这可以通过使用诸如HMAC之类的MAC（消息认证代码）来完成，其本身构建在散列函数之上（然后再次，易于实现，并且在sphlib中有Java实现）。或者，甚至更好的是，在组合的加密/ MAC模式下使用AES，这将为您处理棘手的细节（因为恰当地使用分组密码是而不是容易）;查找CWC和GCM（两者均无专利权;后者已获NIST批准）。

来源

2010-10-06 12:02:22

非常丰富。我正在使用相当小包大小的UDP通信加密。从我读过的内容来看，Blowfish看起来媲美AES，但速度更快。我以前忽视了MAC，但现在我会仔细研究一下。 – 2010-10-07 00:40:17

对于与速度有关的任何事情，您都应该进行测量。与12年前的3DES相比，河豚被认为是快速的;但AES比3DES快得多。河豚也被称为有一个慢钥匙计划（改变一个新的钥匙是昂贵的）。从安全角度来看，AES要好得多，如果只是因为它被更多的密码学家仔细研究。 Blowfish设计师甚至制作了一个名为Twofish的新版本，该版本是成为AES的候选人（但是Rijndael被选中，并成为AES）。 – 2010-10-07 11:51:54

正确的方法是使用标准，而不是自己设计密码方案。 – Accipitridae 2010-10-13 08:57:55

您提出的解决方案取决于Diffie-Hellman交换的最重要的位是否是硬核。已知有一些小的结果表明最重要的位是不可预测的，但我不知道有足够强的文件表明您的方法是正确的。

但是，有几个关于从Diffie-Hellman密钥派生密钥的建议。例如一个不错的论文是NIST SP 800-135。到目前为止，这只是一个草案，可以找到here。但是，它审查了一些现有的标准。当然，使用标准总是比你自己开发更可取。

尽管Thomas Pornin的建议看起来合理，但它仍然是一个临时解决方案。为了安全起见，你应该不要使用它。相反，我会使用已经分析过的东西（例如，TLS版本1.2中使用的密钥派生方案）。

来源

2010-10-13 08:56:20 Accipitridae

从Diffie-Hellman输出中选择一个加密密钥

回答

相关问题