The third part of the translation of the official I2P documentation.
Even closer to the text.
If someone doesn’t know, then welcome to the cat, read in table of contents order.
Table of contents:
Part 1: “Everything you wanted to know and were afraid to ask about I2P»
Part 2: Tunnel magic, NetDB and protocol juggling
Part 3: Digital Garlic
Cryptography
A minimal set of cryptographic primitives are added to provide multi-layered protection against various threats in I2P. At the lowest level, communication between routers is protected at the transport layer (TLS). For this, the SSU (secure semireliable UDP) protocol is used, according to which each packet is encrypted using AES256 in CBC mode with an explicit indication of the initialization vector (IV) and message authentication code (using the HMAC-MD5-128 protocol). A 2048-bit session key is first created using the Diffie-Halman algorithm. Routers are authenticated using DSA, and each network message has an additional integrity check. Messages inside the tunnel also have native AES256/CBC encryption with explicit IV and SHA256 hash integrity checking. Other messages also pass through the network inside the garlic, but encrypted using ElGamal/AES + SessionTags algorithms (see below).
“Honest messages”
Honest messages, a continuation of onion encryption, allow one message to contain many attachments (“cloves”), which are fully formed messages with their own instructions for delivery. Messages are wrapped in garlic every time they are sent anywhere, otherwise their contents will be visible to intermediary nodes, which is not acceptable. As an example, the following situation:
The router sends a request to another router to participate in the creation of a tunnel, for this it wraps the message in “garlic”, encrypts it by receiving a 2048-bit public key, according to the El-Gamal scheme, and sends the message through the tunnel.
Another example, when a client wants to send a message to a recipient, the “sender” router will wrap the message data (along with other messages) in garlic, encrypt the garlic using a 2048-bit ElGamal public key published in the recipient's leaseSet, and send it through corresponding tunnel.
The nested instructions contained in the slices make it possible to redirect locally (somewhere), to a remote router, or to a tunnel to a remote router. The instructions have special fields that allow you to ask peers to delay delivery until a certain trigger is triggered (by time or condition); if they are not completed within the limits of “non-trivial delays” (artificially created delays), then the message will be “deployed”).
If possible, the garlic message can be sent through any number of hops (jumps - intermediate points), without a pre-built tunnel, to the target. While in the garlic, it will go through a specified number of steps before being delivered to the next hop in the tunnel.
(approx. lane - as I understand it, this is an example of a non-trivial delay).
In the current network and client implementation, this method is not available.
Session tags
Just as the messages of an I2P-based system are insecure and messy, I2P uses a simple combination of asymmetric and symmetric encryption algorithms to ensure the confidentiality and integrity of the data embedded in garlic messages. This combination is referred to as ElGamal/AES+SessionTags, but this is an overly verbose way of describing the simple 2048-bit “ElGamal”, AES256, SHA256 and 32-byte nonce algorithms used.
First, the router encrypts the message to another router using AES256, ElGamal is used as the key, and after it an AES256/CBC encrypted payload is added. In the additional load, the AES encrypted section contains the load length, SHA256 hash, the unencrypted load and a number of session tags - random 32 bytes. Next time, the sender wants to encrypt the “garlic” for another router, but without generating a new key using ElGamal, he can simply choose one of the previously supplied session tags and AES encryption of the payload, as before, using the key using the session tag, which was added before. When the router receives a message, it checks the first 32 bytes to see if they match the available session tags, if they do, then simple AES decryption is used, but if not, then the ElGamal algorithm is used for the first block.
Each session tag can be used only once, to prevent internal conflicts and the need to correlate messages between routers. Garlic messages allow you to monitor the delivery status, if the delivery is successful, then the trigger is executed:
Getting to the recipient -> successful decryption -> searching for instructions for a return response, if found, send a response through the incoming tunnel back to the sender.
When the sender receives a delivery status message, it knows that the session tag in the message was successfully delivered. Session tags themselves have a very short lifespan; after their lifetime expires, they are deleted if not used. In addition, the number of saves for each key is limited, just like the number of keys themselves. If there are too many tags, then new or old ones may be “thrown out”. The sender keeps track of his messages using session tags, if there is no necessary connection they can be removed before the message is revealed and the message is sent back thanks to a track from ElGamal encryption.
(approx. translation: PRNG - Pseudo-random number generator)
One option is to send one tag and listen to the PRNG to determine which tags have been used and which can be used.
By keeping the PRNG roughly synchronized between sender and receiver (the receiver pre-computes the size of the next window, e.g. 50 tags), if there is too much overhead, tags are removed, allowing for more options and a trade-off between time and volume, and a reduction in the number of ElGamal encryptions.
However, the complexity of the PRNG will determine the degree of protection against internal adversaries, perhaps by limiting the number of uses of the PRNG, any weaknesses can be minimized. But at the moment, in the foreseeable future, there are no plans to move towards the development of synchronous PRNG.
