Java 使用diffie-hellman共享密钥继续加密

我目前正在研究一个协议，它使用Diffie Hellman进行密钥交换。 我收到一个数据包，它由一个aes-128加密部分和一个128位DH公钥组成

在协议的最后一步中，aes密钥被发送到网络中的另一个对等方。 此aes密钥应使用128位强加密密钥加密

我计划使用河豚（也可以是另一种密码，对这个问题并不重要）

现在要加密aes密钥，比如说blowfish，我必须使用一个名为SecretKeySpec的类（我使用javax.crypto stuff）为加密构建一个secretkey，该类在构造函数中使用一个byteArray来构建secretkey

DH的sharedkey是一个128位的BigInteger。 好了，现在我可以将共享密钥解释为byteArray（它给了我16字节中的128位[其中数字被解释为8位数据的帧]）

所以我的问题是，我的钥匙到底有多结实

因为我只使用数字作为byteArray的输入，所以会有任何影响吗（这会以任何方式限制键空间吗？）

我认为情况并非如此，但我不是100%确定。 也许有人能算算，证明我是对还是错

---

如果我搞错了共享密钥的密钥大小，那么我最终可以使用128位SecretKey进行加密？

在这里，DH不是DH的专家，但在我看来，以n位表示的共享密钥的DH密钥空间略小于2^n

该网站建议使用最小的

p

3072位（或256位用于实现）来传输128位AES密钥

---

您可能希望研究在中提供的参考资料，以了解有关比较不同算法的密钥长度的更多信息。

请注意，使用Blowfish加密AES密钥会将协议强度降低到AES或Blowfish中最弱的一个。虽然在AES出版后发现了一些针对AES的攻击，但我还是打赌（而且比河豚更仔细研究）。@sarnold:谢谢你的提示，我知道这个问题。河豚只是一个例子，也许我也使用AES。我还不确定是否需要在这一步进行更多的传输，因此我计划使用streamcipher，以消除aes强制我使用的固定大小（或填充数据）。我仅限于一个以太网数据包，因此每个字节都可以避免使用更好的数据包。：）这是一个非常棒的链接。非常感谢你！在我结束这个问题之前，我正在等待是否有更多类似的建议。我不知道为什么3072位被认为是传输128位AES密钥的“安全”位。也许我还没有找到合适的地方。希望有人能给我一些启发。这是一个“计算复杂性”的问题——你试图将（目前128位AES的密钥恢复为2^126左右）的复杂性与针对该问题的最著名的攻击进行比较。正如您所猜测的，在整数上，并非每个位都独立于其他位——ECC通过减少位之间的相关性来改进这一点，但位仍然不是完全独立的。离散对数下的键是什么意思？该组匹配3072，但键为256，这应该告诉我什么？啊，好吧，我错过了参考。我会自己做一些关于这个主题的研究，再次非常感谢。看起来是这样，sarnold发布的链接告诉你应该至少使用3072位p。但为什么，我还没发现：(