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 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 no ElGamal ou outras criptografias assimétricas, representando apenas o expoente, não os números 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 especificados no Certificado de Chave de um Destination ou RouterInfo, ou nos campos de 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 outra descriptografia assimétrica, representando apenas o expoente, não os números 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 o comprimento da chave são inferidos do contexto ou armazenados separadamente em uma estrutura de dados ou arquivo 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/net/i2p/data/SessionKey.html

SigningPublicKey

Descrição

Esta estrutura é usada para verificar assinaturas.

Conteúdo

O tipo e comprimento da chave são inferidos do contexto ou são especificados no Certificado de Chave 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 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/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 para 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/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 a partir 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 com length/2 com zeros à esquerda se necessário.

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

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

Hash

Descrição

Representa o SHA256 de alguns dados.

Conteúdo

32 bytes

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

Session Tag

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

Descrição

Um número aleatório

Conteúdo

32 bytes

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

TunnelId

Descrição

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

Conteúdo

4 byte Integer

JavaDoc: http://docs.i2p-projekt.de/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 do payload do certificado, então essa quantidade de bytes.

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

type :: Integer
        length -> 1 byte

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 Certificate é sempre NULL, nenhum outro está atualmente implementado.

• Para Garlic Messages , o Certificate é 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 alertados para proibir dados em excesso nos Certificados. O comprimento apropriado para cada tipo de certificado deve ser aplicado.

Tipos de Certificado

Os seguintes tipos de certificado estã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 qualquer dado de chave excedente dentro do certificado, mantemos a 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:

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

• Preenchimento aleatório se o comprimento total das duas chaves for menor que 384 bytes

• Chave Pública de Assinatura completa ou primeira parte

A Chave Pública Criptográfica é 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 partes de dados de chave excedentes nos certificados não são especificados explicitamente, mas são derivados dos comprimentos dos tipos de chave especificados. Se os comprimentos totais das Chaves Públicas Criptográfica e de Assinatura excederem 384 bytes, o restante será contido no Certificado de Chave. Se o comprimento da Chave Pública Criptográfica não for 256 bytes, o método para determinar o limite entre as duas chaves será especificado em uma revisão futura deste documento.

Layouts de exemplo usando uma Chave Pública Cripto ElGamal e o tipo de Chave Pública de Assinatura indicado:

Notas

• Os implementadores são alertados para proibir dados excessivos em Certificados de Chave. 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 que usar um certificado KEY.

Mapeamento

Descrição

Um conjunto de mapeamentos chave/valor ou propriedades

Conteúdo

Um Integer 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 do 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

• Algumas documentações dizem que as strings podem não incluir ‘=’ ou ‘;’ mas esta codificação suporta eles

• 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, no entanto, em qualquer uso onde o mapeamento é assinado, 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 invariável. Chaves duplicadas não são permitidas.

• Os mapeamentos contidos em um I2CP SessionConfig devem ser ordenados por chave para que a assinatura seja invariável. 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 dependa 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 de comprimento total é 65535 bytes, mais o campo de tamanho de 2 bytes, ou 65537 no total.

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

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

Para qualquer combinação atualmente usada de tipos de chave que não seja ElGamal + DSA-SHA1, padding estará presente. Além disso, para destinos, o campo de chave pública de 256 bytes não é 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 Identity de Destination e Router, de modo que sejam compressíveis em vários protocolos I2P enquanto permanecem seguros, e sem 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 qualquer mudança disruptiva de protocolo.

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 banco de dados da rede.

No entanto, por excesso de precaução, recomendamos que um mínimo de 32 bytes de dados aleatórios seja usado no campo de chave pública ElG e no preenchimento. 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 comprimível em protocolos I2P como I2NP Database Store Message, Streaming SYN, handshake SSU2 e Datagrams com resposta.

Exemplos:

• Uma Router Identity 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, para uma economia de aproximadamente 320 bytes quando comprimido.

As implementações devem, é claro, armazenar a estrutura completa de 387+ bytes porque o hash SHA-256 da estrutura cobre 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) fica no meio.

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

RouterIdentity

Descrição

Define a forma de identificar exclusivamente um router específico

Conteúdo

Idêntico ao KeysAndCert.

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

Notas

• O certificado para um RouterIdentity sempre foi 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. 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) 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/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údos

Idêntico a 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.

Veja KeysAndCert para diretrizes sobre a geração de 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á obsoleta. A chave pública no LeaseSet é usada em seu lugar.

• Não assuma que estes são sempre 387 bytes! 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/net/i2p/data/Destination.html

Lease

Descrição

Define a autorização para um tunnel específico receber mensagens direcionadas a um Destination .

Conteúdo

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

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

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 netDb (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, então 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

• 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 chave de criptografia é usada para criptografia ElGamal/AES+SessionTag de ponta a ponta 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 é usado. Era destinado para revogação de LeaseSet, que não está implementado. Todas as variantes de LeaseSet2 exigem pelo menos um Lease.

• A signing_key atualmente não é utilizada. Foi destinada 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 aceitam 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 geralmente deve 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 Mensagem DatabaseStore enviada pelo router originário, o router definia todas as expirações dos leases publicados para o mesmo valor, ou seja, o 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/net/i2p/data/LeaseSet.html

Lease2

Descrição

Define a autorização para um tunnel específico receber mensagens direcionadas a um Destination . O mesmo que Lease , mas com um end_date de 4 bytes. Usado por 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, depois 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.

• Tamanho total: 40 bytes

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

OfflineSignature

Descrição

Esta é uma parte opcional do LeaseSet2Header . Também usado em 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 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.

• 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.
  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 bytes):

  • Bit 0: Se definido, chaves offline estão presentes (veja OfflineSignature )
  • Bit 1: Se definido, este é um leaseset não publicado
  • Bit 2: Se definido, este é um leaseset cegado
  • Bits 15-3: Reservados, definir como 0

• 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 resolução de um segundo. Os 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, caso contrário os floodfills não armazenarão ou propagarão o novo leaseset.

LeaseSet2

Descrição

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

Contém todos os Lease2 atualmente autorizados para um Destination específico, e a PublicKey para a qual as mensagens garlic podem ser criptografadas. Um 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

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

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 eles 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 em sua preferência em vez disso, 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 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, é definido um formato padrão para opções de registro de serviço. 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 do REGISTRY ou do Linux /etc/services devem ser usados se definidos lá.
• proto := O protocolo de transporte do serviço desejado. Deve estar em minúsculas, seja “tcp” ou “udp”. “tcp” significa streaming e “udp” significa datagramas respondíveis. 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” Apenas útil 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” Apenas útil 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 para a aplicação, não deve conter " " ou “,”. A 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”

No 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 um 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 ponta a ponta ElGamal/AES+SessionTag ELGAMAL-AES (tipo 0) ou outros esquemas de criptografia ponta a ponta. 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 que nem todos os tipos de criptografia sejam 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/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

SHA256 Hash da RouterIdentity do router gateway, depois 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/net/i2p/data/MetaLease.html

MetaLeaseSet

Descrição

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

Contém todos os MetaLease atualmente autorizados para um Destination específico, e a PublicKey para a qual as mensagens garlic podem ser criptografadas. Um 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

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 está sendo 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/net/i2p/data/MetaLeaseSet.html

EncryptedLeaseSet

Descrição

Contido numa mensagem I2NP DatabaseStore do tipo 5. Definido a partir da versão 0.9.38; funcional 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 cegada, 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 assinada pela SigningPrivateKey cegada 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 único byte 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.

• O mascaramento e criptografia são especificados em EncryptedLeaseSet

• Esta estrutura não utiliza 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 sobre o campo ‘published’ em LeaseSet2Header (mesmo problema, embora não usemos o formato LeaseSet2Header aqui)

JavaDoc: http://docs.i2p-projekt.de/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 do 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 sem uso, 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 da assinatura do RouterInfo. Implementar 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/net/i2p/data/router/RouterAddress.html

RouterInfo

Descrição

Define todos os dados que um router deseja 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 é indexado 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. Isso atualmente não é usado. Foi destinado a 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. Deve ser pesquisado antes de habilitar essa funcionalidade.

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

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

• Routers muito antigos exigiam que os endereços fossem ordenados pelo SHA256 dos seus dados para que a assinatura fosse invariável. 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/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