This page summarizes the current state of the I2P cryptography.
Currently used ciphers
Symmetric
Cipher | Used lengths | Security | Comments |
AES-CBC [8] | 256 | Good [5] | See [8] for p/q/g. A good choice due to common support for hardware acceleration??? Really? We don't support hardware acceleration. Never used alone, always with ElG+SessionTag? [8] Notes about padding in [8] are incorrect and to be fixed (see trac ticket) |
Asymmetric
Cipher | Used lengths | Security | Comments |
ElGamal [8] | 2048 | >Poor [5]??? | We use "short exponent" [8]. See [8] for prime. |
MAC
Cipher | Security | Implementability | Comments |
HMAC-MD5-128 | Poor [5] | nonstandard, used in SSU |
Hashes
Cipher | Used lengths | Security | Comments |
SHA256 [8] | 256 | Good [5] | Slow compared to SHA-3. Used everywhere. |
Key Exchange
Cipher | Used lengths | Security | Comments |
DH [8] | 2048 | Both NTCP and SSU. Uses same prime as ElG [8] |
Signatures
Cipher | Used lengths | Security | Comments |
DSA [8] | 1024 | Poor [5] [10] | We use DSA for all signatures. We do not use ElG as it was deemed too slow. That's why every Dest and RI has two keys, one for crypto and one for signing. Note that we do not support signing key revocation for anything. |
Cipher usage
Router aspect | Cipher used | Key used | Security timescale | Usage details | Comments |
NTCP handshake | DSA | RI SigKey | ??? | see below | |
SSU handshake | DSA | RI SigKey | ??? | see below | |
RouterInfo signing | DSA | RI SigKey | Years but… | Right now there's no limit on RI key lifetime but we could force a regeneration after a certain amount of time, esp. on startup after a long downtime | |
LeaseSet signing? | DSA | Dest SigKey | Years | 75% verif.? (guesstimation) | |
LeaseSet revocation (unused) | DSA | LS SigKey | ??? | ||
I2CP Session Config signing | DSA | ??? | |||
Datagram signing | DSA | Years and years? | Or is it the other LS key? There's multiple keys in a LS, some are in the Dest (i.e. tied to the hosts.txt entry) and some are regenerated at startup. Of course for client tunnels, keys are not persistent, all are regenerated at startup (or on reconnect if so configured in i2ptunnel) | ||
Streaming message signing | DSA | Years and years? | ditto | ||
SUD signing | DSA | Years and years | 99% verif. | Keys are hardcoded in i2p source, and revokable by removing them. New file format required to change algo, proposal at http://zzz.i2p/topics/1351 | |
Tunnel Build Messages [8] | ElG | RI EncKey | |||
NetDB Lookups / Stores [8] | ElG/AES+SessionTag? | Years but… | Only some are encrypted [8] Right now there's no limit on RI key lifetime but we could force a regeneration after a certain amount of time | ||
End-to-End Encryption [8] | ElG/AES+SessionTag? | LS EncKey | |||
Transport key exchange [8] | DH | Both NTCP and SSU | |||
NTCP Transport encryption [8] | AES | DH key | |||
SSU Transport encryption [8] | AES | DH key | With nonstandard HMAC-MD5-128 [8] | ||
Tunnel encryption hop-by-hop [9] | AES | See [9] for details | |||
Hashes [8] | SHA-256 | Used as the netdb keys and would be very disruptive to change [8] |
Potential new ciphers
Asymmetric ciphers
Cipher | Suggested length | Speed [6] | Security | Implementability | Comments |
EC-DSA | 256 | Sign.: 9203/s Verif.: 4658/s | Good [5] | Java7 BouncyCastle | |
EC-DSA | 384 | Sign.: 4791/s Verif.: 1085/s | >Good [5]??? | Java7 BouncyCastle | |
RSA-PKCS#1 v1.5 | 2048 | Sign.: 770/s Verif.: 25184/s | Poor [5] | ||
RSA-PKCS#1 v1.5 | 3072 | Decent [5] | |||
RSA-PKCS#1 v1.5 | 4096 | Sign.: 108/s Verif.: 6757/s | >Decent [5]??? | ||
RSA-PSS | 2048 | Sign.: 770/s Verif.: 25184/s | Decent [5] | ||
RSA-PSS | 3072 | Good [5] | |||
RSA-PSS | 4096 | Sign.: 108/s Verif.: 6757/s | >Good [5]??? | ||
DSA | 160/1024 | Sign.: 8176/s Verif.: 7500/s | Poor [5] | ||
DSA | 224/2048 256/2048 | Sign.: 2548/s Verif.: 2089/s | >Poor [5]??? | ||
DSA | 256/3072 | Decent [5] | |||
ElGamal | 256/2048 | About the same as DSA-2048 as DSA is based on ElGamal? | I2P |
Symmetric ciphers
Cipher | Suggested length | Speed | Security | Implementability | Comments |
Twofish | 256 Bits | 256-Bit Twofish is faster than 256-bit Rijndael(AES) on the same hardware |
Hashes
Cipher | Security | Implementability | Comments |
SHA3(Keccak) | Good enough to be recommended by NIST | Faster than the SHA-2 family | |
RIPEMD-160 | Decent [5] | ||
RIPEMD-320 | ~RIPEMD-160 [7] |
MAC
Cipher | Security | Implementability | Comments |
HMAC | Good [5] | ||
CMAC | Good [5] | ||
CBC-MAC-X9.19 | Good [5] | ||
CBC-MAC-EMAC | Good [5] |
Strategy
At first glance, current signing algo (DSA) is the weakest, and signing is far easier to understand and analyze than crypto, so it's probably a good place to start. [8] [10]
[1] http://www.cryptopp.com/benchmarks.html
[2] http://tools.ietf.org/html/rfc4492
[3] NIST 2011 http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
[4] http://www.keylength.com/en/compare/
[5] ECRYPT II 2012 http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf
[6] OpenSSL Benchmark
[7] http://en.wikipedia.org/wiki/RIPEMD - Citation needed
[8] https://geti2p.net/spec/cryptography and see more references there
[9] https://geti2p.net/en/docs/tunnels/implementation tunnel encryption
[10] http://zzz.i2p/topics/715 DSA replacement