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

【问题标题】：continued encryption with diffie-hellman shared key使用 diffie-hellman 共享密钥继续加密
【发布时间】：2011-12-17 15:57:27
【问题描述】：

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

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

我打算使用 Blowfish（也可以是另一种密码，与问题无关）

现在要加密 aes 密钥，比如说河豚，我必须使用一个名为 SecretKeySpec 的类（我正在使用 javax.crypto 的东西）构建一个用于加密的密钥，它在构造函数中使用一个 byteArray 来构建密钥。

来自 DH 的共享密钥是 128 位 BigInteger。好吧，现在我可以将我的共享密钥解释为一个 byteArray（这仍然给我 16Bytes 中的 128 位 [其中数字被解释为 8 位数据的帧]）

所以我的问题是，我的钥匙到底有多强？

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

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

如果我错了，共享密钥的密钥大小让我放心最终使用 128 位 SecretKey 进行加密？

【问题讨论】：

请注意，使用 Blowfish 加密 AES 密钥会将您的协议强度降低到 AES 或 Blowfish 的最弱。虽然在 AES 发布后发现了一些针对 AES 的攻击，但我仍然会打赌 AES is stronger（并且更好地检查）而不是 Blowfish。
@sarnold：感谢您的注意，我知道这个问题。 Blowfish 只是一个例子，也许我也使用 AES。我还不确定是否需要在该步骤传输更多信息，所以我计划使用流密码运行，以摆脱固定大小的 aes 强制我使用（或填充我的数据）。我仅限于一个以太网数据包，所以我可以避免更好的每个字节。 :)

【解决方案1】：

Crypto++ 网站建议使用至少 3072 位的 p（或对于 ECC 实现使用 256 位）来传输 128 位 AES 密钥。

您可能希望研究http://www.keylength.com/en/compare/ 提供的参考资料，以获取有关比较不同算法之间的密钥长度的更多信息。

【讨论】：

这是一个非常棒的链接。非常感谢！在我关闭问题之前，我正在等待是否在此处发布更多类似的建议。
我错过了，为什么 3072 位被认为是“安全的”传输 128 位 AES 密钥。也许我还没有找到合适的地方。希望有人能启发我。
这是一个“计算复杂性”的问题——您试图将best known attacks against AES 的复杂性（对于 128 位 AES 的密钥恢复目前为 2^126 左右）与针对discrete logarithm 问题的最著名的攻击。正如您所推测的那样，在整数上，并非每个位都独立于其他位 - ECC 通过减少位之间的相关性对此进行了改进，但位仍然不是完全独立的。
离散对数下key是什么意思？该组匹配 3072，但 256 匹配密钥，这应该告诉我什么？
啊好吧，我错过了参考。将在该主题上自己进行一些研究，再次非常感谢您。

【解决方案2】：

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

【讨论】：