title: i2p session key generation suspected to leak
body: <p>I've found recently in the I2P sources (Java) the following fragment:</p>
  
  <pre class="lang-java prettyprint-override"><code>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 &lt; val.length) {
          System.arraycopy(buf, 0, val, 0, buf.length);
                      ... //irrelevant details
      } else { // (buf.length &gt;= val.length)
          System.arraycopy(buf, 0, val, 0, val.length);
                     ... //irrelevant details
      }
      key.setData(val);
      return key;
  }
  </code></pre>
  
  <p>As I understand, the first 256 bits of <code>buf[]</code> are copied directly to the session key, and no SHA256 digest is ever run on it. I'm not cryptography specialist (neither java), could anyone explain me, isn't it security hole here? I mean, in the standard Diffie-Hellman wiki page the SHA hash is also run over the key. 
  If it really is, could you also give an example how it can be exploit?</p>