Specifikace běžných struktur

Tento dokument popisuje některé datové typy společné všem I2P protokolům, jako je I2NP , I2CP , SSU , atd.

Specifikace běžného typu

Celé číslo

Popis

Představuje nezáporné celé číslo.

Obsah

1 až 8 bajtů v síťovém pořadí bajtů (big endian) reprezentujících neznaménkové celé číslo.

Datum

Popis

Počet milisekund od půlnoci 1. ledna 1970 v časovém pásmu GMT. Pokud je číslo 0, datum je nedefinované nebo null.

Obsah

8 bajtový Integer

Řetězec

Popis

Představuje řetězec kódovaný v UTF-8.

Obsah

1 nebo více bajtů, kde první bajt je počet bajtů (ne znaků!) v řetězci a zbývajících 0-255 bajtů je pole znaků kódované v UTF-8 bez ukončení nulovým znakem. Limit délky je 255 bajtů (ne znaků). Délka může být 0.

PublicKey

Popis

Tato struktura se používá v ElGamal nebo jiném asymetrickém šifrování a představuje pouze exponent, nikoli prvočísla, která jsou konstantní a definována ve specifikaci kryptografie ELGAMAL . Jiná schémata šifrování jsou v procesu definování, viz tabulka níže.

Obsah

Typ a délka klíče jsou odvozeny z kontextu nebo specifikovány v Key Certificate cíle nebo RouterInfo, nebo v polích v LeaseSet2 či jiné datové struktuře. Výchozím typem je ElGamal. Od verze 0.9.38 mohou být podporovány další typy v závislosti na kontextu. Klíče jsou ve formátu big-endian, pokud není uvedeno jinak.

Klíče X25519 jsou podporovány v Destinations a LeaseSet2 od vydání 0.9.44. Klíče X25519 jsou podporovány v RouterIdentities od vydání 0.9.48.

PrivateKey

Popis

Tato struktura se používá v ElGamal nebo jiných asymetrických šifrováních, představuje pouze exponent, nikoli prvočísla, která jsou konstantní a definovaná ve specifikaci kryptografie ELGAMAL . Další šifrovací schémata jsou v procesu definování, viz tabulka níže.

Obsah

Typ a délka klíče jsou odvozeny z kontextu nebo jsou uloženy samostatně v datové struktuře nebo v souboru soukromého klíče. Výchozím typem je ElGamal. Od verze 0.9.38 mohou být podporovány další typy, v závislosti na kontextu. Klíče jsou ve formátu big-endian, pokud není uvedeno jinak.

SessionKey

Popis

Tato struktura se používá pro symetrické šifrování a dešifrování AES256.

Obsah

32 bajtů

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

SigningPublicKey

Popis

Tato struktura se používá pro ověřování podpisů.

Obsah

Typ a délka klíče jsou odvozeny z kontextu nebo jsou specifikovány v Key Certificate příslušného Destination. Výchozím typem je DSA_SHA1. Od verze 0.9.12 mohou být podporovány i další typy v závislosti na kontextu.

• Když je klíč složen ze dvou prvků (například body X,Y), je serializován tak, že se každý prvek doplní na délku/2 s úvodními nulami, pokud je to nutné.

• Všechny typy jsou Big Endian, kromě EdDSA a RedDSA, které jsou ukládány a přenášeny ve formátu Little Endian.

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

SigningPrivateKey

Popis

Tato struktura se používá pro vytváření podpisů.

Obsah

Typ a délka klíče jsou specifikovány při vytvoření. Výchozí typ je DSA_SHA1. Od verze 0.9.12 mohou být podporovány další typy v závislosti na kontextu.

• Když je klíč složen ze dvou prvků (například body X,Y), je serializován tak, že se každý prvek doplní na délku/2 úvodními nulami, pokud je to nutné.

• Všechny typy jsou Big Endian, kromě EdDSA a RedDSA, které jsou uloženy a přenášeny ve formátu Little Endian.

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

Podpis

Popis

Tato struktura představuje podpis nějakých dat.

Obsah

Typ a délka podpisu se odvozují z typu použitého klíče. Výchozím typem je DSA_SHA1. Od verze 0.9.12 mohou být podporovány i jiné typy, v závislosti na kontextu.

• Když je podpis složen ze dvou prvků (například hodnoty R,S), je serializován tak, že každý prvek je doplněn na délku/2 úvodními nulami, pokud je to nutné.

• Všechny typy jsou Big Endian, kromě EdDSA a RedDSA, které jsou uloženy a přenášeny ve formátu Little Endian.

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

Hash

Popis

Představuje SHA256 hash některých dat.

Obsah

32 bajtů

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

Značka relace

Poznámka: Session Tags pro ECIES-X25519 destinace (ratchet) a ECIES-X25519 routery mají 8 bajtů. Viz ECIES a ECIES-ROUTERS .

Popis

Náhodné číslo

Obsah

32 bajtů

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

TunnelId

Popis

Definuje identifikátor, který je jedinečný pro každý router v tunnelu. Tunnel ID je obecně větší než nula; nepoužívejte hodnotu nula kromě zvláštních případů.

Obsah

4 bajtové Integer

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

Certifikát

Popis

Certifikát je kontejner pro různé doklady nebo důkazy prací používané v síti I2P.

Obsah

1 byte Integer specifikující typ certifikátu, následovaný 2 byte Integer specifikujícím velikost dat certifikátu, poté tolik bytů.

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

type :: Integer
        length -> 1 byte

length :: Integer
          length -> 2 bytes

payload :: data
           length -> $length bytes

Poznámky

• Pro Router Identities je Certificate vždy NULL až do verze 0.9.15. Od verze 0.9.16 se používá Key Certificate pro specifikaci typů klíčů. Od verze 0.9.48 jsou povoleny typy veřejných šifrovacích klíčů X25519. Viz níže.

• Pro Garlic Cloves je Certificate vždy NULL, žádné jiné nejsou v současnosti implementovány.

• Pro Garlic Messages je Certificate vždy NULL, žádné jiné nejsou v současnosti implementovány.

• Pro Destinations může být Certificate nenulový. Od verze 0.9.12 může být Key Certificate použit k určení typu veřejného podepisovacího klíče. Viz níže.

• Implementátorům se doporučuje zakázat nadbytečná data v certifikátech. Měla by být vynucena odpovídající délka pro každý typ certifikátu.

Typy certifikátů

Jsou definovány následující typy certifikátů:

Klíčové certifikáty byly zavedeny ve verzi 0.9.12. Před touto verzí byly všechny PublicKeys 256-bajtové ElGamal klíče a všechny SigningPublicKeys byly 128-bajtové DSA-SHA1 klíče. Klíčový certifikát poskytuje mechanismus k označení typu PublicKey a SigningPublicKey v Destination nebo RouterIdentity a k zabalení jakýchkoli klíčových dat přesahujících standardní délky.

Udržováním přesně 384 bajtů před certifikátem a umístěním jakýchkoli přebytečných klíčových dat do certifikátu zachováváme kompatibilitu pro jakýkoli software, který parsuje Destinations a Router Identities.

Obsah certifikátu klíče obsahuje:

Definované typy veřejných klíčů pro podepisování jsou:

• Kompletní nebo první část kryptografického veřejného klíče

• Náhodné vyplnění, pokud je celková délka obou klíčů menší než 384 bajtů

• Úplná nebo první část veřejného klíče pro podepisování

Crypto Public Key je zarovnán na začátku a Signing Public Key je zarovnán na konci. Padding (pokud existuje) je uprostřed. Délky a hranice počátečních klíčových dat, paddingu a přebytečných klíčových dat v certifikátech nejsou explicitně specifikovány, ale jsou odvozeny z délek specifikovaných typů klíčů. Pokud celková délka Crypto a Signing Public Keys překročí 384 bajtů, zbytek bude obsažen v Key Certificate. Pokud délka Crypto Public Key není 256 bajtů, metoda pro určení hranice mezi dvěma klíči bude specifikována v budoucí revizi tohoto dokumentu.

Příklady rozložení používající ElGamal Crypto Public Key a uvedený typ Signing Public Key:

Poznámky

• Implementátoři jsou upozorněni, aby zakázali nadměrná data v Key Certificates. Měla by být vynucována odpovídající délka pro každý typ certifikátu.

• KEY certifikát s typy 0,0 (ElGamal,DSA_SHA1) je povolen, ale nedoporučuje se. Není dobře otestován a může způsobovat problémy v některých implementacích. Použijte NULL certifikát v kanonické reprezentaci (ElGamal,DSA_SHA1) Destination nebo RouterIdentity, což bude o 4 bajty kratší než použití KEY certifikátu.

Mapování

Popis

Sada mapování klíč/hodnota nebo vlastností

Obsah

2-bajtové celé číslo velikosti následované řadou párů String=String;.

VAROVÁNÍ: Většina použití Mapping je v podepsaných strukturách, kde musí být položky Mapping seřazeny podle klíče, aby byl podpis neměnný. Neseřazení podle klíče bude mít za následek selhání podpisu!

+----+----+----+----+----+----+----+----+
|  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 ';'

Poznámky

• Kódování není optimální - potřebujeme buď znaky ‘=’ a ‘;’, nebo délky řetězců, ale ne oboje

• Některá dokumentace uvádí, že řetězce nesmí obsahovat ‘=’ nebo ‘;’, ale toto kódování je podporuje

• Řetězce jsou definovány jako UTF-8, ale v současné implementaci I2CP používá UTF-8, zatímco I2NP ne. Například UTF-8 řetězce v mapování možností RouterInfo ve zprávě I2NP Database Store budou poškozeny.

• Kódování umožňuje duplicitní klíče, avšak při jakémkoli použití, kde je mapování podepsané, mohou duplicity způsobit selhání podpisu.

• Mapování obsažená v I2NP zprávách (např. v RouterAddress nebo RouterInfo) musí být seřazena podle klíče, aby byl podpis neměnný. Duplicitní klíče nejsou povoleny.

• Mapování obsažená v I2CP SessionConfig musí být seřazena podle klíče, aby byl podpis neměnný. Duplicitní klíče nejsou povoleny.

• Metoda řazení je definována stejně jako v Java String.compareTo(), používající Unicode hodnotu znaků.

• Ačkoli to závisí na aplikaci, klíče a hodnoty jsou obecně citlivé na velikost písmen.

• Limity délky řetězců klíče a hodnoty jsou 255 bajtů (ne znaků) každý, plus bajt délky. Bajt délky může být 0.

• Celkový limit délky je 65535 bajtů, plus 2bajtové pole velikosti, nebo celkem 65537.

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

Specifikace společné struktury

KeysAndCert

Popis

Veřejný klíč pro šifrování, veřejný klíč pro podepisování a certifikát, používané buď jako RouterIdentity nebo Destination.

Obsah

PublicKey následovaný SigningPublicKey a poté 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

Tyto pokyny byly navrženy v Návrhu 161 a implementovány v API verzi 0.9.57. Tyto pokyny jsou zpětně kompatibilní se všemi verzemi od 0.6 (2005). Pro kontext a další informace viz Návrh 161.

Pro jakoukoliv aktuálně používanou kombinaci typů klíčů jinou než ElGamal + DSA-SHA1 bude přítomno vyplnění. Navíc pro cíle je 256-bytové pole veřejného klíče nepoužívané od verze 0.6 (2005).

Implementátoři by měli generovat náhodná data pro veřejné klíče Destination a padding pro identitu Destination a router tak, aby byla kompresibilní v různých I2P protokolech a zároveň zůstala bezpečná, a aby Base 64 reprezentace nevypadaly jako poškozené nebo nebezpečné. Toto poskytuje většinu výhod odstranění padding polí bez jakýchkoli rušivých změn protokolu.

Přísně vzato, samotný 32-bytový veřejný klíč pro podepisování (jak v Destinations, tak v Router Identities) a 32-bytový veřejný klíč pro šifrování (pouze v Router Identities) je náhodné číslo, které poskytuje veškerou entropii potřebnou k tomu, aby SHA-256 hashe těchto struktur byly kryptograficky silné a náhodně distribuované v netDb DHT.

Pro maximální opatrnost však doporučujeme použít minimálně 32 bajtů náhodných dat v poli veřejného klíče ElG a ve výplni. Navíc, pokud by všechna pole byla nulová, Base 64 destinace by obsahovaly dlouhé sekvence znaků AAAA, což by mohlo vyvolat poplach nebo zmatení u uživatelů.

Opakujte 32 bajtů náhodných dat podle potřeby tak, aby byla celá struktura KeysAndCert vysoce kompresibilní v I2P protokolech jako je I2NP Database Store Message, Streaming SYN, SSU2 handshake a repliable Datagrams.

Příklady:

• Router Identity s typem šifrování X25519 a typem podpisu Ed25519 bude obsahovat 10 kopií (320 bajtů) náhodných dat, což při kompresi ušetří přibližně 288 bajtů.

• Destination s typem podpisu Ed25519 bude obsahovat 11 kopií (352 bajtů) náhodných dat, což při kompresi ušetří přibližně 320 bajtů.

Implementace musí samozřejmě ukládat celou strukturu o velikosti 387+ bytů, protože SHA-256 hash struktury pokrývá celý obsah.

Poznámky

• Nepředpokládejte, že mají vždy 387 bajtů! Mají 387 bajtů plus délku certifikátu specifikovanou na bajtech 385-386, která může být nenulová.

• Od vydání 0.9.12, pokud je certifikát Key Certificate, hranice polí klíčů se mohou lišit. Podrobnosti najdete v sekci Key Certificate výše.

• Kryptografický veřejný klíč je zarovnán na začátku a podepisující veřejný klíč je zarovnán na konci. Výplň (pokud existuje) je uprostřed.

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

RouterIdentity

Popis

Definuje způsob, jak jednoznačně identifikovat konkrétní router

Obsah

Identické s KeysAndCert.

Viz KeysAndCert pro pokyny k generování náhodných dat pro pole padding.

Poznámky

• Certifikát pro RouterIdentity byl vždy NULL až do vydání 0.9.12.

• Nepředpokládejte, že tyto jsou vždy 387 bajtů! Jsou to 387 bajtů plus délka certifikátu specifikovaná na bajtech 385-386, která může být nenulová.

• Od verze 0.9.12, pokud je certifikát Key Certificate, hranice polí klíčů se mohou lišit. Podrobnosti najdete v sekci Key Certificate výše.

• Kryptografický veřejný klíč je zarovnán na začátku a podepisovací veřejný klíč je zarovnán na konci. Výplň (pokud existuje) je uprostřed.

• RouterIdentity s certifikátem klíče a veřejným klíčem ECIES_X25519 jsou podporovány od verze 0.9.48. Před tím byly všechny RouterIdentity typu ElGamal.

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

Cíl

Popis

Destination definuje konkrétní koncový bod, kam mohou být zprávy směrovány pro bezpečné doručení.

Obsah

Identické s KeysAndCert , s výjimkou toho, že veřejný klíč se nikdy nepoužívá a může obsahovat náhodná data namísto platného ElGamal veřejného klíče.

Viz KeysAndCert pro pokyny k generování náhodných dat pro pole veřejného klíče a výplně.

Poznámky

• Veřejný klíč destinace byl použit pro staré i2cp-to-i2cp šifrování, které bylo zakázáno ve verzi 0.6 (2005), v současnosti je nepoužíván kromě IV pro LeaseSet šifrování, které je zastaralé. Místo toho se používá veřejný klíč v LeaseSet.

• Nepředpokládejte, že mají vždy 387 bajtů! Mají 387 bajtů plus délku certifikátu specifikovanou na bajtech 385-386, která může být nenulová.

• Od vydání 0.9.12, pokud je certifikát Key Certificate, hranice polí klíčů se mohou lišit. Podrobnosti najdete v sekci Key Certificate výše.

• Crypto Public Key je zarovnán na začátku a Signing Public Key je zarovnán na konci. Výplň (pokud existuje) je uprostřed.

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

Lease

Popis

Definuje autorizaci pro konkrétní tunnel k přijímání zpráv určených pro Destination .

Obsah

SHA256 Hash RouterIdentity gateway routeru, poté TunnelId a nakonec konečné Date .

+----+----+----+----+----+----+----+----+
| 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

Popis

Obsahuje všechny aktuálně autorizované Leases pro konkrétní Destination , PublicKey , kterým lze šifrovat garlic zprávy, a poté SigningPublicKey , který lze použít k odvolání této konkrétní verze struktury. LeaseSet je jedna ze dvou struktur uložených v síťové databázi (druhou je RouterInfo ) a je klíčována pod SHA256 obsažené Destination .

Obsah

Destination , následovaná PublicKey pro šifrování, poté SigningPublicKey , který lze použít k odvolání této verze LeaseSet, pak 1 byte Integer specifikující kolik struktur Lease je v sadě, následované skutečnými strukturami Lease a nakonec Signature předchozích bytů podepsaná SigningPrivateKey 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

• Veřejný klíč cíle byl použit pro staré I2CP-to-I2CP šifrování, které bylo zakázáno ve verzi 0.6, v současnosti se nepoužívá.

• Šifrovací klíč se používá pro end-to-end ElGamal/AES+SessionTag šifrování ELGAMAL-AES . V současnosti se generuje znovu při každém spuštění routeru, není trvalý.

• Podpis může být ověřen pomocí veřejného podepisovacího klíče cíle.

• LeaseSet s nulou Lease je povolen, ale nepoužívá se. Byl určen pro revokaci LeaseSet, což není implementováno. Všechny varianty LeaseSet2 vyžadují alespoň jeden Lease.

• signing_key je v současnosti nepoužíván. Byl zamýšlen pro zrušení LeaseSet, které není implementováno. V současnosti se generuje znovu při každém spuštění routeru, není perzistentní. Typ signing key je vždy stejný jako typ signing key cíle.

• Nejdřívější vypršení všech Lease je považováno za časovou značku nebo verzi LeaseSet. Routery obecně nepřijmou uložení LeaseSet, pokud není “novější” než současný. Buďte opatrní při publikování nového LeaseSet, kde nejstarší Lease je stejný jako nejstarší Lease v předchozím LeaseSet. Publikující router by v takovém případě měl obecně zvýšit vypršení nejstaršího Lease alespoň o 1 ms.

• Před verzí 0.9.7, když byl zahrnut ve zprávě DatabaseStore odeslané původním routerem, router nastavil všechna vypršení publikovaných leaseů na stejnou hodnotu, tu nejčasnějšího lease. Od verze 0.9.7 router publikuje skutečné vypršení lease pro každý lease. Toto je implementační detail a není součástí specifikace struktur.

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

Lease2

Popis

Definuje autorizaci pro konkrétní tunnel přijímat zprávy zaměřené na Destination . Stejné jako Lease , ale se 4-bytovým end_date. Používá se v LeaseSet2 . Podporováno od verze 0.9.38; pro více informací viz návrh 123.

Obsah

SHA256 Hash RouterIdentity gateway routeru, poté TunnelId a nakonec 4bajtové datum ukončení.

+----+----+----+----+----+----+----+----+
| 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.

• Celková velikost: 40 bajtů

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

OfflineSignature

Popis

Toto je volitelná část LeaseSet2Header . Také se používá ve streaming a I2CP. Podporováno od verze 0.9.38; více informací viz návrh 123.

Obsah

Obsahuje expiraci, sigtype a přechodný SigningPublicKey a 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.

• Tato sekce může a měla by být vygenerována offline.

LeaseSet2Header

Popis

Toto je společná část LeaseSet2 a MetaLeaseSet . Podporováno od verze 0.9.38; více informací v návrhu 123.

Obsah

Obsahuje Destination , dvě časová razítka a volitelný OfflineSignature .

+----+----+----+----+----+----+----+----+
| 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 bajty):

  • Bit 0: Pokud je nastaven, jsou přítomny offline klíče (viz OfflineSignature )
  • Bit 1: Pokud je nastaven, jedná se o nepublikovaný leaseset
  • Bit 2: Pokud je nastaven, jedná se o zaslepený leaseset
  • Bity 15-3: Rezervováno, nastaveno na 0

• Celková velikost: minimálně 395 bajtů

• Maximální skutečný čas vypršení je přibližně 660 (11 minut) pro LeaseSet2 a 65535 (plných 18,2 hodiny) pro MetaLeaseSet .

• LeaseSet (1) neměl pole ‘published’, takže verzování vyžadovalo hledání nejstaršího lease. LeaseSet2 přidává pole ‘published’ s rozlišením jedné sekundy. Routery by měly omezovat rychlost odesílání nových leaseset do floodfill na rychlost mnohem pomalejší než jednou za sekundu (na destinaci). Pokud to není implementováno, pak kód musí zajistit, že každý nový leaseset má čas ‘published’ nejméně o sekundu pozdější než předchozí, jinak floodfill neuloží ani nezaplavní nový leaseset.

LeaseSet2

Popis

Obsaženo v I2NP DatabaseStore zprávě typu 3. Podporováno od verze 0.9.38; více informací najdete v návrhu 123.

Obsahuje všechny aktuálně autorizované Lease2 pro konkrétní Destination a PublicKey , kterým mohou být garlic zprávy šifrovány. LeaseSet je jedna ze dvou struktur uložených v síťové databázi (druhou je RouterInfo ) a je klíčována pod SHA256 obsaženého Destination .

Obsah

LeaseSet2Header , následovaný možnostmi, pak jeden nebo více PublicKey pro šifrování, Integer určující kolik Lease2 struktur je v sadě, následovaný skutečnými Lease2 strukturami a nakonec Signature předchozích bytů podepsaný Destination SigningPrivateKey nebo přechodným klíčem.

+----+----+----+----+----+----+----+----+
|         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

Pro publikované (serverové) leaseSety jsou šifrovací klíče seřazeny podle preference serveru, s nejpreferovanějším jako prvním. Pokud klienti podporují více než jeden typ šifrování, doporučuje se, aby respektovali preferenci serveru a vybrali první podporovaný typ jako šifrovací metodu pro připojení k serveru. Obecně jsou novější (s vyšším číslem) typy klíčů bezpečnější nebo efektivnější a jsou preferované, takže klíče by měly být uvedeny v opačném pořadí podle typu klíče.

Klienti však mohou, v závislosti na implementaci, vybírat podle svých vlastních preferencí, nebo použít nějakou metodu k určení “kombinované” preference. To může být užitečné jako konfigurační možnost nebo pro ladění.

Pořadí klíčů v nepublikovaných (klientských) leaseStech v podstatě nezáleží, protože spojení obvykle nebudou pokoušena k nepublikovaným klientům. Pokud se toto pořadí nepoužívá k určení kombinované preference, jak je popsáno výše.

Možnosti

Od API 0.9.66 je definován standardní formát pro možnosti záznamů služeb. Podrobnosti najdete v návrhu 167. V budoucnu mohou být definovány další možnosti kromě záznamů služeb s použitím jiného formátu.

Volby LS2 MUSÍ být seřazeny podle klíče, takže podpis je neměnný.

Možnosti záznamu služby jsou definovány následovně:

• serviceoption := optionkey optionvalue
• optionkey := _service._proto
• service := Symbolické jméno požadované služby. Musí být psané malými písmeny. Příklad: “smtp”. Povolené znaky jsou [a-z0-9-] a nesmí začínat nebo končit znakem ‘-’. Musí být použity standardní identifikátory z REGISTRY nebo Linux /etc/services, pokud jsou tam definovány.
• proto := Transportní protokol požadované služby. Musí být psán malými písmeny, buď “tcp” nebo “udp”. “tcp” znamená streamování a “udp” znamená odpověditelné datagramy. Indikátory protokolů pro surové datagramy a datagram2 mohou být definovány později. Povolené znaky jsou [a-z0-9-] a nesmí začínat nebo končit znakem ‘-’.
• optionvalue := self | srvrecord[,srvrecord]*
• self := “0” ttl port [appoptions]
• srvrecord := “1” ttl priority weight port target [appoptions]
• ttl := doba života, celočíselné sekundy. Kladné číslo. Příklad: “86400”. Doporučuje se minimum 86400 (jeden den), podrobnosti viz sekce Doporučení níže.
• priority := Priorita cílového hostitele, nižší hodnota znamená vyšší preference. Nezáporné číslo. Příklad: “0” Užitečné pouze při více než jednom záznamu, ale vyžadované i při jediném záznamu.
• weight := Relativní váha pro záznamy se stejnou prioritou. Vyšší hodnota znamená větší šanci výběru. Nezáporné číslo. Příklad: “0” Užitečné pouze při více než jednom záznamu, ale vyžadované i při jediném záznamu.
• port := I2CP port, na kterém má být služba nalezena. Nezáporné číslo. Příklad: “25” Port 0 je podporován, ale není doporučen.
• target := Hostname nebo b32 cíle poskytujícího službu. Platný hostname podle NAMING . Musí být psán malými písmeny. Příklad: “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p” nebo “example.i2p”. b32 je doporučeno, pokud hostname není “dobře známý”, tj. v oficiálních nebo výchozích adresářích.
• appoptions := libovolný text specifický pro aplikaci, nesmí obsahovat " " nebo “,”. Kódování je UTF-8.

Příklady:

V LS2 pro aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p, ukazující na jeden SMTP server:

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

V LS2 pro aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p, ukazující na dva SMTP servery:

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

V LS2 pro bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p, odkazující sám na sebe jako SMTP server:

“_smtp._tcp” “0 999999 25”

Poznámky

• Veřejný klíč cílového uzlu byl používán pro staré I2CP-to-I2CP šifrování, které bylo zakázáno ve verzi 0.6, v současnosti se nepoužívá.

• Šifrovací klíče se používají pro end-to-end ElGamal/AES+SessionTag šifrování ELGAMAL-AES (typ 0) nebo jiná end-to-end šifrovací schémata. Viz ECIES a návrhy 145 a 156. Mohou být generovány znovu při každém spuštění routeru nebo mohou být trvalé. X25519 (typ 4, viz ECIES ) je podporováno od verze 0.9.44.

• Podpis je nad daty výše, PŘEDŘAZENÝMI jedním bytem obsahujícím typ DatabaseStore (3).

• Podpis může být ověřen pomocí veřejného klíče pro podepisování destinace, nebo přechodného veřejného klíče pro podepisování, pokud je offline podpis zahrnut v hlavičce leaseset2.

• Délka klíče je poskytována pro každý klíč, takže floodfill a klienti mohou analyzovat strukturu i v případě, že nejsou všechny typy šifrování známé nebo podporované.

• Viz poznámka k poli ‘published’ v LeaseSet2Header

• Mapování možností, pokud je velikost větší než jedna, musí být seřazeno podle klíče, aby byl podpis neměnný.

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

MetaLease

Popis

Definuje autorizaci pro konkrétní tunnel pro přijímání zpráv cílených na Destination . Stejné jako Lease2 , ale s příznaky a cenou namísto tunnel id. Používá MetaLeaseSet . Obsaženo v I2NP DatabaseStore zprávě typu 7. Podporováno od verze 0.9.38; viz návrh 123 pro více informací.

Obsah

SHA256 Hash RouterIdentity gateway routeru, poté příznaky a náklady, a nakonec 4bajtové datum ukončení.

+----+----+----+----+----+----+----+----+
| 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.

Poznámky

• Celková velikost: 40 bytů

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

MetaLeaseSet

Popis

Obsaženo v I2NP DatabaseStore zprávě typu 7. Definováno od verze 0.9.38; naplánováno k fungování od verze 0.9.40; viz návrh 123 pro více informací.

Obsahuje všechny aktuálně autorizované MetaLease pro konkrétní Destination a PublicKey , kterým lze šifrovat garlic zprávy. LeaseSet je jedna ze dvou struktur uložených v síťové databázi (druhou je RouterInfo ) a je indexována pod SHA256 obsaženého Destination .

Obsah

LeaseSet2Header , následovaný možnostmi, Integer specifikující kolik struktur Lease2 je v sadě, následovaný skutečnými strukturami Lease2 a nakonec Signature předchozích bytů podepsaných SigningPrivateKey Destination nebo přechodným klíčem.

+----+----+----+----+----+----+----+----+
|         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

Poznámky

• Veřejný klíč destinace byl používán pro staré I2CP-to-I2CP šifrování, které bylo zakázáno ve verzi 0.6, v současnosti se nepoužívá.

• Podpis je nad výše uvedenými daty, PŘEDŘAZENÝMI s jediným bajtem obsahujícím typ DatabaseStore (7).

• Podpis může být ověřen pomocí veřejného klíče pro podepisování cíle, nebo přechodného veřejného klíče pro podepisování, pokud je v hlavičce leaseset2 zahrnut offline podpis.

• Viz poznámka k poli ‘published’ v LeaseSet2Header

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

EncryptedLeaseSet

Popis

Obsaženo ve zprávě I2NP DatabaseStore typu 5. Definováno od verze 0.9.38; funkční od verze 0.9.39; více informací viz návrh 123.

Pouze blinded klíč a doba vypršení jsou viditelné v nešifrovaném textu. Skutečný leaseSet je šifrovaný.

Obsah

Dvoubajtový typ podpisu, zaslepený SigningPrivateKey , čas publikování, vypršení a příznaky. Poté dvoubajtová délka následovaná zašifrovanými daty. Nakonec Signature předchozích bajtů podepsaná zaslepeným SigningPrivateKey nebo přechodným klíčem.

+----+----+----+----+----+----+----+----+
| 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

Poznámky

• Veřejný klíč cíle byl používán pro staré I2CP-to-I2CP šifrování, které bylo zakázáno ve verzi 0.6, v současnosti se nepoužívá.

• Podpis je nad výše uvedenými daty, PŘEDPOJENÝMI s jediným bajtem obsahujícím typ DatabaseStore (5).

• Podpis může být ověřen pomocí veřejného klíče pro podepisování cíle, nebo přechodného veřejného klíče pro podepisování, pokud je offline podpis zahrnut v hlavičce leaseset2.

• Blinding a šifrování jsou specifikovány v EncryptedLeaseSet

• Tato struktura nepoužívá LeaseSet2Header .

• Maximální skutečný čas vypršení je přibližně 660 (11 minut), pokud se nejedná o zašifrovaný MetaLeaseSet .

• Viz návrh 123 pro poznámky k používání offline podpisů s šifrovanými leaseSety.

• Viz poznámka k poli ‘published’ v LeaseSet2Header (stejný problém, i když zde nepoužíváme formát LeaseSet2Header)

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

RouterAddress

Popis

Tato struktura definuje způsoby, jak kontaktovat router prostřednictvím transportního protokolu.

Obsah

1 byte Integer definující relativní náklady na použití adresy, kde 0 je zdarma a 255 je drahé, následované datem vypršení Date , po kterém by adresa neměla být použita, nebo pokud je null, adresa nikdy nevyprší. Poté následuje String definující transportní protokol, který tato router adresa používá. Nakonec je zde Mapping obsahující všechny transportně specifické možnosti potřebné k navázání spojení, jako je IP adresa, číslo portu, e-mailová adresa, URL atd.

+----+----+----+----+----+----+----+----+
|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`

Poznámky

• Cena je typicky 5 nebo 6 pro SSU a 10 nebo 11 pro NTCP.

• Expiration (vypršení platnosti) se v současnosti nepoužívá, vždy null (všechny nuly). Od vydání 0.9.3 se předpokládá nulové expiration a neukládá se, takže jakékoliv nenulové expiration způsobí selhání ověření podpisu RouterInfo. Implementace expiration (nebo jiné použití těchto bajtů) bude změna nekompatibilní zpětně. Routery MUSÍ nastavit toto pole na všechny nuly. Od vydání 0.9.12 je nenulové pole expiration opět rozpoznáváno, nicméně musíme počkat několik vydání, než toto pole použijeme, dokud ho nebude rozpoznávat naprostá většina sítě.

• Následující možnosti, ačkoli nejsou vyžadovány, jsou standardní a očekává se, že budou přítomny ve většině router adres: “host” (IPv4 nebo IPv6 adresa nebo název hostitele) a “port”.

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

RouterInfo

Popis

Definuje všechna data, která chce router publikovat, aby je mohla síť vidět. RouterInfo je jedna ze dvou struktur uložených v síťové databázi (druhou je LeaseSet ) a je indexována pod SHA256 hash obsaženého RouterIdentity .

Obsah

RouterIdentity následovaná Date , kdy byl záznam publikován

+----+----+----+----+----+----+----+----+
| 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

Poznámky

• Hodnota peer_size Integer může být následována seznamem tolika router hashů. Toto se v současnosti nepoužívá. Bylo určeno pro formu omezených tras, která není implementována. Některé implementace mohou vyžadovat, aby byl seznam seřazen, takže signatura je invariantní. Je třeba toto prozkoumat před povolením této funkce.

• Podpis může být ověřen pomocí veřejného podpisového klíče router_ident.

• Viz stránku síťové databáze NETDB-ROUTERINFO pro standardní možnosti, které se očekávají ve všech router infos.

• Velmi staré routery vyžadovaly, aby byly adresy seřazeny podle SHA256 jejich dat, takže podpis je invariantní. To už není vyžadováno a nestojí za implementaci kvůli zpětné kompatibilitě.

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

Instrukce pro doručení

Instrukce pro doručování tunnel zpráv jsou definovány ve specifikaci Tunnel Message Specification TUNNEL-DELIVERY .

Instrukce pro doručování Garlic zpráv jsou definovány ve specifikaci I2NP zpráv GARLIC-DELIVERY .

Reference

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