Especificação de estruturas comuns

Este documento descreve alguns tipos de dados comuns a todos os protocolos I2P, como I2NP , I2CP , SSU , etc.

Especificação de tipo comum

Inteiro

Descrição

Representa um número inteiro não-negativo.

Conteúdo

1 a 8 bytes em ordem de bytes de rede (big endian) representando um número inteiro sem sinal.

Data

Descrição

O número de milissegundos desde a meia-noite de 1º de janeiro de 1970 no fuso horário GMT. Se o número for 0, a data é indefinida ou nula.

Conteúdo

8 bytes Integer

String

Descrição

Representa uma string codificada em UTF-8.

Conteúdo

1 ou mais bytes onde o primeiro byte é o número de bytes (não caracteres!) na string e os 0-255 bytes restantes são o array de caracteres codificado em UTF-8 sem terminação nula. O limite de comprimento é 255 bytes (não caracteres). O comprimento pode ser 0.

PublicKey

Descrição

Esta estrutura é usada em ElGamal ou outra criptografia assimétrica, representando apenas o expoente, não os primos, que são constantes e definidos na especificação de criptografia ELGAMAL . Outros esquemas de criptografia estão em processo de definição, veja a tabela abaixo.

Conteúdo

O tipo e comprimento da chave são inferidos do contexto ou especificados no Certificado de Chave de um Destino ou RouterInfo, ou nos campos em um LeaseSet2 ou outra estrutura de dados. O tipo padrão é ElGamal. A partir da versão 0.9.38, outros tipos podem ser suportados, dependendo do contexto. As chaves são big-endian, salvo indicação em contrário.

Chaves X25519 são suportadas em Destinations e LeaseSet2 a partir da versão 0.9.44. Chaves X25519 são suportadas em RouterIdentities a partir da versão 0.9.48.

PrivateKey

Descrição

Esta estrutura é usada na descriptografia ElGamal ou outras assimétricas, representando apenas o expoente, não os primos que são constantes e definidos na especificação de criptografia ELGAMAL . Outros esquemas de criptografia estão em processo de definição, veja a tabela abaixo.

Conteúdo

O tipo e comprimento da chave são inferidos do contexto ou são armazenados separadamente numa estrutura de dados ou num ficheiro de chave privada. O tipo padrão é ElGamal. A partir da versão 0.9.38, outros tipos podem ser suportados, dependendo do contexto. As chaves são big-endian salvo indicação em contrário.

SessionKey

Descrição

Esta estrutura é usada para criptografia e descriptografia simétrica AES256.

Conteúdo

32 bytes

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

SigningPublicKey

Descrição

Esta estrutura é usada para verificar assinaturas.

Conteúdo

O tipo e o comprimento da chave são inferidos do contexto ou são especificados no Key Certificate de um Destination. O tipo padrão é DSA_SHA1. A partir da versão 0.9.12, outros tipos podem ser suportados, dependendo do contexto.

• Quando uma chave é composta por dois elementos (por exemplo pontos X,Y), ela é serializada preenchendo cada elemento até comprimento/2 com zeros à esquerda se necessário.

• Todos os tipos são Big Endian, exceto para EdDSA e RedDSA, que são armazenados e transmitidos em formato Little Endian.

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

SigningPrivateKey

Descrição

Esta estrutura é usada para criar assinaturas.

Conteúdo

O tipo e comprimento da chave são especificados quando criada. O tipo padrão é DSA_SHA1. A partir da versão 0.9.12, outros tipos podem ser suportados, dependendo do contexto.

• Quando uma chave é composta por dois elementos (por exemplo pontos X,Y), ela é serializada preenchendo cada elemento com comprimento/2 com zeros à esquerda se necessário.

• Todos os tipos são Big Endian, exceto para EdDSA e RedDSA, que são armazenados e transmitidos em formato Little Endian.

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

Assinatura

Descrição

Esta estrutura representa a assinatura de alguns dados.

Conteúdo

O tipo e comprimento da assinatura são inferidos do tipo de chave utilizada. O tipo padrão é DSA_SHA1. A partir da versão 0.9.12, outros tipos podem ser suportados, dependendo do contexto.

• Quando uma assinatura é composta por dois elementos (por exemplo, valores R,S), ela é serializada preenchendo cada elemento até comprimento/2 com zeros à esquerda se necessário.

• Todos os tipos são Big Endian, exceto para EdDSA e RedDSA, que são armazenados e transmitidos em formato Little Endian.

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

Hash

Descrição

Representa o SHA256 de alguns dados.

Conteúdo

32 bytes

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

Tag de Sessão

Nota: Session Tags para destinos ECIES-X25519 (ratchet) e routers ECIES-X25519 são de 8 bytes. Consulte ECIES e ECIES-ROUTERS .

Descrição

Um número aleatório

Conteúdo

32 bytes

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

TunnelId

Descrição

Define um identificador único para cada router em um tunnel. Um Tunnel ID geralmente é maior que zero; não use um valor zero exceto em casos especiais.

Conteúdo

4 bytes Integer

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

Certificado

Descrição

Um certificado é um contêiner para vários recibos ou provas de trabalho usados em toda a rede I2P.

Conteúdo

1 byte Integer especificando o tipo de certificado, seguido por um Integer de 2 bytes especificando o tamanho da carga útil do certificado, depois essa quantidade de bytes.

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

Notas

• Para Router Identities , o Certificate é sempre NULL até a versão 0.9.15. A partir da 0.9.16, um Key Certificate é usado para especificar os tipos de chave. A partir da 0.9.48, tipos de chave pública de criptografia X25519 são permitidos. Veja abaixo.

• Para Garlic Cloves , o Certificado é sempre NULL, nenhum outro está atualmente implementado.

• Para Mensagens Garlic , o Certificado é sempre NULL, nenhum outro está atualmente implementado.

• Para Destinations , o Certificate pode ser não-NULL. A partir da versão 0.9.12, um Key Certificate pode ser usado para especificar o tipo de chave pública de assinatura. Veja abaixo.

• Os implementadores são aconselhados a proibir dados excessivos em Certificados. O comprimento apropriado para cada tipo de certificado deve ser aplicado.

Tipos de Certificados

Os seguintes tipos de certificado são definidos:

Os certificados de chave foram introduzidos na versão 0.9.12. Antes dessa versão, todas as PublicKeys eram chaves ElGamal de 256 bytes, e todas as SigningPublicKeys eram chaves DSA-SHA1 de 128 bytes. Um certificado de chave fornece um mecanismo para indicar o tipo da PublicKey e SigningPublicKey no Destination ou RouterIdentity, e para empacotar quaisquer dados de chave que excedam os comprimentos padrão.

Ao manter exatamente 384 bytes antes do certificado, e colocar quaisquer dados de chave excedentes dentro do certificado, mantemos compatibilidade para qualquer software que analise Destinations e Router Identities.

O payload do certificado de chave contém:

Os tipos de Chave Pública de Assinatura definidos são:

• Parte completa ou primeira porção da Chave Pública Criptográfica

• Preenchimento aleatório se o comprimento total das duas chaves for inferior a 384 bytes

• Porção completa ou primeira da Chave Pública de Assinatura

A Chave Pública de Criptografia é alinhada no início e a Chave Pública de Assinatura é alinhada no final. O preenchimento (se houver) fica no meio. Os comprimentos e limites dos dados iniciais da chave, do preenchimento e das porções de dados excedentes da chave nos certificados não são especificados explicitamente, mas são derivados dos comprimentos dos tipos de chave especificados. Se o comprimento total das Chaves Públicas de Criptografia e de Assinatura exceder 384 bytes, o restante será contido no Certificado de Chave. Se o comprimento da Chave Pública de Criptografia não for 256 bytes, o método para determinar a fronteira entre as duas chaves deve ser especificado em uma revisão futura deste documento.

Exemplos de layouts usando uma Chave Pública Criptográfica ElGamal e o tipo de Chave Pública de Assinatura indicado:

Notas

• Os implementadores são alertados para proibir dados em excesso nos Key Certificates. O comprimento apropriado para cada tipo de certificado deve ser aplicado.

• Um certificado KEY com tipos 0,0 (ElGamal,DSA_SHA1) é permitido mas desencorajado. Não é bem testado e pode causar problemas em algumas implementações. Use um certificado NULL na representação canônica de um Destination (ElGamal,DSA_SHA1) ou RouterIdentity, que será 4 bytes mais curto do que usar um certificado KEY.

Mapeamento

Descrição

Um conjunto de mapeamentos chave/valor ou propriedades

Conteúdos

Um Integer de tamanho de 2 bytes seguido por uma série de pares String=String;.

AVISO: A maioria dos usos de Mapping estão em estruturas assinadas, onde as entradas de Mapping devem ser ordenadas por chave, para que a assinatura seja imutável. Falha ao ordenar por chave resultará em falhas de assinatura!

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

Notas

• A codificação não é ideal - precisamos dos caracteres ‘=’ e ‘;’, ou dos comprimentos das strings, mas não de ambos

• Alguma documentação diz que as strings podem não incluir ‘=’ ou ‘;’ mas esta codificação os suporta

• Strings são definidas como UTF-8, mas na implementação atual, I2CP usa UTF-8 mas I2NP não. Por exemplo, strings UTF-8 em um mapeamento de opções RouterInfo em uma I2NP Database Store Message serão corrompidas.

• A codificação permite chaves duplicadas, porém em qualquer uso onde o mapeamento é assinado, as duplicatas podem causar uma falha de assinatura.

• Mapeamentos contidos em mensagens I2NP (por exemplo, em um RouterAddress ou RouterInfo) devem ser ordenados por chave para que a assinatura seja invariante. Chaves duplicadas não são permitidas.

• Os mapeamentos contidos em um I2CP SessionConfig devem ser ordenados por chave para que a assinatura seja invariante. Chaves duplicadas não são permitidas.

• O método de ordenação é definido como em Java String.compareTo(), usando o valor Unicode dos caracteres.

• Embora seja dependente da aplicação, chaves e valores são geralmente sensíveis a maiúsculas e minúsculas.

• Os limites de comprimento das strings de chave e valor são de 255 bytes (não caracteres) cada, mais o byte de comprimento. O byte de comprimento pode ser 0.

• O limite total de comprimento é 65535 bytes, mais o campo de tamanho de 2 bytes, ou 65537 no total.

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

Especificação de estrutura comum

KeysAndCert

Descrição

Uma chave pública de criptografia, uma chave pública de assinatura e um certificado, usado como RouterIdentity ou Destination.

Conteúdo

Uma PublicKey seguida por uma SigningPublicKey e então um 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

Diretrizes de Geração de Padding

Essas diretrizes foram propostas na Proposta 161 e implementadas na versão 0.9.57 da API. Essas diretrizes são compatíveis com versões anteriores desde a versão 0.6 (2005). Veja a Proposta 161 para informações básicas e detalhes adicionais.

Para qualquer combinação de tipos de chave atualmente usada que não seja ElGamal + DSA-SHA1, o padding estará presente. Além disso, para destinos, o campo de chave pública de 256 bytes não tem sido usado desde a versão 0.6 (2005).

Os implementadores devem gerar os dados aleatórios para chaves públicas de Destination e preenchimento de Identidade de Destination e Router, de forma que sejam compressíveis em vários protocolos I2P, mantendo a segurança e evitando que as representações Base 64 pareçam corrompidas ou inseguras. Isso fornece a maioria dos benefícios de remover os campos de preenchimento sem mudanças disruptivas nos protocolos.

Rigorosamente falando, apenas a chave pública de assinatura de 32 bytes (tanto em Destinations quanto em Router Identities) e a chave pública de criptografia de 32 bytes (apenas em Router Identities) é um número aleatório que fornece toda a entropia necessária para que os hashes SHA-256 dessas estruturas sejam criptograficamente fortes e distribuídos aleatoriamente no DHT do netDb.

No entanto, por excesso de cautela, recomendamos que seja usado um mínimo de 32 bytes de dados aleatórios no campo da chave pública ElG e no padding. Além disso, se os campos fossem todos zeros, os destinos Base 64 conteriam longas sequências de caracteres AAAA, o que pode causar alarme ou confusão aos usuários.

Repita os 32 bytes de dados aleatórios conforme necessário para que a estrutura KeysAndCert completa seja altamente compressível nos protocolos I2P como I2NP Database Store Message, Streaming SYN, handshake SSU2 e Datagrams que podem ser respondidos.

Exemplos:

• Uma Identidade de Router com tipo de criptografia X25519 e tipo de assinatura Ed25519 conterá 10 cópias (320 bytes) dos dados aleatórios, para uma economia de aproximadamente 288 bytes quando comprimida.

• Um Destination com tipo de assinatura Ed25519 conterá 11 cópias (352 bytes) dos dados aleatórios, resultando numa economia de aproximadamente 320 bytes quando comprimido.

As implementações devem, naturalmente, armazenar a estrutura completa de 387+ bytes porque o hash SHA-256 da estrutura abrange todo o conteúdo.

Notas

• Não assuma que estes são sempre 387 bytes! Eles são 387 bytes mais o comprimento do certificado especificado nos bytes 385-386, que pode ser diferente de zero.

• A partir da versão 0.9.12, se o certificado for um Key Certificate, os limites dos campos de chave podem variar. Veja a seção Key Certificate acima para detalhes.

• A Chave Pública Criptográfica está alinhada no início e a Chave Pública de Assinatura está alinhada no final. O preenchimento (se houver) está no meio.

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

RouterIdentity

Descrição

Define a forma de identificar exclusivamente um router específico

Conteúdo

Idêntico ao KeysAndCert.

Consulte KeysAndCert para diretrizes sobre como gerar os dados aleatórios para o campo de preenchimento.

Notas

• O certificado para uma RouterIdentity era sempre NULL até a versão 0.9.12.

• Não assuma que estes são sempre 387 bytes! Eles são 387 bytes mais o comprimento do certificado especificado nos bytes 385-386, que pode ser diferente de zero.

• A partir da versão 0.9.12, se o certificado for um Key Certificate, os limites dos campos de chave podem variar. Consulte a seção Key Certificate acima para detalhes.

• A Chave Pública Criptográfica está alinhada no início e a Chave Pública de Assinatura está alinhada no final. O preenchimento (se houver) fica no meio.

• RouterIdentities com um certificado de chave e uma chave pública ECIES_X25519 são suportadas a partir da versão 0.9.48. Antes disso, todas as RouterIdentities eram ElGamal.

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

Destino

Descrição

Um Destination define um endpoint específico para o qual as mensagens podem ser direcionadas para entrega segura.

Conteúdo

Idêntico ao KeysAndCert , exceto que a chave pública nunca é usada, e pode conter dados aleatórios em vez de uma Chave Pública ElGamal válida.

Consulte KeysAndCert para diretrizes sobre como gerar dados aleatórios para os campos de chave pública e preenchimento.

Notas

• A chave pública do destino foi usada para a antiga encriptação i2cp-to-i2cp que foi desabilitada na versão 0.6 (2005), atualmente não é usada exceto para o IV para encriptação de LeaseSet, que está deprecada. A chave pública no LeaseSet é usada em seu lugar.

• Não assuma que estes são sempre 387 bytes! Eles são 387 bytes mais o comprimento do certificado especificado nos bytes 385-386, que pode ser diferente de zero.

• A partir da versão 0.9.12, se o certificado for um Key Certificate, os limites dos campos de chave podem variar. Consulte a seção Key Certificate acima para detalhes.

• A Chave Pública Criptográfica está alinhada no início e a Chave Pública de Assinatura está alinhada no final. O preenchimento (se houver) fica no meio.

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

Lease

Descrição

Define a autorização para um determinado tunnel receber mensagens direcionadas a um Destination .

Conteúdo

SHA256 Hash da RouterIdentity do router de gateway, depois o TunnelId , e finalmente uma Date de fim.

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

Notas

• Tamanho total: 44 bytes

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

LeaseSet

Descrição

Contém todos os Leases atualmente autorizados para um Destination específico, a PublicKey para a qual as mensagens garlic podem ser criptografadas, e então a SigningPublicKey que pode ser usada para revogar esta versão específica da estrutura. O LeaseSet é uma das duas estruturas armazenadas no banco de dados da rede (a outra sendo RouterInfo ), e é indexado sob o SHA256 do Destination contido.

Conteúdo

Destination , seguido por uma PublicKey para criptografia, depois uma SigningPublicKey que pode ser usada para revogar esta versão do LeaseSet, depois um Integer de 1 byte especificando quantas estruturas Lease estão no conjunto, seguido pelas estruturas Lease reais e finalmente uma Signature dos bytes anteriores assinada pela SigningPrivateKey do 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

Notas

• A chave pública do destino foi usada para a criptografia I2CP-to-I2CP antiga que foi desabilitada na versão 0.6, atualmente não está sendo usada.

• A chave de criptografia é usada para criptografia ponta-a-ponta ElGamal/AES+SessionTag ELGAMAL-AES . Atualmente é gerada novamente a cada inicialização do router, não é persistente.

• A assinatura pode ser verificada usando a chave pública de assinatura do destino.

• Um LeaseSet com zero Leases é permitido mas não é utilizado. Foi destinado para revogação de LeaseSet, que não está implementada. Todas as variantes de LeaseSet2 requerem pelo menos um Lease.

• A signing_key atualmente não é utilizada. Foi pensada para revogação de LeaseSet, que não está implementada. Atualmente é gerada novamente a cada inicialização do router, não é persistente. O tipo de chave de assinatura é sempre o mesmo que o tipo de chave de assinatura do destino.

• A expiração mais antiga de todos os Leases é tratada como o timestamp ou versão do LeaseSet. Os routers geralmente não aceitarão o armazenamento de um LeaseSet a menos que seja “mais novo” que o atual. Tenha cuidado ao publicar um novo LeaseSet onde o Lease mais antigo é o mesmo que o Lease mais antigo no LeaseSet anterior. O router de publicação deve geralmente incrementar a expiração do Lease mais antigo em pelo menos 1 ms nesse caso.

• Antes da versão 0.9.7, quando incluído em uma DatabaseStore Message enviada pelo router originário, o router definia todas as expirações dos leases publicados para o mesmo valor, aquele do lease mais antigo. A partir da versão 0.9.7, o router publica a expiração real do lease para cada lease. Este é um detalhe de implementação e não faz parte da especificação das estruturas.

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

Lease2

Descrição

Define a autorização para um túnel específico receber mensagens direcionadas a um Destination . Igual ao Lease mas com um end_date de 4 bytes. Usado pelo LeaseSet2 . Suportado a partir da versão 0.9.38; consulte a proposta 123 para mais informações.

Conteúdo

SHA256 Hash da RouterIdentity do router gateway, então o TunnelId , e finalmente uma data de término de 4 bytes.

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

Notas

• Tamanho total: 40 bytes

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

OfflineSignature

Descrição

Esta é uma parte opcional do LeaseSet2Header . Também usado no streaming e I2CP. Suportado a partir da versão 0.9.38; veja a proposta 123 para mais informações.

Conteúdo

Contém uma expiração, um sigtype e uma SigningPublicKey transitória, e uma 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.

Notas

• Esta seção pode, e deve, ser gerada offline.

LeaseSet2Header

Descrição

Esta é a parte comum do LeaseSet2 e MetaLeaseSet . Suportado a partir da versão 0.9.38; consulte a proposta 123 para mais informações.

Conteúdo

Contém o Destination , dois timestamps, e uma OfflineSignature opcional.

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

Notas

• Tamanho total: 395 bytes mínimo

• O tempo máximo real de expiração é cerca de 660 (11 minutos) para LeaseSet2 e 65535 (as 18,2 horas completas) para MetaLeaseSet .

• LeaseSet (1) não tinha um campo ‘published’, então o versionamento exigia uma busca pelo lease mais antigo. LeaseSet2 adiciona um campo ‘published’ com uma resolução de um segundo. Routers devem limitar a taxa de envio de novos leasesets para floodfills para uma taxa muito mais lenta que uma vez por segundo (por destino). Se isso não for implementado, então o código deve garantir que cada novo leaseset tenha um tempo ‘published’ pelo menos um segundo posterior ao anterior, ou senão floodfills não irão armazenar ou propagar o novo leaseset.

LeaseSet2

Descrição

Contido numa mensagem I2NP DatabaseStore do tipo 3. Suportado a partir da versão 0.9.38; veja a proposta 123 para mais informações.

Contém todas as Lease2 atualmente autorizadas para um Destination específico, e a PublicKey para a qual as mensagens garlic podem ser criptografadas. Um LeaseSet é uma das duas estruturas armazenadas na base de dados da rede (a outra sendo RouterInfo ), e é indexado sob o SHA256 do Destination contido.

Conteúdo

LeaseSet2Header , seguido por opções, depois uma ou mais PublicKey para criptografia, Integer especificando quantas estruturas Lease2 estão no conjunto, seguido pelas estruturas Lease2 reais e finalmente uma Signature dos bytes anteriores assinados pela SigningPrivateKey do Destination ou pela chave transitória.

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

Preferência de Chave de Criptografia

Para leaseSets publicados (servidor), as chaves de criptografia estão em ordem de preferência do servidor, com a mais preferida primeiro. Se os clientes suportam mais de um tipo de criptografia, é recomendado que honrem a preferência do servidor e selecionem o primeiro tipo suportado como método de criptografia a usar para conectar ao servidor. Geralmente, os tipos de chave mais novos (numerados mais alto) são mais seguros ou eficientes e são preferidos, então as chaves devem ser listadas em ordem reversa do tipo de chave.

No entanto, os clientes podem, dependendo da implementação, selecionar com base na sua preferência, ou usar algum método para determinar a preferência “combinada”. Isso pode ser útil como uma opção de configuração, ou para depuração.

A ordem das chaves em leaseSets não publicados (cliente) efetivamente não importa, porque as conexões geralmente não serão tentadas para clientes não publicados. A menos que esta ordem seja usada para determinar uma preferência combinada, conforme descrito acima.

Opções

A partir da API 0.9.66, um formato padrão para opções de registro de serviço é definido. Consulte a proposta 167 para detalhes. Opções diferentes dos registros de serviço, usando um formato diferente, podem ser definidas no futuro.

As opções LS2 DEVEM ser ordenadas por chave, para que a assinatura seja invariante.

As opções de registro de serviço são definidas da seguinte forma:

• serviceoption := optionkey optionvalue
• optionkey := _service._proto
• service := O nome simbólico do serviço desejado. Deve estar em minúsculas. Exemplo: “smtp”. Caracteres permitidos são [a-z0-9-] e não deve começar ou terminar com ‘-’. Identificadores padrão de REGISTRY ou Linux /etc/services devem ser usados se definidos lá.
• proto := O protocolo de transporte do serviço desejado. Deve estar em minúsculas, “tcp” ou “udp”. “tcp” significa streaming e “udp” significa datagramas com resposta. Indicadores de protocolo para datagramas brutos e datagram2 podem ser definidos posteriormente. Caracteres permitidos são [a-z0-9-] e não deve começar ou terminar com ‘-’.
• optionvalue := self | srvrecord[,srvrecord]*
• self := “0” ttl port [appoptions]
• srvrecord := “1” ttl priority weight port target [appoptions]
• ttl := tempo de vida, segundos inteiros. Inteiro positivo. Exemplo: “86400”. Um mínimo de 86400 (um dia) é recomendado, veja a seção Recomendações abaixo para detalhes.
• priority := A prioridade do host de destino, valor menor significa mais preferido. Inteiro não negativo. Exemplo: “0” Útil apenas se mais de um registro, mas obrigatório mesmo se apenas um registro.
• weight := Um peso relativo para registros com a mesma prioridade. Valor maior significa mais chance de ser escolhido. Inteiro não negativo. Exemplo: “0” Útil apenas se mais de um registro, mas obrigatório mesmo se apenas um registro.
• port := A porta I2CP na qual o serviço deve ser encontrado. Inteiro não negativo. Exemplo: “25” Porta 0 é suportada mas não recomendada.
• target := O hostname ou b32 do destino que fornece o serviço. Um hostname válido como em NAMING . Deve estar em minúsculas. Exemplo: “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p” ou “example.i2p”. b32 é recomendado a menos que o hostname seja “bem conhecido”, ou seja, em livros de endereços oficiais ou padrão.
• appoptions := texto arbitrário específico da aplicação, não deve conter " " ou “,”. Codificação é UTF-8.

Exemplos:

No LS2 para aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p, apontando para um servidor SMTP:

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

Em LS2 para aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p, apontando para dois servidores SMTP:

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

No LS2 para bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p, apontando para si mesmo como servidor SMTP:

“_smtp._tcp” “0 999999 25”

Notas

• A chave pública do destino era usada para a antiga criptografia I2CP-para-I2CP que foi desabilitada na versão 0.6, atualmente não é utilizada.

• As chaves de criptografia são usadas para criptografia fim-a-fim ElGamal/AES+SessionTag ELGAMAL-AES (tipo 0) ou outros esquemas de criptografia fim-a-fim. Veja ECIES e propostas 145 e 156. Elas podem ser geradas novamente a cada inicialização do router ou podem ser persistentes. X25519 (tipo 4, veja ECIES ) é suportado a partir da versão 0.9.44.

• A assinatura é sobre os dados acima, PREFIXADOS com o byte único contendo o tipo DatabaseStore (3).

• A assinatura pode ser verificada usando a chave pública de assinatura do destino, ou a chave pública de assinatura transitória, se uma assinatura offline estiver incluída no cabeçalho do leaseset2.

• O comprimento da chave é fornecido para cada chave, para que floodfills e clientes possam analisar a estrutura mesmo se nem todos os tipos de criptografia forem conhecidos ou suportados.

• Veja a nota sobre o campo ‘published’ em LeaseSet2Header

• O mapeamento de opções, se o tamanho for maior que um, deve ser ordenado por chave, para que a assinatura seja invariante.

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

MetaLease

Descrição

Define a autorização para um tunnel específico receber mensagens direcionadas a um Destination . Igual ao Lease2 mas com flags e custo em vez de um ID de tunnel. Usado pelo MetaLeaseSet . Contido em uma mensagem I2NP DatabaseStore do tipo 7. Suportado a partir da versão 0.9.38; veja a proposta 123 para mais informações.

Conteúdo

Hash SHA256 da RouterIdentity do router gateway, seguido por flags e custo, e finalmente uma data de término de 4 bytes.

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

Notas

• Tamanho total: 40 bytes

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

MetaLeaseSet

Descrição

Contido em uma mensagem I2NP DatabaseStore do tipo 7. Definido a partir da versão 0.9.38; programado para estar funcionando a partir da 0.9.40; veja a proposta 123 para mais informações.

Contém todos os MetaLease atualmente autorizados para um determinado Destination , e a PublicKey para a qual mensagens garlic podem ser criptografadas. Um LeaseSet é uma das duas estruturas armazenadas na base de dados da rede (a outra sendo RouterInfo ), e é indexado sob o SHA256 do Destination contido.

Conteúdo

LeaseSet2Header , seguido por opções, Integer especificando quantas estruturas Lease2 estão no conjunto, seguido pelas estruturas Lease2 reais e finalmente uma Signature dos bytes anteriores assinados pela SigningPrivateKey do Destination ou pela chave transitória.

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

Notas

• A chave pública do destino foi usada para a antiga criptografia I2CP-para-I2CP que foi desabilitada na versão 0.6, atualmente não é utilizada.

• A assinatura é sobre os dados acima, PRECEDIDOS pelo byte único contendo o tipo DatabaseStore (7).

• A assinatura pode ser verificada usando a chave pública de assinatura do destino, ou a chave pública de assinatura transitória, se uma assinatura offline estiver incluída no cabeçalho do leaseset2.

• Veja a nota sobre o campo ‘published’ em LeaseSet2Header

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

EncryptedLeaseSet

Descrição

Contido em uma mensagem I2NP DatabaseStore do tipo 5. Definido a partir da versão 0.9.38; funcionando a partir da versão 0.9.39; consulte a proposta 123 para mais informações.

Apenas a chave cega e a expiração são visíveis em texto claro. O leaseSet real está criptografado.

Conteúdo

Um tipo de assinatura de dois bytes, a SigningPrivateKey ofuscada, tempo de publicação, expiração e flags. Em seguida, um comprimento de dois bytes seguido por dados criptografados. Finalmente, uma Signature dos bytes anteriores assinados pela SigningPrivateKey ofuscada ou pela chave transitória.

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

Notas

• A chave pública do destino foi usada para a antiga criptografia I2CP-para-I2CP que foi desabilitada na versão 0.6, atualmente não é utilizada.

• A assinatura é sobre os dados acima, PRECEDIDOS pelo byte único contendo o tipo DatabaseStore (5).

• A assinatura pode ser verificada usando a chave pública de assinatura do destino, ou a chave pública de assinatura transitória, se uma assinatura offline estiver incluída no cabeçalho do leaseset2.

• Blinding e criptografia são especificados em EncryptedLeaseSet

• Esta estrutura não usa o LeaseSet2Header .

• O tempo máximo real de expiração é cerca de 660 (11 minutos), a menos que seja um MetaLeaseSet criptografado.

• Veja a proposta 123 para notas sobre o uso de assinaturas offline com leaseSets criptografados.

• Veja a nota no campo ‘published’ em LeaseSet2Header (mesmo problema, mesmo que não usemos o formato LeaseSet2Header aqui)

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

RouterAddress

Descrição

Esta estrutura define os meios para contactar um router através de um protocolo de transporte.

Conteúdo

1 byte Integer definindo o custo relativo de usar o endereço, onde 0 é gratuito e 255 é caro, seguido pela Date de expiração após a qual o endereço não deve ser usado, ou se nulo, o endereço nunca expira. Depois disso vem uma String definindo o protocolo de transporte que este endereço de router usa. Finalmente há um Mapping contendo todas as opções específicas de transporte necessárias para estabelecer a conexão, como endereço IP, número da porta, endereço de email, 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`

Notas

• O custo é tipicamente 5 ou 6 para SSU, e 10 ou 11 para NTCP.

• A expiração está atualmente não utilizada, sempre nula (todos zeros). A partir da versão 0.9.3, a expiração é assumida como zero e não é armazenada, então qualquer expiração não-zero falhará na verificação de assinatura do RouterInfo. Implementar a expiração (ou outro uso para estes bytes) será uma mudança incompatível com versões anteriores. Os routers DEVEM definir este campo como todos zeros. A partir da versão 0.9.12, um campo de expiração não-zero é novamente reconhecido, no entanto devemos aguardar várias versões para usar este campo, até que a grande maioria da rede o reconheça.

• As seguintes opções, embora não sejam obrigatórias, são padrão e espera-se que estejam presentes na maioria dos endereços de router: “host” (um endereço IPv4 ou IPv6 ou nome de host) e “port”.

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

RouterInfo

Descrição

Define todos os dados que um router quer publicar para que a rede possa ver. O RouterInfo é uma das duas estruturas armazenadas na base de dados da rede (a outra sendo LeaseSet ), e é indexada sob o SHA256 da RouterIdentity contida.

Conteúdo

RouterIdentity seguido pela Date , quando a entrada foi publicada

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

Notas

• O peer_size Integer pode ser seguido por uma lista com essa quantidade de hashes de router. Isto está atualmente não utilizado. Foi destinado para uma forma de rotas restritas, que não está implementada. Certas implementações podem exigir que a lista seja ordenada para que a assinatura seja invariante. Para ser pesquisado antes de habilitar esta funcionalidade.

• A assinatura pode ser verificada usando a chave pública de assinatura do router_ident.

• Veja a página da base de dados da rede NETDB-ROUTERINFO para as opções padrão que devem estar presentes em todas as informações do router.

• Roteadores muito antigos exigiam que os endereços fossem ordenados pelo SHA256 de seus dados para que a assinatura fosse invariante. Isso não é mais necessário e não vale a pena implementar para compatibilidade com versões anteriores.

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

Instruções de Entrega

As Instruções de Entrega de Mensagem de Tunnel são definidas na Especificação de Mensagem de Tunnel TUNNEL-DELIVERY .

As Instruções de Entrega de Mensagem Garlic são definidas na Especificação de Mensagem I2NP GARLIC-DELIVERY .

Referências

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