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 cat, read in the order of 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

The minimum set of cryptographic primitives is added up to provide I2P with multi-level protection against various threats. At the lowest level, the interaction between routers is protected at the transport level (TLS). To do this, use SSU (secure semireliable UDP) protocol, 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 (via the HMAC-MD5-128 protocol). Pre-created session 2048-bit key for the Diffie-Hellman algorithm. Routers are authenticated using DSA, and each network message has an additional integrity check. Messages inside the tunnel also have their own AES256 / CBC encryption with explicit IV and integrity checking using the SHA256 hash algorithm. Other messages also pass through the network from inside the garlic, but encrypted using El-Gemal / AES + SessionTags (see below).

“Honest Messages”

Honest messages are a continuation of onion (“onion”) encryption, which allows you to contain a number of attachments (“cloves”) in one message, which are fully formed messages with their delivery instructions. Messages are wrapped in garlic every time they go somewhere, otherwise their contents will be visible to intermediary nodes, and this is not permissible. As an example, the following situation:
The router sends the request to another router to participate in the creation of the tunnel, for this it wraps the message in “garlic” encrypts receiving the public key of 2048 bits, according to the scheme of El-Gamal and sends the message through the tunnel.
Another example is when a client wants to send a message to the recipient, the sender's router will wrap the message data (along with other messages) in garlic, encrypt garlic using the 2048 bit public key according to the El-Gamal scheme published at the recipient's lease set and send it via appropriate tunnel.
')
The instructions enclosed contained in the 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 peers to postpone delivery until a certain trigger is triggered (by time or condition), if they are not performed within “non-trivial delays” (artificially created delays), the message will be “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 take a predetermined number of steps before being delivered to the next hop in the tunnel.
(note. 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

As unreliable and unordered messages system based on I2P, 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 Hemal / AES + SessionTags, but this is an unnecessarily detailed way of describing the simple 2048 bit “ElGamal”, AES256, SHA256, and 32-byte one-time algorithms used.

First, the router encrypts the message for the other router using AES256, ElGamal serves as the key, and after it the AES256 / CBC encrypted “useful” (Additional, transit) load is added. In the additional load, the encrypted AES section contains the load length, the SHA256 hash, the non-encrypted load, and a number of session tags — a random 32 bytes. Next time, the sender wants to encrypt “garlic” for another router, but without generating a new key from ElGamal, he can simply choose one of the previously set session tags and AES encryption of the payload, as before, using a key that uses the 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, then simple AES decryption is used, but if not, the ElGamal algorithm is used for the first block.

Each session tag can be used only once, to prevent internal conflicts and because of the need to correlate messages between routers. Garlic messages allow you to control the delivery status, if the delivery is successful, a trigger is executed:
Contact with the recipient -> successful decryption -> search for instructions for the return response, if it is found to send a response, through the incoming tunnel back to the sender.
When the sender receives a delivery status message, he learns that the session tag in the message has been successfully delivered. Session tags themselves live very little, after the release of the life span they are deleted if not used. In addition, the number of saves for each key is limited, exactly like the number of keys themselves. If there are too many tags, then new or old ones can be “discarded”. The sender keeps track of its messages using session tags, if there is no necessary connection, they can be deleted before the message is opened and the message is returned back thanks to the track from El-Gamal encryption.

(comment per: PRNG - Pseudo-random number generator)
One option is to send a single tag and listen to the PRNG to determine which tags were used and which ones can be used.
By keeping the PRNG roughly synchronized between the sender and the recipient (the recipient pre-computes the size of the next window, for example 50 tags), with too much overhead, the tags are removed, which allows you to get more options and get a compromise between time and volume, and reducing the number of ElGamal encryption.
However, the degree of protection from internal adversaries will depend on the complexity of PRNG, perhaps by limiting the number of uses of 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.