i2p 会话密钥生成疑似泄露答案

【问题标题】：i2p session key generation suspected to leaki2p 会话密钥生成疑似泄露
【发布时间】：2014-02-18 18:21:19
【问题描述】：

我最近在 I2P 源代码 (Java) 中发现了以下片段：

private final SessionKey calculateSessionKey(BigInteger myPrivateValue, BigInteger publicPeerValue) {
    SessionKey key = new SessionKey();
    BigInteger exchangedKey = publicPeerValue.modPow(myPrivateValue, CryptoConstants.elgp);
    byte buf[] = exchangedKey.toByteArray();
    byte val[] = new byte[32];
    if (buf.length < val.length) {
        System.arraycopy(buf, 0, val, 0, buf.length);
                    ... //irrelevant details
    } else { // (buf.length >= val.length)
        System.arraycopy(buf, 0, val, 0, val.length);
                   ... //irrelevant details
    }
    key.setData(val);
    return key;
}

据我了解，buf[] 的前 256 位被直接复制到会话密钥中，并且从未在其上运行任何 SHA256 摘要。我不是密码学专家（也不是java），谁能解释一下，这里不是安全漏洞吗？我的意思是，在标准的 Diffie-Hellman wiki 页面中，SHA 哈希值也在密钥上运行。如果真的是这样，您能否也举一个如何利用它的例子？

【问题讨论】：

标签： security cryptography sha256

【解决方案1】：

从攻击者可以利用密钥交换的意义上说，没有“泄漏”，但肯定会损失熵。因为密钥的大小似乎是 32 字节，这可能不是灾难性的，但我个人很难接受这种实现。

Diffie-Hellman 协议在 RFC 2631 中明确指定

必须保留前导零，以便 ZZ 占用与 p 一样多的八位字节。

在协议的实现中不存在前导零的保留。

最后，因为设计师决定不填充，所以值会重叠：70、7000 和 700000 会被认为是相同的值，而它们显然不是。

此外，BigInteger.toByteArray() 将返回 signed 值的二补码编码。这意味着它通常会用00 值字节填充，即使该值已经与八位字节中的 p 具有相同的大小。所以密钥的第一个字节很有可能是00。即使不是，第一个字节也受模数限制，因此第一个字节的值永远不会高于编码 p 的第一个字节。

更新：我已经asked on crypto.stackexchange.com 看看其余的关键字节是否可以被认为是由随机 Oracle（一种似乎向外界生成随机字节的确定性函数）生成的，幸运的是 @987654323 @。这意味着 AES 密钥中留下了足够的熵，可以安全地抵御对 AES 分组密码的（暴力）攻击。

正如所解释的，由于密钥大小很大，即使是所有这些缺陷的总和也很可能无法轻易利用。但可以肯定的是，密钥不会像预期的那样携带 256 位的熵。这足以让密码分析师宣布这个实现被破坏了。当然，使用更小的密钥大小会更糟。

注意：所有值都是十六进制。

【讨论】：

【解决方案2】：

正如 owlstead 所解释的，这不是安全漏洞。但它是自 I2P 开始以来就一直存在的错误，我们将对其进行修复。不幸的是，修复此问题所需的更改与我们现有的传输不向后兼容，因此将合并到我们的下一个版本的传输中。

有兴趣的可以关注这个bug的进展here。

【讨论】：