【问题标题】:Determining a Private Key (Diffie-Hellman)确定私钥(Diffie-Hellman)
【发布时间】:2011-07-13 15:37:39
【问题描述】:

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

这是一个 Diffie-Hellman 交换过程,这里是已知的变量/常量:

  • P, G
  • 我生成的私钥(变量)
  • 我生成的公钥(变量)
  • 收件人公钥(常量)。

查看我的私钥时 - PG 都在其中。例如,第一个“x”字节似乎与任何东西都没有关系,那么接下来的“y”字节是P,接下来的两个字节是静态的,接下来的“z”字节是G,其余的是可变的。

这个过程是加密一个文件,然后把它发送到一个设备,然后设备会解密它——我的攻击思路是这样的:

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

  2. 尝试查找收件人的私钥。在这里,我可以强行闯入——但除非我有某种超级计算机,否则我会花很长时间。

在尝试攻击时还有其他选择吗?

【问题讨论】:

  • 在处理安全协议时,重要的是要非常精确地确定哪些数据存储在哪里。例如,在您的问题中,您将短语“私钥”用于两件事:数据布局(文件或网络数据包)和实际的私钥(X)。我建议仔细地写下协议的详细说明。然后更新您的问题,使协议描述更清晰。
  • P.S.从您的想法 1. 和 2. 来看,我认为您正在查看 Diffie-Hellman 协议的基本属性。你不会在那里找到错误:核心密码算法不会被破坏。该错误始终是一个错误的实现(例如,遗留机密数据,或执行不正确的计算),一个损坏的协议(这些确实发生,协议很棘手),或一个侧通道。

标签: java diffie-hellman


【解决方案1】:

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

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

  2. 如果您的 DH 实现允许声明一组新的 PQG,您可以请求其他对等方使用新的弱集。如果 Bob 不验证这个集合的质量,那么它很容易受到攻击。

  3. DH 要求 Alice 发送 X = g^x,如果 Bob 不检查 X 的质量,他很容易受到攻击,因为中间的 Eve 可以显着减少密钥的可能值空间.

  4. 如果您的实现不记得泄露的密钥,它们可以被 Eve 重新使用。

  5. 如果您的实施不记得被泄露的证书,它们可以被 Eve 重新使用。

  6. 如果您的实施不检查证书,Eve 肯定会很开心。

【讨论】:

  • 很好的答案,虽然我认为是马洛里得到了所有的乐趣。 :)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-19
  • 1970-01-01
  • 1970-01-01
  • 2015-09-05
相关资源
最近更新 更多