Java 从Diffie Hellman输出中选择加密密钥

我用Java实现了一些来自的大型组。我的输出是一个相当大的字节数组将输出的前448位（56字节）用于河豚键安全吗？我应该以任何方式转换字节，还是为键选择任何特定字节？

从理论角度看，不安全。并不是说我能准确地指出一次真正的攻击；但是Diffie-Hellman密钥交换的输出是由q元素组成的组的一个元素，最多提供sqrt（q）安全性。截断该元素的部分编码看起来不是一个好主意

“正确”的方法是使用单向键派生函数。简单地说，使用一个好的散列函数（如）处理Diffie Hellman输出，并将散列结果用作键。对于Diffie-Hellman步骤，哈希时间可以忽略不计。Java已经包含了SHA-256和SHA-512的优秀实现，如果您希望与非常旧的Java实现（例如Internet Explorer 5.5附带的Microsoft JVM）兼容，那么您可以使用独立的SHA-2 Java实现，如中的实现。或者可能从规范中重新实现它（这并不难）：

如果您的密钥需要超过128位，那么这意味着您是2050年左右的时间旅行者；假设您使用的是正确的对称加密方案，128位就足以暂时保护您

---

说到这里：河豚已经不再被推荐了。它有64位的数据块，这意味着当加密数据长度达到几GB时会出现问题，而现在的数据长度已经不那么大了。您最好使用128位分组密码，例如。此外，在任何严格的对称加密系统中，都需要密钥完整性检查。这可以通过MAC（消息认证代码）来实现，例如，它本身构建在一个哈希函数上（同样，很容易实现，sphlib中有一个Java实现）。或者，更好的是，在组合加密/MAC模式下使用AES，这将为您处理棘手的细节（因为正确使用分组密码并不容易）；查找和（两者都是无专利的；后者已获得NIST的批准）。

您提出的解决方案取决于Diffie-Hellman交换的最重要位是否为核心。有一些已知的小结果表明，最重要的位是不可预测的，但我不知道有哪篇论文足以证明你的方法是正确的

然而，有几个建议从Diffie-Hellman密钥派生密钥。 好的纸张是NIST SP 800-135。到目前为止，这只是一份草稿，可以找到。然而，它审查了一些现有标准。当然，使用标准总是比自己开发标准更好

---

尽管托马斯·博宁的建议看起来合理，但它仍然是一个临时解决方案。为了安全起见，你可能不应该使用它。相反，我会使用已经分析过的内容（例如TLS 1.2版中使用的密钥派生方案）。

非常有用。我正在对数据包大小相当小的UDP通信使用加密。据我所知，河豚看起来与AES相当，但速度要快得多。我以前忽略了Mac电脑，但现在我要仔细看看。对于任何与速度有关的东西，你都应该测量一下。大约12年前，与3DES相比，河豚被认为速度快；但是AES比3DES快得多。众所周知，河豚的按键时间很慢（换一把新的按键很昂贵）。从安全性的角度来看，AES要好得多，如果只是因为它被更多的密码学家仔细检查过的话。Blowfish设计师甚至制作了一个新版本，名为Twofish，它是成为AES的候选版本（但Rijndael被选为AES）。正确的方法是使用标准，而不是自己设计密码方案。“快速”是一把双刃剑：有利于用户，也有利于暴力。此外，必须考虑优化的HW（ASIC / FPGA）和SW实现后者。