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 dans l’ordre des octets réseau (gros-boutiste) 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 octets Integer

Chaîne de caractères

Description

Représente une chaîne 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 clé sont déduits du contexte ou sont spécifiés dans le Certificat de Clé d’une Destination ou RouterInfo, ou les champs dans un LeaseSet2 ou 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 uniquement 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 sont 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 le déchiffrement symétrique AES256.

Sommaire

32 octets

JavaDoc: http://docs.i2p-projekt.de/javadoc/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.

• 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 en tête si nécessaire.

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

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

SigningPrivateKey

Description

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

Sommaire

Le type et la longueur de la 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, sauf pour EdDSA et RedDSA, qui sont stockés et transmis en format Little Endian.

JavaDoc : http://docs.i2p-projekt.de/javadoc/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ée. 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 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, sauf pour EdDSA et RedDSA, qui sont stockés et transmis dans un format Little Endian.

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

Hachage

Description

Représente le SHA256 de certaines données.

Sommaire

32 octets

JavaDoc: http://docs.i2p-projekt.de/javadoc/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

Sommaire

32 octets

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

TunnelId

Description

Définit un identifiant unique à 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.

Contenu

4 octets Integer

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

Certificat

Description

Un certificat est un conteneur pour divers reçus ou preuves de travail utilisés dans tout 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

        case 0 -> NULL
        case 1 -> HASHCASH
        case 2 -> HIDDEN
        case 3 -> SIGNED
        case 4 -> MULTIPLE
        case 5 -> KEY

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 Certificat est toujours NULL, aucun autre n’est actuellement implémenté.

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

• Pour les Destinations , le Certificate peut être non-NULL. À partir de 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 toute donnée 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é avec tout logiciel qui analyse les Destinations et les Router Identities.

La charge utile du certificat de clé contient :

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

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

• Remplissage aléatoire si la longueur totale des deux clés est inférieure à 384 octets

• Partie complète ou première portion de la clé publique de signature

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 dispositions utilisant une clé publique crypto ElGamal et le type de clé publique de signature indiqué :

Notes

• Il est conseillé aux implémenteurs d’interdire les données excédentaires dans les Key Certificates. 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 courte qu’en utilisant un certificat KEY.

Mappage

Description

Un ensemble de mappages 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 sont dans des structures signées, où les entrées Mapping doivent être triées par clé, afin que la signature soit immuable. Ne pas trier 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 en UTF-8 mais dans l’implémentation actuelle, I2CP utilise UTF-8 mais I2NP ne le fait pas. 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 causer un échec de signature.

• Les mappages contenus dans les messages I2NP (par exemple dans un 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/javadoc/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

Directives de génération de remplissage

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étro-compatibles avec toutes les versions depuis 0.6 (2005). Voir la Proposition 161 pour le contexte et des informations supplémentaires.

Pour toute combinaison de types de clés actuellement utilisée 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 Destination et 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 paraissent corrompues ou non sécurisées. Cela fournit 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 (uniquement dans les Router Identities) 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 remplissage. 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 si nécessaire afin que la structure KeysAndCert complète soit hautement compressible dans les protocoles I2P tels que I2NP Database Store Message, Streaming SYN, handshake SSU2, et les datagrammes auxquels on peut répondre.

Exemples :

• Une Identité de Router avec un type de chiffrement X25519 et un type de signature Ed25519 contiendra 10 copies (320 octets) des données aléatoires, pour une économie d’environ 288 octets lors de la compression.

• 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é.

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

• 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) se trouve au milieu.

JavaDoc: http://docs.i2p-projekt.de/javadoc/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 des 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.

• Depuis 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 de chiffrement 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 prises en charge à partir de la version 0.9.48. Avant cela, toutes les RouterIdentities étaient ElGamal.

JavaDoc: http://docs.i2p-projekt.de/javadoc/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 de données aléatoires pour les champs de clé publique et 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 déprécié. 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 Crypto 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/javadoc/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 de 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

Notes

• Taille totale : 44 octets

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

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 un Integer de 1 octet spécifiant combien de structures Lease sont dans l’ensemble, suivi par les structures Lease réelles et enfin 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

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 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 Lease 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 n’est actuellement pas utilisé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. Attention lors de la publication d’un nouveau LeaseSet où le Lease le plus ancien est identique au Lease le plus ancien du LeaseSet précédent. Le routeur qui publie 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’il était 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 de 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/javadoc/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.

Notes

• Taille totale : 40 octets

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

OfflineSignature

Description

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

Sommaire

Contient une expiration, un sigtype et une SigningPublicKey transitoire, ainsi qu’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.

Notes

• 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 à partir de 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. 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, unless bit 2 is set.
  Bit 2: If 0, a standard published leaseset.
         If 1, this unencrypted leaseset will be blinded and encrypted when published.
         If this leaseset expires, query the blinded location in the netdb for a new one.
         If this bit is set to 1, set bit 1 to 1 also.
         As of release 0.9.42.
  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.

Notes

• 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 doivent limiter le taux 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ée 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

Préférence de clé de chiffrement

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 (avec des numéros plus élevés) 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 plutôt selon leur préférence, 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 les 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é, de sorte 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, entier en secondes. Entier positif. Exemple : “86400”. Un minimum de 86400 (un jour) est recommandé, voir la section Recommandations ci-dessous pour les 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 choisi. 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 peut être trouvé. Entier non négatif. Exemple : “25” Le port 0 est pris en charge 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”. 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 du seul octet 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é, de sorte 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é, de sorte que la signature soit invariante.

JavaDoc : http://docs.i2p-projekt.de/javadoc/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 depuis la version 0.9.38 ; voir la proposition 123 pour plus d’informations.

Sommaire

Hash SHA256 de la RouterIdentity du routeur 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/javadoc/net/i2p/data/MetaLease.html

MetaLeaseSet

Description

Contenu dans un message I2NP DatabaseStore de type 7. Défini depuis la version 0.9.38 ; prévu pour fonctionner à 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 par des options, Integer spécifiant combien de structures Lease2 sont dans l’ensemble, suivi par les 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                      |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| 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-to-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/javadoc/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é aveuglée et la date d’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 seul octet 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.

• Le masquage 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, bien que nous n’utilisions pas le format LeaseSet2Header ici)

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

RouterAddress

Description

Cette structure définit les moyens de contacter un router à travers 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 de router utilise. Enfin, il y a un Mapping contenant toutes les options spécifiques au transport nécessaires pour établir la connexion, telles que l’adresse IP, le numéro de port, l’adresse e-mail, 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 généralement de 5 ou 6 pour SSU, et de 10 ou 11 pour NTCP.

• L’expiration est actuellement inutilisé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 une autre utilisation pour ces octets) sera un changement incompatible avec les versions antérieures. Les routeurs 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 que non obligatoires, sont standard et attendues 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/javadoc/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 la 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

• La peer_size Integer peut être suivie d’une liste contenant autant de hachages de router. Ceci n’est actuellement pas utilisé. C’était prévu pour une forme de routes restreintes, qui n’est pas implémentée. Certaines implémentations peuvent exiger 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 base de données réseau NETDB-ROUTERINFO pour les options standard qui sont censées être présentes dans toutes les informations de router.

• Les très anciens routers exigeaient que les adresses soient triées par le SHA256 de leurs données pour 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/javadoc/net/i2p/data/router/RouterInfo.html

Instructions de livraison

Les Instructions de Livraison de Message 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