Spécification des structures communes

Ce document décrit certains types de données communs à tous les protocoles I2P, comme I2NP , I2CP , SSU , etc.

Spécification de type commun

Entier

Description

Représente un entier non négatif.

Sommaire

1 à 8 octets en ordre d’octets réseau (big endian) représentant un entier non signé.

Date

Description

Le nombre de millisecondes écoulées depuis minuit le 1er janvier 1970 dans le fuseau horaire GMT. Si le nombre est 0, la date est indéfinie ou nulle.

Sommaire

8 byte Integer

Chaîne de caractères

Description

Représente une chaîne de caractères encodée en UTF-8.

Sommaire

1 ou plusieurs octets où le premier octet est le nombre d’octets (pas de caractères !) dans la chaîne et les 0-255 octets restants sont le tableau de caractères encodé en UTF-8 non terminé par null. La limite de longueur est de 255 octets (pas de caractères). La longueur peut être 0.

PublicKey

Description

Cette structure est utilisée dans ElGamal ou d’autres chiffrements asymétriques, représentant seulement l’exposant, pas les nombres premiers, qui sont constants et définis dans la spécification cryptographique ELGAMAL . D’autres schémas de chiffrement sont en cours de définition, voir le tableau ci-dessous.

Sommaire

Le type et la longueur de la clé sont déduits du contexte ou sont spécifiés dans le certificat de clé d’une destination ou d’un RouterInfo, ou dans les champs d’un LeaseSet2 ou d’une autre structure de données. Le type par défaut est ElGamal. À partir de la version 0.9.38, d’autres types peuvent être pris en charge, selon le contexte. Les clés sont en big-endian sauf indication contraire.

Les clés X25519 sont prises en charge dans les Destinations et LeaseSet2 depuis la version 0.9.44. Les clés X25519 sont prises en charge dans les RouterIdentities depuis la version 0.9.48.

PrivateKey

Description

Cette structure est utilisée dans ElGamal ou d’autres décryptages asymétriques, représentant seulement l’exposant, pas les nombres premiers qui sont constants et définis dans la spécification cryptographique ELGAMAL . D’autres schémas de chiffrement sont en cours de définition, voir le tableau ci-dessous.

Sommaire

Le type et la longueur de clé sont déduits du contexte ou stockés séparément dans une structure de données ou un fichier de clé privée. Le type par défaut est ElGamal. Depuis la version 0.9.38, d’autres types peuvent être pris en charge, selon le contexte. Les clés sont en big-endian sauf indication contraire.

SessionKey

Description

Cette structure est utilisée pour le chiffrement et déchiffrement symétrique AES256.

Sommaire

32 octets

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/SessionKey.html

SigningPublicKey

Description

Cette structure est utilisée pour vérifier les signatures.

Sommaire

Le type et la longueur de clé sont déduits du contexte ou sont spécifiés dans le certificat de clé d’une destination. Le type par défaut est DSA_SHA1. À partir de la version 0.9.12, d’autres types peuvent être pris en charge, selon le contexte.

• Quand une clé est composée de deux éléments (par exemple les points X,Y), elle est sérialisée en complétant chaque élément à longueur/2 avec des zéros en tête si nécessaire.

• Tous les types sont en Big Endian, excepté pour EdDSA et RedDSA, qui sont stockés et transmis dans un format Little Endian.

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/SigningPublicKey.html

SigningPrivateKey

Description

Cette structure est utilisée pour créer des signatures.

Sommaire

Le type et la longueur de clé sont spécifiés lors de la création. Le type par défaut est DSA_SHA1. À partir de la version 0.9.12, d’autres types peuvent être pris en charge, selon le contexte.

• Lorsqu’une clé est composée de deux éléments (par exemple les points X,Y), elle est sérialisée en complétant chaque élément à longueur/2 avec des zéros de tête si nécessaire.

• Tous les types sont en Big Endian, à l’exception d’EdDSA et RedDSA, qui sont stockés et transmis dans un format Little Endian.

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/SigningPrivateKey.html

Signature

Description

Cette structure représente la signature de certaines données.

Sommaire

Le type et la longueur de signature sont déduits du type de clé utilisé. Le type par défaut est DSA_SHA1. Depuis la version 0.9.12, d’autres types peuvent être pris en charge, selon le contexte.

• Lorsqu’une signature est composée de deux éléments (par exemple les valeurs R,S), elle est sérialisée en complétant chaque élément à longueur/2 avec des zéros en tête si nécessaire.

• Tous les types sont en Big Endian, à l’exception d’EdDSA et RedDSA, qui sont stockés et transmis dans un format Little Endian.

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/Signature.html

Hachage

Description

Représente le SHA256 de certaines données.

Sommaire

32 octets

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/Hash.html

Étiquette de session

Note : Les Session Tags pour les destinations ECIES-X25519 (ratchet) et les routers ECIES-X25519 font 8 octets. Voir ECIES et ECIES-ROUTERS .

Description

Un nombre aléatoire

Table des matières

32 octets

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/SessionTag.html

TunnelId

Description

Définit un identifiant unique pour chaque router dans un tunnel. Un Tunnel ID est généralement supérieur à zéro ; n’utilisez pas une valeur de zéro sauf dans des cas particuliers.

Sommaire

Entier Integer de 4 octets

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/TunnelId.html

Certificat

Description

Un certificat est un conteneur pour diverses preuves de réception ou preuves de travail utilisées dans le réseau I2P.

Sommaire

1 octet Integer spécifiant le type de certificat, suivi d’un Integer de 2 octets spécifiant la taille de la charge utile du certificat, puis ce nombre d’octets.

+----+----+----+----+----+-/
|type| length  | payload
+----+----+----+----+----+-/

type :: Integer
        length -> 1 byte

length :: Integer
          length -> 2 bytes

payload :: data
           length -> $length bytes

Notes

• Pour les Identités de Router , le Certificat est toujours NULL jusqu’à la version 0.9.15. À partir de la version 0.9.16, un Certificat de Clé est utilisé pour spécifier les types de clés. À partir de la version 0.9.48, les types de clés publiques de chiffrement X25519 sont autorisés. Voir ci-dessous.

• Pour les Garlic Cloves , le Certificate est toujours NULL, aucun autre n’est actuellement implémenté.

• Pour les Garlic Messages , le Certificat est toujours NULL, aucun autre n’est actuellement implémenté.

• Pour les Destinations , le Certificate peut être non-NULL. Depuis la version 0.9.12, un Key Certificate peut être utilisé pour spécifier le type de clé publique de signature. Voir ci-dessous.

• Les implémenteurs sont avertis d’interdire les données excédentaires dans les Certificats. La longueur appropriée pour chaque type de certificat doit être appliquée.

Types de certificats

Les types de certificats suivants sont définis :

Les certificats de clé ont été introduits dans la version 0.9.12. Avant cette version, toutes les PublicKeys étaient des clés ElGamal de 256 octets, et toutes les SigningPublicKeys étaient des clés DSA-SHA1 de 128 octets. Un certificat de clé fournit un mécanisme pour indiquer le type de la PublicKey et de la SigningPublicKey dans la Destination ou RouterIdentity, et pour empaqueter toutes les données de clé dépassant les longueurs standard.

En maintenant exactement 384 octets avant le certificat, et en plaçant toutes les données de clé excédentaires à l’intérieur du certificat, nous maintenons la compatibilité pour tout logiciel qui analyse les Destinations et les Router Identities.

Le payload du certificat de clé contient :

Les types de clés publiques de signature définis sont :

• Clé publique cryptographique complète ou première portion

• Remplissage aléatoire si les longueurs totales des deux clés sont inférieures à 384 octets

• Clé publique de signature complète ou première partie

La clé publique cryptographique est alignée au début et la clé publique de signature est alignée à la fin. Le remplissage (le cas échéant) se trouve au milieu. Les longueurs et les limites des données de clé initiales, du remplissage et des portions de données de clé excédentaires dans les certificats ne sont pas explicitement spécifiées, mais sont dérivées des longueurs des types de clés spécifiés. Si les longueurs totales des clés publiques cryptographiques et de signature dépassent 384 octets, le reste sera contenu dans le certificat de clé. Si la longueur de la clé publique cryptographique n’est pas de 256 octets, la méthode pour déterminer la limite entre les deux clés doit être spécifiée dans une révision future de ce document.

Exemples de structures utilisant une clé publique de cryptographie ElGamal et le type de clé publique de signature indiqué :

Notes

• Les implémenteurs sont avertis d’interdire les données excédentaires dans les certificats de clé. La longueur appropriée pour chaque type de certificat doit être appliquée.

• Un certificat KEY avec les types 0,0 (ElGamal,DSA_SHA1) est autorisé mais déconseillé. Il n’est pas bien testé et peut causer des problèmes dans certaines implémentations. Utilisez un certificat NULL dans la représentation canonique d’une Destination ou RouterIdentity (ElGamal,DSA_SHA1), qui sera 4 octets plus court qu’en utilisant un certificat KEY.

Mappage

Description

Un ensemble de correspondances clé/valeur ou de propriétés

Sommaire

Un entier de taille 2 octets suivi d’une série de paires String=String;.

AVERTISSEMENT : La plupart des utilisations de Mapping se trouvent dans des structures signées, où les entrées Mapping doivent être triées par clé, afin que la signature soit immuable. L’échec du tri par clé entraînera des échecs de signature !

+----+----+----+----+----+----+----+----+
|  size   | key_string (len + data)| =  |
+----+----+----+----+----+----+----+----+
| val_string (len + data)     | ;  | ...
+----+----+----+----+----+----+----+
size :: `Integer`
        length -> 2 bytes
        Total number of bytes that follow

key_string :: `String`
              A string (one byte length followed by UTF-8 encoded characters)

= :: A single byte containing '='

val_string :: `String`
              A string (one byte length followed by UTF-8 encoded characters)

; :: A single byte containing ';'

Notes

• L’encodage n’est pas optimal - nous avons besoin soit des caractères ‘=’ et ‘;’, soit des longueurs de chaîne, mais pas des deux

• Certaines documentations indiquent que les chaînes ne peuvent pas inclure ‘=’ ou ‘;’ mais cet encodage les prend en charge

• Les chaînes sont définies comme étant UTF-8 mais dans l’implémentation actuelle, I2CP utilise UTF-8 mais pas I2NP. Par exemple, les chaînes UTF-8 dans un mappage d’options RouterInfo dans un message I2NP Database Store seront corrompues.

• L’encodage autorise les clés dupliquées, cependant dans tout usage où le mappage est signé, les doublons peuvent provoquer un échec de signature.

• Les mappings contenus dans les messages I2NP (par exemple dans une RouterAddress ou RouterInfo) doivent être triés par clé afin que la signature soit invariante. Les clés dupliquées ne sont pas autorisées.

• Les mappages contenus dans un I2CP SessionConfig doivent être triés par clé afin que la signature soit invariante. Les clés dupliquées ne sont pas autorisées.

• La méthode de tri est définie comme dans Java String.compareTo(), en utilisant la valeur Unicode des caractères.

• Bien que cela dépende de l’application, les clés et valeurs sont généralement sensibles à la casse.

• Les limites de longueur des chaînes de clé et de valeur sont de 255 octets (pas de caractères) chacune, plus l’octet de longueur. L’octet de longueur peut être 0.

• La limite de longueur totale est de 65535 octets, plus le champ de taille de 2 octets, soit 65537 au total.

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/DataHelper.html

Spécification de structure commune

KeysAndCert

Description

Une clé publique de chiffrement, une clé publique de signature, et un certificat, utilisés soit comme RouterIdentity soit comme Destination.

Sommaire

Une PublicKey suivie d’une SigningPublicKey puis d’un Certificate .

+----+----+----+----+----+----+----+----+
| public_key                            |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| padding (optional)                    |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| signing_key                           |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| certificate                           |
+----+----+----+-/

public_key :: `PublicKey` (partial or full)
              length -> 256 bytes or as specified in key certificate

padding :: random data
           length -> 0 bytes or as specified in key certificate
           public_key length + padding length + signing_key length == 384 bytes

signing__key :: `SigningPublicKey` (partial or full)
                length -> 128 bytes or as specified in key certificate

certificate :: `Certificate`
               length -> >= 3 bytes

total length: 387+ bytes

Ces directives ont été proposées dans la Proposition 161 et implémentées dans la version d’API 0.9.57. Ces directives sont rétrocompatibles avec toutes les versions depuis la 0.6 (2005). Voir la Proposition 161 pour le contexte et des informations supplémentaires.

Pour toute combinaison actuellement utilisée de types de clés autre qu’ElGamal + DSA-SHA1, un remplissage sera présent. De plus, pour les destinations, le champ de clé publique de 256 octets n’est plus utilisé depuis la version 0.6 (2005).

Les implémenteurs devraient générer les données aléatoires pour les clés publiques de Destination, et le rembourrage des identités de Destination et de router, de manière à ce qu’elles soient compressibles dans divers protocoles I2P tout en restant sécurisées, et sans que les représentations Base 64 apparaissent comme corrompues ou non sécurisées. Cela offre la plupart des avantages de la suppression des champs de rembourrage sans aucun changement de protocole perturbateur.

Strictement parlant, la clé publique de signature de 32 octets seule (dans les Destinations et les Router Identities) et la clé publique de chiffrement de 32 octets (dans les Router Identities uniquement) est un nombre aléatoire qui fournit toute l’entropie nécessaire pour que les hachages SHA-256 de ces structures soient cryptographiquement robustes et distribués de manière aléatoire dans la DHT de la base de données réseau.

Cependant, par excès de prudence, nous recommandons d’utiliser un minimum de 32 octets de données aléatoires dans le champ de clé publique ElG et le padding. De plus, si les champs étaient tous à zéro, les destinations Base 64 contiendraient de longues séquences de caractères AAAA, ce qui pourrait alarmer ou confondre les utilisateurs.

Répétez les 32 octets de données aléatoires autant que nécessaire pour que la structure KeysAndCert complète soit hautement compressible dans les protocoles I2P tels que I2NP Database Store Message, Streaming SYN, handshake SSU2, et Datagrams avec réponse.

Exemples :

• Une Router Identity avec un type de chiffrement X25519 et un type de signature Ed25519 contiendra 10 copies (320 octets) de données aléatoires, pour une économie d’environ 288 octets une fois compressée.

• Une Destination avec un type de signature Ed25519 contiendra 11 copies (352 octets) des données aléatoires, pour une économie d’environ 320 octets une fois compressée.

Les implémentations doivent, bien entendu, stocker la structure complète de 387+ octets car le hachage SHA-256 de la structure couvre l’intégralité du contenu.

Notes

• N’assumez pas que ceux-ci font toujours 387 octets ! Ils font 387 octets plus la longueur du certificat spécifiée aux octets 385-386, qui peut être non nulle.

• À partir de la version 0.9.12, si le certificat est un Key Certificate, les limites des champs de clé peuvent varier. Voir la section Key Certificate ci-dessus pour plus de détails.

• La clé publique cryptographique est alignée au début et la clé publique de signature est alignée à la fin. Le rembourrage (s’il y en a un) se trouve au milieu.

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/KeysAndCert.html

RouterIdentity

Description

Définit la façon d’identifier de manière unique un router particulier

Sommaire

Identique à KeysAndCert.

Voir KeysAndCert pour les directives sur la génération de données aléatoires pour le champ de remplissage.

Notes

• Le certificat pour une RouterIdentity était toujours NULL jusqu’à la version 0.9.12.

• Ne supposez pas que ceux-ci font toujours 387 octets ! Ils font 387 octets plus la longueur du certificat spécifiée aux octets 385-386, qui peut être non nulle.

• À partir de la version 0.9.12, si le certificat est un Key Certificate, les limites des champs de clé peuvent varier. Voir la section Key Certificate ci-dessus pour plus de détails.

• La clé publique crypto est alignée au début et la clé publique de signature est alignée à la fin. Le remplissage (le cas échéant) se trouve au milieu.

• Les RouterIdentities avec un certificat de clé et une clé publique ECIES_X25519 sont pris en charge depuis la version 0.9.48. Avant cela, toutes les RouterIdentities étaient ElGamal.

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/router/RouterIdentity.html

Destination

Description

Une Destination définit un point de terminaison particulier vers lequel les messages peuvent être dirigés pour une livraison sécurisée.

Sommaire

Identique à KeysAndCert , sauf que la clé publique n’est jamais utilisée et peut contenir des données aléatoires au lieu d’une clé publique ElGamal valide.

Voir KeysAndCert pour les directives sur la génération des données aléatoires pour la clé publique et les champs de remplissage.

Notes

• La clé publique de la destination était utilisée pour l’ancien chiffrement i2cp-to-i2cp qui a été désactivé dans la version 0.6 (2005), elle n’est actuellement pas utilisée sauf pour l’IV du chiffrement LeaseSet, qui est obsolète. La clé publique dans le LeaseSet est utilisée à la place.

• Ne supposez pas que ceux-ci font toujours 387 octets ! Ils font 387 octets plus la longueur du certificat spécifiée aux octets 385-386, qui peut être non nulle.

• À partir de la version 0.9.12, si le certificat est un Key Certificate, les limites des champs de clé peuvent varier. Voir la section Key Certificate ci-dessus pour plus de détails.

• La clé publique cryptographique est alignée au début et la clé publique de signature est alignée à la fin. Le remplissage (s’il y en a un) est au milieu.

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/Destination.html

Lease

Description

Définit l’autorisation pour un tunnel particulier de recevoir des messages ciblant une Destination .

Sommaire

SHA256 Hash de la RouterIdentity du router passerelle, puis le TunnelId , et enfin une Date de fin.

+----+----+----+----+----+----+----+----+
| tunnel_gw                             |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|     tunnel_id     |      end_date
+----+----+----+----+----+----+----+----+
                    |
+----+----+----+----+

tunnel_gw :: Hash of the `RouterIdentity` of the tunnel gateway
             length -> 32 bytes

tunnel_id :: `TunnelId`
             length -> 4 bytes

end_date :: `Date`
            length -> 8 bytes

LeaseSet

Description

Contient tous les Leases actuellement autorisés pour une Destination particulière, la PublicKey avec laquelle les messages garlic peuvent être chiffrés, puis la SigningPublicKey qui peut être utilisée pour révoquer cette version particulière de la structure. Le leaseSet est l’une des deux structures stockées dans la base de données réseau (l’autre étant RouterInfo ), et est indexé sous le SHA256 de la Destination contenue.

Sommaire

Destination , suivie d’une PublicKey pour le chiffrement, puis d’une SigningPublicKey qui peut être utilisée pour révoquer cette version du LeaseSet, puis d’un Integer de 1 octet spécifiant combien de structures Lease sont dans l’ensemble, suivi des structures Lease actuelles et enfin d’une Signature des octets précédents signée par la SigningPrivateKey de la Destination .

+----+----+----+----+----+----+----+----+
| destination                           |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| encryption_key                        |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| signing_key                           |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| num| Lease 0                          |
+----+                                  +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| Lease 1                               |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| Lease ($num-1)                        |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| signature                             |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+

destination :: `Destination`
               length -> >= 387+ bytes

encryption_key :: `PublicKey`
                  length -> 256 bytes

signing_key :: `SigningPublicKey`
               length -> 128 bytes or as specified in destination's key
                         certificate

num :: `Integer`
       length -> 1 byte
       Number of leases to follow
       value: 0 <= num <= 16

leases :: [`Lease`]
          length -> $num*44 bytes

signature :: `Signature`
             length -> 40 bytes or as specified in destination's key
                       certificate

• La clé publique de la destination était utilisée pour l’ancien chiffrement I2CP vers I2CP qui a été désactivé dans la version 0.6, elle n’est actuellement pas utilisée.

• La clé de chiffrement est utilisée pour le chiffrement de bout en bout ElGamal/AES+SessionTag ELGAMAL-AES . Elle est actuellement générée à nouveau à chaque démarrage du router, elle n’est pas persistante.

• La signature peut être vérifiée en utilisant la clé publique de signature de la destination.

• Un LeaseSet avec zéro Leases est autorisé mais n’est pas utilisé. Il était destiné à la révocation de LeaseSet, qui n’est pas implémentée. Toutes les variantes de LeaseSet2 nécessitent au moins un Lease.

• La signing_key est actuellement inutilisée. Elle était destinée à la révocation de leaseSet, qui n’est pas implémentée. Elle est actuellement générée à nouveau à chaque démarrage du router, elle n’est pas persistante. Le type de clé de signature est toujours le même que le type de clé de signature de la destination.

• L’expiration la plus précoce de tous les Leases est traitée comme l’horodatage ou la version du LeaseSet. Les routeurs n’accepteront généralement pas le stockage d’un LeaseSet à moins qu’il ne soit “plus récent” que l’actuel. Soyez prudent lors de la publication d’un nouveau LeaseSet où le Lease le plus ancien est le même que le Lease le plus ancien dans le LeaseSet précédent. Le routeur de publication devrait généralement incrémenter l’expiration du Lease le plus ancien d’au moins 1 ms dans ce cas.

• Avant la version 0.9.7, lorsqu’inclus dans un message DatabaseStore envoyé par le router d’origine, le router définissait toutes les expirations des leases publiés à la même valeur, celle du lease le plus ancien. À partir de la version 0.9.7, le router publie l’expiration réelle du lease pour chaque lease. Il s’agit d’un détail d’implémentation et non d’une partie de la spécification des structures.

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/LeaseSet.html

Lease2

Description

Définit l’autorisation pour un tunnel particulier de recevoir des messages ciblant une Destination . Identique à Lease mais avec un end_date de 4 octets. Utilisé par LeaseSet2 . Pris en charge depuis la version 0.9.38 ; voir la proposition 123 pour plus d’informations.

Sommaire

Hash SHA256 de la RouterIdentity du router passerelle, puis le TunnelId , et enfin une date de fin sur 4 octets.

+----+----+----+----+----+----+----+----+
| tunnel_gw                             |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|     tunnel_id     |      end_date     |
+----+----+----+----+----+----+----+----+

tunnel_gw :: Hash of the `RouterIdentity` of the tunnel gateway
             length -> 32 bytes

tunnel_id :: `TunnelId`
             length -> 4 bytes

end_date :: 4 byte date
            length -> 4 bytes
            Seconds since the epoch, rolls over in 2106.

• Taille totale : 40 octets

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/Lease2.html

OfflineSignature

Description

Il s’agit d’une partie optionnelle de LeaseSet2Header . Également utilisée dans le streaming et I2CP. Prise en charge à partir de la version 0.9.38 ; voir la proposition 123 pour plus d’informations.

Sommaire

Contient une expiration, un sigtype et une SigningPublicKey transitoire, et une Signature .

+----+----+----+----+----+----+----+----+
|     expires       | sigtype |         |
+----+----+----+----+----+----+         +
|       transient_public_key            |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|           signature                   |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

expires :: 4 byte date
           length -> 4 bytes
           Seconds since the epoch, rolls over in 2106.

sigtype :: 2 byte type of the transient_public_key
           length -> 2 bytes

transient_public_key :: `SigningPublicKey`
                        length -> As inferred from the sigtype

signature :: `Signature`
             length -> As inferred from the sigtype of the signing public key
                       in the `Destination` that preceded this offline signature.
             Signature of expires timestamp, transient sig type, and public key,
             by the destination public key.

• Cette section peut, et devrait, être générée hors ligne.

LeaseSet2Header

Description

Ceci est la partie commune du LeaseSet2 et du MetaLeaseSet . Pris en charge depuis la version 0.9.38 ; voir la proposition 123 pour plus d’informations.

Sommaire

Contient la Destination , deux horodatages, et une OfflineSignature optionnelle.

+----+----+----+----+----+----+----+----+
| destination                           |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|     published     | expires |  flags  |
+----+----+----+----+----+----+----+----+
| offline_signature (optional)          |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

destination :: `Destination`
               length -> >= 387+ bytes

published :: 4 byte date
             length -> 4 bytes
             Seconds since the epoch, rolls over in 2106.

expires :: 2 byte time
           length -> 2 bytes
           Offset from published timestamp in seconds, 18.2 hours max

flags :: 2 bytes
  Bit order: 15 14 ... 3 2 1 0
  Bit 0: If 0, no offline keys; if 1, offline keys
  Bit 1: If 0, a standard published leaseset.
         If 1, an unpublished leaseset.
  Bit 2: If 0, a standard published leaseset.
         If 1, this unencrypted leaseset will be blinded and encrypted when published.
  Bits 15-3: set to 0 for compatibility with future uses

offline_signature :: `OfflineSignature`
                     length -> varies
                     Optional, only present if bit 0 is set in the flags.

• Flags (2 octets) :

  • Bit 0 : Si défini, les clés hors ligne sont présentes (voir OfflineSignature )
  • Bit 1 : Si défini, il s’agit d’un leaseSet non publié
  • Bit 2 : Si défini, il s’agit d’un leaseSet aveugle
  • Bits 15-3 : Réservés, définis à 0

• Taille totale : 395 octets minimum

• Le temps d’expiration réel maximum est d’environ 660 (11 minutes) pour LeaseSet2 et 65535 (les 18,2 heures complètes) pour MetaLeaseSet .

• LeaseSet (1) n’avait pas de champ ‘published’, donc le versioning nécessitait une recherche du lease le plus ancien. LeaseSet2 ajoute un champ ‘published’ avec une résolution d’une seconde. Les routers devraient limiter le débit d’envoi de nouveaux leasesets vers les floodfills à un taux beaucoup plus lent qu’une fois par seconde (par destination). Si cela n’est pas implémenté, alors le code doit s’assurer que chaque nouveau leaseset a un temps ‘published’ d’au moins une seconde plus tard que le précédent, sinon les floodfills ne stockeront pas ou ne diffuseront pas le nouveau leaseset.

LeaseSet2

Description

Contenu dans un message I2NP DatabaseStore de type 3. Pris en charge depuis la version 0.9.38 ; voir la proposition 123 pour plus d’informations.

Contient tous les Lease2 actuellement autorisés pour une Destination particulière, et la PublicKey avec laquelle les messages garlic peuvent être chiffrés. Un LeaseSet est l’une des deux structures stockées dans la base de données réseau (l’autre étant RouterInfo ), et est indexé sous le SHA256 de la Destination contenue.

Sommaire

LeaseSet2Header , suivi d’options, puis une ou plusieurs PublicKey pour le chiffrement, un Integer spécifiant combien de structures Lease2 sont dans l’ensemble, suivi des structures Lease2 réelles et enfin une Signature des octets précédents signés par la SigningPrivateKey de la Destination ou la clé transitoire.

+----+----+----+----+----+----+----+----+
|         ls2_header                    |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|          options                      |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|numk| keytype0| keylen0 |              |
+----+----+----+----+----+              +
|          encryption_key_0             |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| keytypen| keylenn |                   |
+----+----+----+----+                   +
|          encryption_key_n             |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| num| Lease2 0                         |
+----+                                  +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| Lease2($num-1)                        |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| signature                             |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

ls2header :: `LeaseSet2Header`
             length -> varies

options :: `Mapping`
           length -> varies, 2 bytes minimum

numk :: `Integer`
        length -> 1 byte
        Number of key types, key lengths, and `PublicKey`s to follow
        value: 1 <= numk <= max TBD

keytype :: The encryption type of the `PublicKey` to follow.
           length -> 2 bytes

keylen :: The length of the `PublicKey` to follow.
          Must match the specified length of the encryption type.
          length -> 2 bytes

encryption_key :: `PublicKey`
                  length -> keylen bytes

num :: `Integer`
       length -> 1 byte
       Number of `Lease2`s to follow
       value: 0 <= num <= 16

leases :: [`Lease2`]
          length -> $num*40 bytes

signature :: `Signature`
             length -> 40 bytes or as specified in destination's key
                       certificate, or by the sigtype of the transient public key,
                       if present in the header

Pour les leasesets publiés (serveur), les clés de chiffrement sont classées par ordre de préférence du serveur, la plus préférée en premier. Si les clients prennent en charge plus d’un type de chiffrement, il est recommandé qu’ils respectent la préférence du serveur et sélectionnent le premier type pris en charge comme méthode de chiffrement à utiliser pour se connecter au serveur. En général, les types de clés plus récents (numérotés plus haut) sont plus sécurisés ou efficaces et sont préférés, donc les clés devraient être listées dans l’ordre inverse du type de clé.

Cependant, les clients peuvent, selon l’implémentation, sélectionner en fonction de leurs préférences à la place, ou utiliser une méthode pour déterminer la préférence “combinée”. Cela peut être utile comme option de configuration, ou pour le débogage.

L’ordre des clés dans les leasesets non publiés (client) n’a effectivement pas d’importance, car les connexions ne seront généralement pas tentées vers des clients non publiés. À moins que cet ordre ne soit utilisé pour déterminer une préférence combinée, comme décrit ci-dessus.

Options

À partir de l’API 0.9.66, un format standard pour les options d’enregistrement de service est défini. Voir la proposition 167 pour plus de détails. Des options autres que les enregistrements de service, utilisant un format différent, pourront être définies à l’avenir.

Les options LS2 DOIVENT être triées par clé, afin que la signature soit invariante.

Les options d’enregistrement de service sont définies comme suit :

• serviceoption := optionkey optionvalue
• optionkey := _service._proto
• service := Le nom symbolique du service désiré. Doit être en minuscules. Exemple : “smtp”. Les caractères autorisés sont [a-z0-9-] et ne doivent pas commencer ou finir par un ‘-’. Les identifiants standards du REGISTRY ou de Linux /etc/services doivent être utilisés s’ils y sont définis.
• proto := Le protocole de transport du service désiré. Doit être en minuscules, soit “tcp” soit “udp”. “tcp” signifie streaming et “udp” signifie datagrammes avec réponse possible. Les indicateurs de protocole pour les datagrammes bruts et datagram2 pourront être définis ultérieurement. Les caractères autorisés sont [a-z0-9-] et ne doivent pas commencer ou finir par un ‘-’.
• optionvalue := self | srvrecord[,srvrecord]*
• self := “0” ttl port [appoptions]
• srvrecord := “1” ttl priority weight port target [appoptions]
• ttl := durée de vie, en secondes entières. Entier positif. Exemple : “86400”. Un minimum de 86400 (un jour) est recommandé, voir la section Recommandations ci-dessous pour plus de détails.
• priority := La priorité de l’hôte cible, une valeur plus faible signifie plus préféré. Entier non négatif. Exemple : “0” Utile seulement s’il y a plus d’un enregistrement, mais requis même s’il n’y a qu’un seul enregistrement.
• weight := Un poids relatif pour les enregistrements avec la même priorité. Une valeur plus élevée signifie plus de chances d’être sélectionné. Entier non négatif. Exemple : “0” Utile seulement s’il y a plus d’un enregistrement, mais requis même s’il n’y a qu’un seul enregistrement.
• port := Le port I2CP sur lequel le service doit être trouvé. Entier non négatif. Exemple : “25” Le port 0 est supporté mais non recommandé.
• target := Le nom d’hôte ou b32 de la destination fournissant le service. Un nom d’hôte valide comme dans NAMING . Doit être en minuscules. Exemple : “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p” ou “example.i2p”. Le b32 est recommandé sauf si le nom d’hôte est “bien connu”, c’est-à-dire dans les carnets d’adresses officiels ou par défaut.
• appoptions := texte arbitraire spécifique à l’application, ne doit pas contenir " " ou “,”. L’encodage est UTF-8.

Exemples :

Dans LS2 pour aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p, pointant vers un serveur SMTP :

“_smtp._tcp” “1 86400 0 0 25 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p”

Dans LS2 pour aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p, pointant vers deux serveurs SMTP :

“_smtp._tcp” “1 86400 0 0 25 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p,86400 1 0 25 cccccccccccccccccccccccccccccccccccccccccccc.b32.i2p”

Dans LS2 pour bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p, pointant vers lui-même en tant que serveur SMTP :

“_smtp._tcp” “0 999999 25”

Notes

• La clé publique de la destination était utilisée pour l’ancien chiffrement I2CP-vers-I2CP qui a été désactivé dans la version 0.6, elle n’est actuellement pas utilisée.

• Les clés de chiffrement sont utilisées pour le chiffrement de bout en bout ElGamal/AES+SessionTag ELGAMAL-AES (type 0) ou d’autres schémas de chiffrement de bout en bout. Voir ECIES et les propositions 145 et 156. Elles peuvent être générées à nouveau à chaque démarrage du router ou elles peuvent être persistantes. X25519 (type 4, voir ECIES ) est pris en charge depuis la version 0.9.44.

• La signature porte sur les données ci-dessus, PRÉCÉDÉES par l’octet unique contenant le type DatabaseStore (3).

• La signature peut être vérifiée en utilisant la clé publique de signature de la destination, ou la clé publique de signature transitoire, si une signature hors ligne est incluse dans l’en-tête du leaseset2.

• La longueur de clé est fournie pour chaque clé, afin que les floodfills et les clients puissent analyser la structure même si tous les types de chiffrement ne sont pas connus ou pris en charge.

• Voir la note sur le champ ‘published’ dans LeaseSet2Header

• Le mappage des options, si la taille est supérieure à un, doit être trié par clé, afin que la signature soit invariante.

JavaDoc : http://docs.i2p-projekt.de/net/i2p/data/LeaseSet2.html

MetaLease

Description

Définit l’autorisation pour un tunnel particulier de recevoir des messages ciblant une Destination . Identique à Lease2 mais avec des drapeaux et un coût au lieu d’un identifiant de tunnel. Utilisé par MetaLeaseSet . Contenu dans un message I2NP DatabaseStore de type 7. Pris en charge à partir de la version 0.9.38 ; voir la proposition 123 pour plus d’informations.

Contenu

Hachage SHA256 de la RouterIdentity du router passerelle, puis les drapeaux et le coût, et enfin une date de fin sur 4 octets.

+----+----+----+----+----+----+----+----+
| tunnel_gw                             |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|    flags     |cost|      end_date     |
+----+----+----+----+----+----+----+----+

tunnel_gw :: Hash of the `RouterIdentity` of the tunnel gateway,
             or the hash of another `MetaLeaseSet`.
             length -> 32 bytes

flags :: 3 bytes of flags
         Bit order: 23 22 ... 3 2 1 0
         Bits 3-0: Type of the entry.
         If 0, unknown.
         If 1, a `LeaseSet`.
         If 3, a `LeaseSet2`.
         If 5, a `MetaLeaseSet`.
         Bits 23-4: set to 0 for compatibility with future uses
         length -> 3 bytes

cost :: 1 byte, 0-255. Lower value is higher priority.
        length -> 1 byte

end_date :: 4 byte date
            length -> 4 bytes
            Seconds since the epoch, rolls over in 2106.

Notes

• Taille totale : 40 octets

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/MetaLease.html

MetaLeaseSet

Description

Contenu dans un message I2NP DatabaseStore de type 7. Défini à partir de la version 0.9.38 ; prévu pour être opérationnel à partir de la version 0.9.40 ; voir la proposition 123 pour plus d’informations.

Contient tous les MetaLease actuellement autorisés pour une Destination particulière, et la PublicKey avec laquelle les messages garlic peuvent être chiffrés. Un LeaseSet est l’une des deux structures stockées dans la base de données réseau (l’autre étant RouterInfo ), et est indexé sous le SHA256 de la Destination contenue.

Sommaire

LeaseSet2Header , suivi d’options, Integer spécifiant combien de structures Lease2 sont dans l’ensemble, suivi des structures Lease2 actuelles et finalement une Signature des octets précédents signés par la SigningPrivateKey de la Destination ou la clé transitoire.

+----+----+----+----+----+----+----+----+
|         ls2_header                    |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|          options                      |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| num| MetaLease 0                      |
+----+                                  +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| MetaLease($num-1)                     |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|numr|                                  |
+----+                                  +
|          revocation_0                 |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|          revocation_n                 |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| signature                             |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

ls2header :: `LeaseSet2Header`
             length -> varies

options :: `Mapping`
           length -> varies, 2 bytes minimum

num :: `Integer`
        length -> 1 byte
        Number of `MetaLease`s to follow
        value: 1 <= num <= max TBD

leases :: `MetaLease`s
          length -> $numr*40 bytes

numr :: `Integer`
        length -> 1 byte
        Number of `Hash`es to follow
        value: 0 <= numr <= max TBD

revocations :: [`Hash`]
               length -> $numr*32 bytes

signature :: `Signature`
             length -> 40 bytes or as specified in destination's key
                       certificate, or by the sigtype of the transient public key,
                       if present in the header

Notes

• La clé publique de la destination était utilisée pour l’ancien chiffrement I2CP vers I2CP qui a été désactivé dans la version 0.6, elle n’est actuellement pas utilisée.

• La signature porte sur les données ci-dessus, PRÉCÉDÉES par l’octet unique contenant le type DatabaseStore (7).

• La signature peut être vérifiée en utilisant la clé publique de signature de la destination, ou la clé publique de signature transitoire, si une signature hors ligne est incluse dans l’en-tête du leaseset2.

• Voir la note sur le champ ‘published’ dans LeaseSet2Header

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/MetaLeaseSet.html

EncryptedLeaseSet

Description

Contenu dans un message I2NP DatabaseStore de type 5. Défini à partir de la version 0.9.38 ; fonctionnel à partir de la version 0.9.39 ; voir la proposition 123 pour plus d’informations.

Seuls la clé masquée et l’expiration sont visibles en texte clair. Le leaseSet réel est chiffré.

Sommaire

Un type de signature de deux octets, la SigningPrivateKey aveuglée, l’heure de publication, l’expiration et les drapeaux. Puis, une longueur de deux octets suivie de données chiffrées. Enfin, une Signature des octets précédents signée par la SigningPrivateKey aveuglée ou la clé transitoire.

+----+----+----+----+----+----+----+----+
| sigtype |                             |
+----+----+                             +
|        blinded_public_key             |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|     published     | expires |  flags  |
+----+----+----+----+----+----+----+----+
| offline_signature (optional)          |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|  len    |                             |
+----+----+                             +
|         encrypted_data                |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| signature                             |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

sigtype :: A two byte signature type of the public key to follow
           length -> 2 bytes

blinded_public_key :: `SigningPublicKey`
                      length -> As inferred from the sigtype

published :: 4 byte date
             length -> 4 bytes
             Seconds since the epoch, rolls over in 2106.

expires :: 2 byte time
           length -> 2 bytes
           Offset from published timestamp in seconds, 18.2 hours max

flags :: 2 bytes
  Bit order: 15 14 ... 3 2 1 0
  Bit 0: If 0, no offline keys; if 1, offline keys
  Bit 1: If 0, a standard published leaseset.
         If 1, an unpublished leaseset. Should not be flooded, published, or
         sent in response to a query. If this leaseset expires, do not query the
         netdb for a new one.
  Bits 15-2: set to 0 for compatibility with future uses

offline_signature :: `OfflineSignature`
                     length -> varies
                     Optional, only present if bit 0 is set in the flags.

len :: `Integer`
        length -> 2 bytes
        length of encrypted_data to follow
        value: 1 <= num <= max TBD

encrypted_data :: Data encrypted
                  length -> len bytes

signature :: `Signature`
             length -> As specified by the sigtype of the blinded pubic key,
                       or by the sigtype of the transient public key,
                       if present in the header

Notes

• La clé publique de la destination était utilisée pour l’ancien chiffrement I2CP-vers-I2CP qui a été désactivé dans la version 0.6, elle n’est actuellement pas utilisée.

• La signature porte sur les données ci-dessus, PRÉCÉDÉES du byte unique contenant le type DatabaseStore (5).

• La signature peut être vérifiée en utilisant la clé publique de signature de la destination, ou la clé publique de signature transitoire, si une signature hors ligne est incluse dans l’en-tête du leaseset2.

• L’aveuglement et le chiffrement sont spécifiés dans EncryptedLeaseSet

• Cette structure n’utilise pas le LeaseSet2Header .

• Le temps d’expiration réel maximum est d’environ 660 (11 minutes), sauf s’il s’agit d’un MetaLeaseSet chiffré.

• Voir la proposition 123 pour des notes sur l’utilisation de signatures hors ligne avec des leaseSets chiffrés.

• Voir la note sur le champ ‘published’ dans LeaseSet2Header (même problème, même si nous n’utilisons pas le format LeaseSet2Header ici)

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/EncryptedLeaseSet.html

RouterAddress

Description

Cette structure définit les moyens de contacter un router via un protocole de transport.

Sommaire

1 octet Integer définissant le coût relatif d’utilisation de l’adresse, où 0 est gratuit et 255 est coûteux, suivi de la Date d’expiration après laquelle l’adresse ne doit pas être utilisée, ou si nulle, l’adresse n’expire jamais. Après cela vient une String définissant le protocole de transport que cette adresse router utilise. Finalement, il y a un Mapping contenant toutes les options spécifiques au transport nécessaires pour établir la connexion, comme l’adresse IP, le numéro de port, l’adresse email, l’URL, etc.

+----+----+----+----+----+----+----+----+
|cost|           expiration
+----+----+----+----+----+----+----+----+
     |        transport_style           |
+----+----+----+----+-/-+----+----+----+
|                                       |
+                                       +
|               options                 |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

cost :: `Integer`
        length -> 1 byte

        case 0 -> free
        case 255 -> expensive

expiration :: `Date` (must be all zeros, see notes below)
              length -> 8 bytes

              case null -> never expires

transport_style :: `String`
                   length -> 1-256 bytes

options :: `Mapping`

Notes

• Le coût est typiquement de 5 ou 6 pour SSU, et de 10 ou 11 pour NTCP.

• L’expiration n’est actuellement pas utilisée, toujours nulle (tous des zéros). Depuis la version 0.9.3, l’expiration est supposée être zéro et n’est pas stockée, donc toute expiration non-nulle échouera lors de la vérification de signature du RouterInfo. L’implémentation de l’expiration (ou un autre usage pour ces octets) sera un changement incompatible avec les versions antérieures. Les routers DOIVENT définir ce champ à tous zéros. Depuis la version 0.9.12, un champ d’expiration non-nul est à nouveau reconnu, cependant nous devons attendre plusieurs versions pour utiliser ce champ, jusqu’à ce que la grande majorité du réseau le reconnaisse.

• Les options suivantes, bien qu’elles ne soient pas obligatoires, sont standard et doivent normalement être présentes dans la plupart des adresses de router : “host” (une adresse IPv4 ou IPv6 ou un nom d’hôte) et “port”.

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/router/RouterAddress.html

RouterInfo

Description

Définit toutes les données qu’un router souhaite publier pour que le réseau puisse les voir. Le RouterInfo est l’une des deux structures stockées dans la base de données réseau (l’autre étant LeaseSet ), et est indexé sous le SHA256 de l’RouterIdentity contenue.

Sommaire

RouterIdentity suivi de la Date , quand l’entrée a été publiée

+----+----+----+----+----+----+----+----+
| router_ident                          |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| published                             |
+----+----+----+----+----+----+----+----+
|size| RouterAddress 0                  |
+----+                                  +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| RouterAddress 1                       |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| RouterAddress ($size-1)               |
+                                       +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+-/-+----+----+----+
|psiz| options                          |
+----+----+----+----+-/-+----+----+----+
| signature                             |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+

router_ident :: `RouterIdentity`
                length -> >= 387+ bytes

published :: `Date`
             length -> 8 bytes

size :: `Integer`
        length -> 1 byte
        The number of `RouterAddress`es to follow, 0-255

addresses :: [`RouterAddress`]
             length -> varies

peer_size :: `Integer`
             length -> 1 byte
             The number of peer `Hash`es to follow, 0-255, unused, always zero
             value -> 0

options :: `Mapping`

signature :: `Signature`
             length -> 40 bytes or as specified in router_ident's key
                       certificate

Notes

• Le peer_size Integer peut être suivi d’une liste contenant autant de hachages de router. Ceci n’est actuellement pas utilisé. Cela était destiné à une forme de routes restreintes, qui n’est pas implémentée. Certaines implémentations peuvent nécessiter que la liste soit triée afin que la signature soit invariante. À rechercher avant d’activer cette fonctionnalité.

• La signature peut être vérifiée en utilisant la clé publique de signature du router_ident.

• Voir la page de base de données réseau NETDB-ROUTERINFO pour les options standard qui sont censées être présentes dans tous les router infos.

• Les très anciens routers exigeaient que les adresses soient triées par le SHA256 de leurs données afin que la signature soit invariante. Ceci n’est plus requis, et ne vaut pas la peine d’être implémenté pour la rétrocompatibilité.

JavaDoc: http://docs.i2p-projekt.de/net/i2p/data/router/RouterInfo.html

Instructions de livraison

Les instructions de livraison des messages tunnel sont définies dans la spécification des messages tunnel TUNNEL-DELIVERY .

Les instructions de livraison des messages garlic sont définies dans la spécification des messages I2NP GARLIC-DELIVERY .

Références

• ECIES
• ECIES-HYBRID
• ECIES-ROUTERS
• ELGAMAL
• ELGAMAL-AES
• GARLIC-DELIVERY
• I2CP
• I2NP
• NAMING
• NETDB-ROUTERINFO
• Prop134
• Prop169
• REGISTRY
• SSU
• TUNNEL-DELIVERY