I2p session key generation assumed

Question

I recently found the following snippet in I2P (Java) sources:

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; } 

As I understand it, the first 256 bits of buf[] copied directly to the session key, and no SHA256 digest is ever executed on it. I'm not a cryptography specialist (nor java), can anyone explain to me if there isn’t a security hole here? I mean, the standard Diffie-Hellman wiki page also uses the SHA key. If this is true, could you also give an example, how can this be used?

Answer 1

There is no “leak” in the sense that an attacker can engage in key exchange, but, of course, entropy loss. Since the key appears to be 32 bytes in size, this may not be catastrophic, but it will be very difficult for me personally to accept this implementation.

The Diffie-Hellman protocol clearly states RFC 2631 , which

Leading zeros MUST be stored, so ZZ takes as many octets as p.

This preservation of the initial zero is absent in the implementation of the protocol.

Finally, since the developer decided not to impose, the values ​​overlap: 70 , 7000 and 700000 will, for example, be considered the same value, while they are clearly not.

In addition, BigInteger.toByteArray() will return the two-component encoding of the signed value. This means that it is often left with 00 digit bytes, even if the value already has the same size as p in octets. Thus, there is a really big chance that the first byte of the key is 00 . And even if it is not, the first byte is limited by the module, so the first byte will never have a value exceeding the first byte of the encoded p.

UPDATE: I asked at crypto.stackexchange.com to find out if the remaining key bytes can be generated by Random Oracle (a deterministic function that apparently generates random bytes for the outside world) and, fortunately, they seem to be do . This means that there is enough entropy in the AES keys to be safe from (brute force) attacks on the AES block cipher.

As explained, due to the large size of the key, it is likely that even the summation of all these defects cannot be easily used. But it’s clear that the keys will not carry 256 bits of entropy as expected. This is enough for the cryptanalyst to declare this implementation violated. Of course, it would be much worse with a smaller key size.

Note: all values ​​are in hexadecimal format.

Answer 2

As Solstead explained, this is not a security hole. But this is a mistake that was there from the very beginning of I2P, and we will correct one of them. Unfortunately, the changes required for correction do not correspond to backward compatibility with existing vehicles, so this will be included in future versions of our vehicles.

Those who are interested can follow the progress of this error here .