Updated August 2010, current as of router version 0.8
This page specifies the low-level details of the cryptography in I2P.
There are a handful of cryptographic algorithms in use within I2P, but we have reduced them to a bare minimum to deal with our needs - one symmetric algorithm one asymmetric algorithm, one signing algorithm, and one hashing algorithm. However, we do combine them in some particular ways to provide message integrity (rather than relying on a MAC). In addition, as much as we hate doing anything new in regards to cryptography, we can't seem to find a reference discussing (or even naming) the technique used in ElGamal/AES+SessionTag (but we're sure others have done it).
ElGamal is used for asymmetric encryption.
We use common primes for 2048 ElGamal encryption and decryption, as given by IETF RFC-3526. We currently only use ElGamal to encrypt the IV and session key in a single block, followed by the AES encrypted payload using that key and IV. Specifically, the unencrypted ElGamal block is formatted (in network byte order):
+----+----+----+----+----+----+----+----+ |nonz| H(data) | +----+ + | | + + | | + + | | + +----+----+----+----+----+----+----+ | | data... +----+----+----+--//
The H(data) is the SHA256 of the data that is encrypted in the ElGamal block, and is preceded by a random nonzero byte. The data encrypted in the block can be up to 222 bytes long. See the ElGamal code.
ElGamal is never used on its own in I2P, but instead always as part of ElGamal/AES+SessionTag.
The shared prime is the [Oakley prime for 2048 bit keys]
2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
or as a hexadecimal value:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
Using 2 as the generator.
Also, Koshiba & Kurosawa: Short Exponent Diffie-Hellman Problems (PKC 2004, LNCS 2947, pp. 173-186) (full text on google books) apparently supports this, according to this sci.crypt thread. The remainder of the PublicKey is padded with zeroes.
The vulnerability of the network to an ElGamal attack and the impact of transitioning to a longer bit length is to be studied. It may be quite difficult to make any change backward-compatible.
AES is used for symmetric encryption.
We use 256 bit AES in CBC mode. The padding used is specified in IETF RFC-2313 (PKCS#5 1.5, section 8.1 (for block type 02)). In this case, padding exists of pseudorandomly generated octets to match 16 byte blocks. Specifically, see [the CBC code] and the Cryptix AES [implementation], as well as the padding, found in the ElGamalAESEngine.getPadding function.
Two situations are possible:
1. For situations where we stream AES data, we still use the same algorithm, as implemented in [AESOutputStream] [AESInputStream]
2. For situations where we know the size of the data to be sent, we AES encrypt the following:
|_______1_______2_______3_______4_______5_______6_______7_______8 |H(data) | | | | | size of data (in bytes) | data ... | rand ... |
After the data comes an application specified number of randomly generated padding bytes. This application specified number is rounded up to a multiple of 16. The entire segment (from H(data) through the end of the random bytes) is AES encrypted (256 bit CBC w/ PKCS#5).
This code is implemented in the safeEncrypt and safeDecrypt methods of [AESEngine]
The vulnerability of the network to an AES attack and the impact of transitioning to a longer bit length is to be studied. It may be quite difficult to make any change backward-compatible.
Signatures are generated and verified with 1024 bit DSA (L=1024, N=160), as implemented in [DSAEngine]. DSA was chosen because it is much faster for signatures than ElGamal.
160 bit
86108236b8526e296e923a4015b4282845b572cc
33
1024 bit
9C05B2AA 960D9B97 B8931963 C9CC9E8C 3026E9B8 ED92FAD0 A69CC886 D5BF8015 FCADAE31 A0AD18FA B3F01B00 A358DE23 7655C496 4AFAA2B3 37E96AD3 16B9FB1C C564B5AE C5B69A9F F6C3E454 8707FEF8 503D91DD 8602E867 E6D35D22 35C1869C E2479C3B 9D5401DE 04E0727F B33D6511 285D4CF2 9538D9E3 B6051F5B 22CC1C93
A5DFC28F EF4CA1E2 86744CD8 EED9D29D 684046B7
1024 bit
C1F4D27D 40093B42 9E962D72 23824E0B BC47E7C8 32A39236 FC683AF8 48895810 75FF9082 ED32353D 4374D730 1CDA1D23 C431F469 8599DDA0 2451824F F3697525 93647CC3 DDC197DE 985E43D1 36CDCFC6 BD5409CD 2F450821 142A5E6F 8EB1C3AB 5D0484B8 129FCF17 BCE4F7F3 3321C3CB 3DBB14A9 05E7B2B3 E93BE470 8CBCC82
The Signing Public Key is 1024 bits. The Signing Private Key is 160 bits.
NIST 800-57 recommends a minimum of (L=2048, N=224) for usage beyond 2010. This may be mitigated somewhat by the "cryptoperiod", or lifespan of a given key.
The prime number was chosen in 2003, and the person that chose the number (TheCrypto) is currently no longer an I2P developer. As such, we do not know if the prime chosen is a 'strong prime'. If a larger prime is chosen for future purposes, this should be a strong prime, and we will document the construction process.
The vulnerability of the network to a DSA attack and the impact of transitioning to longer keys is to be studied. It may be quite difficult to make any change backward-compatible.
Hashes within I2P are plain old SHA256, as implemented in [SHA256Generator]
The vulnerability of the network to a SHA-256 attack and the impact of transitioning to a longer hash is to be studied. It may be quite difficult to make any change backward-compatible.
At the lowest protocol layer, point-to-point inter-router communication is protected by the transport layer security. Both transports use 256 byte (2048 bit) Diffie-Hellman key exchange using the same shared prime and generator as specified above for ElGamal, followed by symmetric AES encryption as described above.
NTCP connections are negotiated with a 2048 Diffie-Hellman implementation, using the router's identity to proceed with a station to station agreement, followed by some encrypted protocol specific fields, with all subsequent data encrypted with AES (as above). A possible enhancement is to use session tags like we do with ElGamalAES+SessionTag to avoid the 2048 bit DH negotiation.
In order to migrate to a more standardized implementation (TLS/SSL or even SSH), the following issues must be addressed:
See the NTCP specification for details.
See the SSU specification for details.