Part 3: Digital Garlic

The third part of the translation of official I2P documentation.
Even closer to the text.
If someone does not know, then welcome under the cut, read in the table of contents.

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-level protection against various threats in I2P. At the lowest level, the interaction between routers is protected at the transport level (TLS). For this, the SSU protocol (secure semireliable UDP) is used, according to which each packet is encrypted using AES256 in CBC mode with an explicit initialization vector (IV) and message authentication code (using the HMAC-MD5-128 protocol). A 2048-bit session key is previously created using the Diffie-Halman algorithm. Router authentication is performed using DSA, and each network message has an additional integrity check. Messages inside the tunnel also have their own AES256 / CBC encryption with an explicit IV and integrity check using the SHA256 hash algorithm.

“Honest Messages”

Honest messages, a continuation of onion encryption, allow you to contain many attachments (“cloves”) in one message, which are fully formed messages with their delivery instructions. Messages are wrapped in garlic every time they are sent somewhere, otherwise their contents will be visible to intermediary nodes, and this is not permissible. As an example, the following situation: The
router sends a request to another router to participate in the creation of the tunnel, for this it wraps the message in “garlic” encrypts, receiving a 2048-bit public key, according to the El-Gamal scheme and sends a 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 public key according to El-Gamal's scheme published in the recipient's leaseSet and send it via corresponding tunnel.

Instructions nested contained in segments, 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 fires (by time or condition), if they are not performed within the “nontrivial delays” (artificially created delays), the message will be “deployed” (are deployed).
If possible, the garlic message can be sent through any number of hops (jumps - intermediate points), without a tunnel built in advance, to the target. Being in garlic, it will go through a given number of steps, before being delivered to the next hop in the tunnel.
(approx. per. - 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

As unreliable and disordered messages from an I2P-based system, I2P uses a simple combination of asymmetric and symmetric encryption algorithms to ensure the confidentiality and integrity of data embedded in garlic messages. This combination is referred to as El Gemal / AES + SessionTags, but it is an overly detailed way of describing the simple algorithms used for the 2048 bit “ElGamal”, AES256, SHA256 and 32 byte one-time numbers.

First, the router encrypts the message for another router using AES256, ElGamal is used as the key, and after it is added AES256 / CBC encrypted “useful” (Additional, transit) load. In the additional load, the encrypted AES section contains the load length, SHA256 hash, unencrypted load and a number of session tags - random 32 bytes. Next time, the sender wants to encrypt “garlic” for another router, but without generating a new key using ElGamal, he can simply select one of the previously set session tags and AES payload encryption, as before, using a key using a session tag, which has been 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 match,

Each session tag can only be used once to prevent internal conflicts and to correlate messages between routers. Garlic messages allow you to monitor the delivery status, if the delivery is successful, then the trigger is executed:
Hit to the recipient -> successful decryption -> search for instructions for the return response, if it is found to send the answer, through the incoming tunnel back to the sender.
When the sender receives a message about the delivery status, he learns that the session tag in the message has been successfully delivered. Session tags, by themselves, live very little, after the expiration of the life 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 can be “thrown out”. The sender tracks his messages using session tags, if there is no necessary connection, they can be deleted before the message is opened and the message goes back thanks to the encryption from El-Gamal.

(note per: PRNG - Pseudo-random number generator)
One option is to send one tag and listen to PRNG to determine which tags were used and which could be used.
Keeping PRNG approximately synchronized between the sender and the recipient (the recipient pre-calculates the size of the next window, for example, 50 tags), with too much overhead, the tags are deleted, which allows you to get more options and get a compromise between time and volume, and reduce the number of ElGamal encryption.
Nevertheless, the degree of protection against internal opponents will depend on the complexity of PRNG, possibly by limiting the number of PRNG uses, 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.