Java 确定私钥（Diffie Hellman）

我遇到了一个挑战，它与测试朋友的加密过程有关

这是一个Diffie-Hellman交换过程，以下是已知的变量/常量：

• P

  ，

  G

• 我生成的私钥（变量）
• 我生成的公钥（变量）
• 收件人的公钥（常量）

查看我的私钥时，

p

和

G

都在其中。例如，第一个“x”字节似乎与任何内容都没有关系，接下来的“y”字节是

P

，接下来的两个字节是静态的，接下来的“z”字节是

G

，其余的是可变的

这个过程是加密一个文件，并将其发送到一个设备，该设备将对其进行解密-我的攻击思路如下：

尝试复制秘密共享密钥。这里的问题是，只要我知道我生成的私钥就可以了，在这种情况下，我不知道他给我的文件

尝试查找收件人的私钥。在这里，我可以用蛮力强行闯入——但如果我没有某种超级计算机，那就要花很长时间

---

在尝试攻击这一点时，还有其他选择吗？

我可能应该闭嘴，但对于那些对Diffie Hellman感兴趣的人来说，这也是一个学习一些东西的机会：

Diffie-Hellman生成共享密钥的简单实现容易受到中间人攻击。然而，DH的大多数实现通过在Alice和Bob之间添加身份验证来正确地解决这个问题

如果您的DH实现允许声明一个新的PQG集，您可以请求另一个对等方使用一个新的弱集。如果Bob未验证此集合的质量，则它容易受到攻击

＞P＞DH要求爱丽丝发送x= G^ x，如果鲍伯不检查X的质量，则是脆弱的，因为EVE在中间可以显著降低密钥的可能值空间。

如果您的实现不记得泄露的密钥，Eve可以重新使用它们

如果您的实现不记得泄露的证书，Eve可以重新使用它们

如果您的实现没有检查证书，Eve肯定会玩得很开心

---

在处理安全协议时，必须非常精确地确定哪些数据存储在何处。例如，在您的问题中，您使用短语“私钥”表示两件事：数据布局（文件或网络数据包）和实际私钥（X）。我建议仔细地写下协议的详细说明。然后更新你的问题，使协议描述更清晰。根据你的想法判断。第二，我想你们看到的是Diffie-Hellman协议的基本属性。你不会在那里发现一个bug：核心加密算法不会被破坏。这个错误总是一个错误的实现（例如，留下机密数据，或执行错误的计算），一个坏的协议（这些确实会发生，协议很复杂），或者一个旁道。回答不错，尽管我认为是Mallory获得了所有的乐趣。：）