Protocolos Criptográficos Pós-Quânticos

Status

Visão Geral

Embora a pesquisa e a competição por criptografia pós-quântica (PQ) adequada tenham prosseguido por uma década, as escolhas não se tornaram claras até recentemente.

Começamos a analisar as implicações da criptografia PQ em 2022 zzz.i2p .

Os padrões TLS adicionaram suporte para criptografia híbrida nos últimos dois anos e agora é usada para uma parcela significativa do tráfego criptografado na internet devido ao suporte no Chrome e Firefox Cloudflare .

O NIST finalizou e publicou recentemente os algoritmos recomendados para criptografia pós-quântica NIST . Várias bibliotecas de criptografia comuns agora suportam os padrões NIST ou lançarão suporte em um futuro próximo.

Tanto a Cloudflare quanto o NIST recomendam que a migração comece imediatamente. Veja também o FAQ PQ de 2022 da NSA NSA . O I2P deve ser líder em segurança e criptografia. Agora é hora de implementar os algoritmos recomendados. Usando nosso sistema flexível de tipos de criptografia e tipos de assinatura, adicionaremos tipos para criptografia híbrida, e para assinaturas PQ e híbridas.

Objetivos

• Selecionar algoritmos resistentes a PQ
• Adicionar algoritmos somente PQ e híbridos aos protocolos I2P onde apropriado
• Definir múltiplas variantes
• Selecionar as melhores variantes após implementação, testes, análise e pesquisa
• Adicionar suporte incrementalmente e com compatibilidade regressiva

Não-Objetivos

• Não altere os protocolos de criptografia unidirecional (Noise N)
• Não abandone o SHA256, não está ameaçado a curto prazo pela computação quântica
• Não selecione as variantes preferidas finais neste momento

Modelo de Ameaças

• Routers no OBEP ou IBGW, possivelmente em conluio, armazenando mensagens garlic para descriptografia posterior (forward secrecy)
• Observadores da rede armazenando mensagens de transporte para descriptografia posterior (forward secrecy)
• Participantes da rede falsificando assinaturas para RI, LS, streaming, datagramas, ou outras estruturas

Protocolos Afetados

Modificaremos os seguintes protocolos, aproximadamente em ordem de desenvolvimento. O lançamento geral provavelmente será do final de 2025 até meados de 2027. Consulte a seção Prioridades e Lançamento abaixo para detalhes.

Design

Iremos suportar os padrões NIST FIPS 203 e 204 FIPS 203 FIPS 204 que são baseados em, mas NÃO compatíveis com, CRYSTALS-Kyber e CRYSTALS-Dilithium (versões 3.1, 3 e anteriores).

Troca de Chaves

Iremos suportar troca de chaves híbrida nos seguintes protocolos:

O Noise N não usa uma troca de chaves bidirecional e, portanto, não é adequado para criptografia híbrida.

Portanto, ofereceremos suporte apenas à criptografia híbrida, para NTCP2, SSU2 e Ratchet. Definiremos as três variantes ML-KEM como em FIPS 203 , totalizando 3 novos tipos de criptografia. Os tipos híbridos serão definidos apenas em combinação com X25519.

Os novos tipos de criptografia são:

Assinaturas

Suportaremos assinaturas PQ e híbridas nas seguintes estruturas:

Então iremos suportar tanto assinaturas apenas PQ quanto híbridas. Definiremos as três variantes ML-DSA como em FIPS 204 , três variantes híbridas com Ed25519, e três variantes apenas PQ com prehash somente para arquivos SU3, totalizando 9 novos tipos de assinatura. Tipos híbridos serão definidos apenas em combinação com Ed25519. Usaremos o ML-DSA padrão, NÃO as variantes pre-hash (HashML-DSA), exceto para arquivos SU3.

Os novos tipos de assinatura são:

Certificados X.509 e outras codificações DER utilizarão as estruturas compostas e OIDs definidos no rascunho do IETF .

Como os novos tipos de identidade de destino e router não conterão preenchimento, eles não serão compressíveis. Os tamanhos de destinos e identidades de router que são compactados com gzip em trânsito aumentarão de 12x a 38x dependendo do algoritmo.

Para Destinations, os novos tipos de assinatura são suportados com todos os tipos de criptografia no leaseSet. Defina o tipo de criptografia no certificado de chave como NONE (255).

Combinações Legais

Para RouterIdentities, o tipo de criptografia ElGamal está depreciado. Os novos tipos de assinatura são suportados apenas com criptografia X25519 (tipo 4). Os novos tipos de criptografia serão indicados nos RouterAddresses. O tipo de criptografia no certificado de chave continuará sendo tipo 4.

Os vetores de teste para SHA3-256, SHAKE128 e SHAKE256 estão disponíveis no NIST .

Nova Criptografia Necessária

• ML-KEM (anteriormente CRYSTALS-Kyber) FIPS 203
• ML-DSA (anteriormente CRYSTALS-Dilithium) FIPS 204
• SHA3-128 (anteriormente Keccak-256) FIPS 202 Usado apenas para SHAKE128
• SHA3-256 (anteriormente Keccak-512) FIPS 202
• SHAKE128 e SHAKE256 (extensões XOF para SHA3-128 e SHA3-256) FIPS 202

Note que a biblioteca Java bouncycastle suporta todos os itens acima. O suporte da biblioteca C++ está no OpenSSL 3.5 OpenSSL .

Não ofereceremos suporte ao FIPS 205 (Sphincs+), é muito muito mais lento e maior que o ML-DSA. Não ofereceremos suporte ao próximo FIPS206 (Falcon), ainda não foi padronizado. Não ofereceremos suporte ao NTRU ou outros candidatos PQ que não foram padronizados pelo NIST.

Alternativas

Existe alguma pesquisa paper sobre adaptar o Wireguard (IK) para criptografia PQ pura, mas há várias questões em aberto nesse paper. Posteriormente, essa abordagem foi implementada como Rosenpass Rosenpass whitepaper para Wireguard PQ.

Rosenpass

O Rosenpass usa um handshake similar ao Noise KK com chaves estáticas pré-compartilhadas Classic McEliece 460896 (500 KB cada) e chaves efêmeras Kyber-512 (essencialmente MLKEM-512). Como os textos cifrados Classic McEliece têm apenas 188 bytes, e as chaves públicas e textos cifrados Kyber-512 são razoáveis, ambas as mensagens de handshake cabem em um MTU UDP padrão. A chave compartilhada de saída (osk) do handshake PQ KK é usada como a chave pré-compartilhada de entrada (psk) para o handshake IK padrão do Wireguard. Então há dois handshakes completos no total, um PQ puro e um X25519 puro.

Não podemos fazer nada disso para substituir nossos handshakes XK e IK porque:

Há muitas informações valiosas no whitepaper, e iremos revisá-lo em busca de ideias e inspiração. TODO.

• Não podemos fazer KK, Bob não tem a chave estática da Alice
• Chaves estáticas de 500KB são grandes demais
• Não queremos uma viagem de ida e volta extra

Atualize as seções e tabelas no documento de estruturas comuns /docs/specs/common-structures/ da seguinte forma:

Especificação

Estruturas Comuns

Os novos tipos de Chave Pública são:

PublicKey

Chaves públicas híbridas são a chave X25519. Chaves públicas KEM são a chave PQ efêmera enviada de Alice para Bob. A codificação e ordem de bytes são definidas em FIPS 203 .

Os novos tipos de Chave Privada são:

PrivateKey

As chaves privadas híbridas são as chaves X25519. As chaves privadas KEM são apenas para Alice. A codificação KEM e a ordem dos bytes são definidas em FIPS 203 .

SigningPublicKey

Chaves públicas de assinatura híbridas são a chave Ed25519 seguida pela chave PQ, como no rascunho IETF . A codificação e ordem de bytes são definidas no FIPS 204 .

SigningPrivateKey

As chaves privadas de assinatura híbridas são a chave Ed25519 seguida pela chave PQ, conforme descrito no rascunho IETF . A codificação e ordem de bytes são definidas no FIPS 204 .

Assinatura

As assinaturas híbridas são a assinatura Ed25519 seguida pela assinatura PQ, como no rascunho IETF . As assinaturas híbridas são verificadas verificando ambas as assinaturas, e falhando se qualquer uma falhar. A codificação e ordem de bytes são definidas no FIPS 204 .

Certificados de Chave

Chaves públicas de assinatura híbridas são a chave Ed25519 seguida pela chave PQ, como no rascunho IETF . A codificação e ordem de bytes são definidas no FIPS 204 .

Para destinos com tipos de assinatura Hybrid ou PQ, use NONE (tipo 255) para o tipo de criptografia, mas não há chave criptográfica, e toda a seção principal de 384 bytes é para a chave de assinatura.

Tamanhos de destino

Aqui estão os comprimentos para os novos tipos de Destination. O tipo Enc para todos é NONE (tipo 255) e o comprimento da chave de criptografia é tratado como 0. Toda a seção de 384 bytes é usada para a primeira parte da chave pública de assinatura. NOTA: Isso é diferente da especificação para os tipos de assinatura ECDSA_SHA512_P521 e RSA, onde mantivemos a chave ElGamal de 256 bytes no destination mesmo que não fosse usada.

Sem preenchimento. O comprimento total é 7 + comprimento total da chave. O comprimento do certificado da chave é 4 + comprimento excessivo da chave.

Exemplo de fluxo de bytes de destino de 1319 bytes para MLDSA44:

skey[0:383] 5 (932 » 8) (932 & 0xff) 00 12 00 255 skey[384:1311]

Tamanhos de RouterIdent

Aqui estão os comprimentos para os novos tipos de Destination. O tipo de criptografia para todos é X25519 (tipo 4). Toda a seção de 352 bytes após a chave pública X25519 é usada para a primeira parte da chave pública de assinatura. Sem preenchimento. O comprimento total é 39 + comprimento total da chave. O comprimento do certificado da chave é 4 + comprimento excedente da chave.

Exemplo de fluxo de bytes de identidade do router de 1351 bytes para MLDSA44:

enckey[0:31] skey[0:351] 5 (960 » 8) (960 & 0xff) 00 12 00 4 skey[352:1311]

Padrões de Handshake

Os handshakes usam padrões de handshake do Noise Protocol .

O seguinte mapeamento de letras é usado:

• e = chave efêmera de uso único
• s = chave estática
• p = carga útil da mensagem
• e1 = chave PQ efêmera de uso único, enviada de Alice para Bob
• ekem1 = o texto cifrado KEM, enviado de Bob para Alice

As seguintes modificações ao XK e IK para sigilo futuro híbrido (hfs) são especificadas conforme a especificação Noise HFS seção 5:

XK:                       XKhfs:
  <- s                      <- s
  ...                       ...
  -> e, es, p               -> e, es, e1, p
  <- e, ee, p               <- e, ee, ekem1, p
  -> s, se                  -> s, se
  <- p                      <- p
  p ->                      p ->


  IK:                       IKhfs:
  <- s                      <- s
  ...                       ...
  -> e, es, s, ss, p       -> e, es, e1, s, ss, p
  <- tag, e, ee, se, p     <- tag, e, ee, ekem1, se, p
  <- p                     <- p
  p ->                     p ->

  e1 and ekem1 are encrypted. See pattern definitions below.
  NOTE: e1 and ekem1 are different sizes (unlike X25519)

O padrão e1 é definido como segue, conforme especificado na seção 4 da especificação Noise HFS :

For Alice:
  (encap_key, decap_key) = PQ_KEYGEN()

  // EncryptAndHash(encap_key)
  ciphertext = ENCRYPT(k, n, encap_key, ad)
  n++
  MixHash(ciphertext)

  For Bob:

  // DecryptAndHash(ciphertext)
  encap_key = DECRYPT(k, n, ciphertext, ad)
  n++
  MixHash(ciphertext)

O padrão ekem1 é definido como segue, conforme especificado na especificação Noise HFS seção 4:

For Bob:

  (kem_ciphertext, kem_shared_key) = ENCAPS(encap_key)

  // EncryptAndHash(kem_ciphertext)
  ciphertext = ENCRYPT(k, n, kem_ciphertext, ad)
  MixHash(ciphertext)

  // MixKey
  MixKey(kem_shared_key)


  For Alice:

  // DecryptAndHash(ciphertext)
  kem_ciphertext = DECRYPT(k, n, ciphertext, ad)
  MixHash(ciphertext)

  // MixKey
  kem_shared_key = DECAPS(kem_ciphertext, decap_key)
  MixKey(kem_shared_key)

KDF do Handshake Noise

Problemas

• Devemos parar de enviar dados ratchet 0-RTT (além do LS)?
• Devemos mudar o ratchet de IK para XK se não enviarmos dados 0-RTT?

Visão Geral

Esta seção se aplica tanto aos protocolos IK quanto XK.

O handshake híbrido é definido na especificação Noise HFS . A primeira mensagem, de Alice para Bob, contém e1, a chave de encapsulamento, antes da carga útil da mensagem. Isso é tratado como uma chave estática adicional; chame EncryptAndHash() nela (como Alice) ou DecryptAndHash() (como Bob). Em seguida, processe a carga útil da mensagem como de costume.

A segunda mensagem, de Bob para Alice, contém ekem1, o texto cifrado, antes da carga útil da mensagem. Isso é tratado como uma chave estática adicional; chame EncryptAndHash() nela (como Bob) ou DecryptAndHash() (como Alice). Em seguida, calcule a kem_shared_key e chame MixKey(kem_shared_key). Então processe a carga útil da mensagem normalmente.

Operações ML-KEM Definidas

Definimos as seguintes funções correspondentes aos blocos fundamentais criptográficos utilizados conforme definido em FIPS 203 .

(encap_key, decap_key) = PQ_KEYGEN()

Alice creates the encapsulation and decapsulation keys
The encapsulation key is sent in message 1.
encap_key and decap_key sizes vary based on ML-KEM variant.

(ciphertext, kem_shared_key) = ENCAPS(encap_key)

Bob calculates the ciphertext and shared key,
using the ciphertext received in message 1.
The ciphertext is sent in message 2.
ciphertext size varies based on ML-KEM variant.
The kem_shared_key is always 32 bytes.

kem_shared_key = DECAPS(ciphertext, decap_key)

Alice calculates the shared key,
using the ciphertext received in message 2.
The kem_shared_key is always 32 bytes.

Note que tanto a encap_key quanto o ciphertext são criptografados dentro de blocos ChaCha/Poly nas mensagens 1 e 2 do handshake Noise. Eles serão descriptografados como parte do processo de handshake.

A kem_shared_key é misturada na chaining key com MixHash(). Veja abaixo para detalhes.

KDF da Alice para Mensagem 1

Para XK: Após o padrão de mensagem ’es’ e antes da carga útil, adicione:

OU

Para IK: Após o padrão de mensagem ’es’ e antes do padrão de mensagem ’s’, adicione:

This is the "e1" message pattern:
  (encap_key, decap_key) = PQ_KEYGEN()

  // EncryptAndHash(encap_key)
  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  ciphertext = ENCRYPT(k, n, encap_key, ad)
  n++

  // MixHash(ciphertext)
  h = SHA256(h || ciphertext)


  End of "e1" message pattern.

  NOTE: For the next section (payload for XK or static key for IK),
  the keydata and chain key remain the same,
  and n now equals 1 (instead of 0 for non-hybrid).

Bob KDF para Mensagem 1

Para XK: Após o padrão de mensagem ’es’ e antes da carga útil, adicione:

OU

Para IK: Após o padrão de mensagem ’es’ e antes do padrão de mensagem ’s’, adicione:

This is the "e1" message pattern:

  // DecryptAndHash(encap_key_section)
  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  encap_key = DECRYPT(k, n, encap_key_section, ad)
  n++

  // MixHash(encap_key_section)
  h = SHA256(h || encap_key_section)

  End of "e1" message pattern.

  NOTE: For the next section (payload for XK or static key for IK),
  the keydata and chain key remain the same,
  and n now equals 1 (instead of 0 for non-hybrid).

Bob KDF para Mensagem 2

Para XK: Após o padrão de mensagem ’ee’ e antes do payload, adicione:

OU

Para IK: Após o padrão de mensagem ’ee’ e antes do padrão de mensagem ‘se’, adicionar:

This is the "ekem1" message pattern:

  (kem_ciphertext, kem_shared_key) = ENCAPS(encap_key)

  // EncryptAndHash(kem_ciphertext)
  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  ciphertext = ENCRYPT(k, n, kem_ciphertext, ad)

  // MixHash(ciphertext)
  h = SHA256(h || ciphertext)

  // MixKey(kem_shared_key)
  keydata = HKDF(chainKey, kem_shared_key, "", 64)
  chainKey = keydata[0:31]

  End of "ekem1" message pattern.

  // AEAD parameters for payload section
  ... as in standard SSU2 ...
  k = keydata[32:63]
  ...

KDF da Alice para Mensagem 2

Após o padrão de mensagem ’ee’ (e antes do padrão de mensagem ‘ss’ para IK), adicione:

This is the "ekem1" message pattern:

  // DecryptAndHash(kem_ciphertext_section)
  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  kem_ciphertext = DECRYPT(k, n, kem_ciphertext_section, ad)

  // MixHash(kem_ciphertext_section)
  h = SHA256(h || kem_ciphertext_section)

  // MixKey(kem_shared_key)
  kem_shared_key = DECAPS(kem_ciphertext, decap_key)
  keydata = HKDF(chainKey, kem_shared_key, "", 64)
  chainKey = keydata[0:31]

  End of "ekem1" message pattern.

  // AEAD parameters for payload section
  ... as in standard SSU2 ...
  k = keydata[32:63]
  ...

KDF para Mensagem 3 (apenas XK)

inalterado

KDF para split()

inalterado

Ratchet

Atualize a especificação ECIES-Ratchet /docs/specs/ecies/ da seguinte forma:

Identificadores Noise

• “Noise_IKhfselg2_25519+MLKEM512_ChaChaPoly_SHA256”
• “Noise_IKhfselg2_25519+MLKEM768_ChaChaPoly_SHA256”
• “Noise_IKhfselg2_25519+MLKEM1024_ChaChaPoly_SHA256”

1b) Novo formato de sessão (com vinculação)

Alterações: O ratchet atual continha a chave estática na primeira seção ChaCha, e o payload na segunda seção. Com ML-KEM, agora há três seções. A primeira seção contém a chave pública PQ criptografada. A segunda seção contém a chave estática. A terceira seção contém o payload.

Formato criptografado:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   New Session Ephemeral Public Key    |
  +             32 bytes                  +
  |     Encoded with Elligator2           |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +           ML-KEM encap_key            +
  |       ChaCha20 encrypted data         |
  +      (see table below for length)     +
  |                                       |
  ~                                       ~
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +    (MAC) for encap_key Section        +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +           X25519 Static Key           +
  |       ChaCha20 encrypted data         |
  +             32 bytes                  +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +    (MAC) for Static Key Section       +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |       ChaCha20 encrypted data         |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +         (MAC) for Payload Section     +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+

Formato descriptografado:

Payload Part 1:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +       ML-KEM encap_key                +
  |                                       |
  +      (see table below for length)     +
  |                                       |
  ~                                       ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Payload Part 2:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +       X25519 Static Key               +
  |                                       |
  +      (32 bytes)                       +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+

  Payload Part 3:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |                                       |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+

Tamanhos:

1g) Formato de Resposta de Nova Sessão

Mudanças: O ratchet atual tem uma carga útil vazia para a primeira seção ChaCha, e a carga útil na segunda seção. Com ML-KEM, agora existem três seções. A primeira seção contém o texto cifrado PQ criptografado. A segunda seção tem uma carga útil vazia. A terceira seção contém a carga útil.

Formato criptografado:

  +----+----+----+----+----+----+----+----+
  |       Session Tag   8 bytes           |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Ephemeral Public Key           +
  |                                       |
  +            32 bytes                   +
  |     Encoded with Elligator2           |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  | ChaCha20 encrypted ML-KEM ciphertext  |
  +      (see table below for length)     +
  ~                                       ~
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +  (MAC) for ciphertext Section         +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +  (MAC) for key Section (no data)      +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |       ChaCha20 encrypted data         |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +         (MAC) for Payload Section     +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+

Formato descriptografado:

Payload Part 1:


  +----+----+----+----+----+----+----+----+
  |                                       |
  +       ML-KEM ciphertext               +
  |                                       |
  +      (see table below for length)     +
  |                                       |
  ~                                       ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Payload Part 2:

  empty

  Payload Part 3:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |                                       |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+

Tamanhos:

NTCP2

Atualize a especificação NTCP2 /docs/specs/ntcp2/ da seguinte forma:

Identificadores Noise

• “Noise_XKhfsaesobfse+hs2+hs3_25519+MLKEM512_ChaChaPoly_SHA256”
• “Noise_XKhfsaesobfse+hs2+hs3_25519+MLKEM768_ChaChaPoly_SHA256”
• “Noise_XKhfsaesobfse+hs2+hs3_25519+MLKEM1024_ChaChaPoly_SHA256”

1) SessionRequest

Mudanças: O NTCP2 atual contém apenas as opções na seção ChaCha. Com ML-KEM, a seção ChaCha também conterá a chave pública PQ criptografada.

Para que NTCP2 PQ e não-PQ possam ser suportados no mesmo endereço e porta do router, usamos o bit mais significativo do valor X (chave pública efêmera X25519) para marcar que é uma conexão PQ. Este bit sempre permanece desmarcado para conexões não-PQ.

Para Alice, após a mensagem ser criptografada pelo Noise, mas antes da ofuscação AES de X, defina X[31] |= 0x7f.

Para Bob, após a des-ofuscação AES de X, teste X[31] & 0x80. Se o bit estiver definido, limpe-o com X[31] &= 0x7f, e descriptografe via Noise como uma conexão PQ. Se o bit estiver limpo, descriptografe via Noise como uma conexão não-PQ normalmente.

Para PQ NTCP2 anunciado em um endereço de router e porta diferentes, isso não é necessário.

Para informações adicionais, consulte a seção Endereços Publicados abaixo.

Conteúdo bruto:

  +----+----+----+----+----+----+----+----+
  |        MS bit set to 1 and then       |
  +        obfuscated with RH_B           +
  |       AES-CBC-256 encrypted X         |
  +             (32 bytes)                +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaChaPoly encrypted data (MLKEM)   |
  +      (see table below for length)     +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  ~                                       ~
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (options)   |
  +         16 bytes                      +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  ~         padding (optional)            ~
  |     length defined in options block   |
  +----+----+----+----+----+----+----+----+

  Same as current specification except add a second ChaChaPoly frame

Dados não criptografados (tag de autenticação Poly1305 não mostrada):

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                   X                   |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM encap_key            |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |               options                 |
  +              (16 bytes)               +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

Nota: o campo de versão no bloco de opções da mensagem 1 deve ser definido como 2, mesmo para conexões PQ.

Tamanhos:

2) SessionCreated

Conteúdo bruto:

Conteúdo bruto:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +        obfuscated with RH_B           +
  |       AES-CBC-256 encrypted Y         |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (MLKEM)     |
  -      (see table below for length)     -
  +   k defined in KDF for message 2      +
  |  (before mixKey)                      |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (options)   |
  +         16 bytes                      +
  +   k defined in KDF for message 2      +
  |  (after mixKey)                       |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Same as current specification except add a second ChaChaPoly frame

Dados não criptografados (tag de autenticação Poly1305 não mostrada):

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                  Y                    |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM Ciphertext           |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |               options                 |
  +              (16 bytes)               +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

Tamanhos:

3) SessionConfirmed

Inalterado

Função de Derivação de Chave (KDF) (para fase de dados)

Inalterado

Endereços Publicados

Em todos os casos, use o nome do transporte NTCP2 como de costume.

Endereço/porta diferentes como não-PQ, ou apenas PQ, não-firewall NÃO é suportado. Isso não será implementado até que o NTCP2 não-PQ seja desabilitado, daqui a vários anos. Quando o não-PQ for desabilitado, múltiplas variantes PQ podem ser suportadas, mas apenas uma por endereço. No endereço do router, publique v=[3|4|5] para indicar MLKEM 512/768/1024. Alice não define o MSB da chave efêmera. Routers mais antigos verificarão o parâmetro v e pularão este endereço como não suportado.

Endereços com firewall (nenhum IP publicado): No endereço do router, publique v=2 (como de costume). Não há necessidade de publicar um parâmetro pq.

Alice pode se conectar a um Bob PQ usando a variante PQ que Bob publica, independentemente de Alice anunciar suporte pq em suas informações de router, ou se ela anuncia a mesma variante.

Na especificação atual, as mensagens 1 e 2 são definidas para ter uma quantidade “razoável” de preenchimento, com uma faixa de 0-31 bytes recomendada, e nenhum máximo especificado.

Preenchimento Máximo

Até a API 0.9.68 (versão 2.11.0), o Java I2P implementava um máximo de 256 bytes de padding para conexões não-PQ, no entanto isso não estava previamente documentado. A partir da API 0.9.69 (versão 2.12.0), o Java I2P implementa o mesmo padding máximo para conexões não-PQ como para MLKEM-512. Veja a tabela abaixo.

Use o tamanho de mensagem definido como o padding máximo, ou seja, o padding máximo dobrará o tamanho da mensagem para conexões PQ, conforme segue:

Atualize a especificação SSU2 /docs/specs/ssu2/ da seguinte forma:

SSU2

Note que MLKEM-1024 NÃO é suportado para SSU2, pois as chaves são muito grandes para caber em um datagrama padrão de 1500 bytes.

Identificadores Noise

• “Noise_XKhfschaobfse+hs1+hs2+hs3_25519+MLKEM512_ChaChaPoly_SHA256”
• “Noise_XKhfschaobfse+hs1+hs2+hs3_25519+MLKEM768_ChaChaPoly_SHA256”

O cabeçalho longo tem 32 bytes. É usado antes de uma sessão ser criada, para Token Request, SessionRequest, SessionCreated e Retry. Também é usado para mensagens Peer Test e Hole Punch fora de sessão.

Cabeçalho Longo

Nas mensagens seguintes, defina o campo ver (versão) no cabeçalho longo para 3 ou 4, para indicar MLKEM-512 ou MLKEM-768.

Nas mensagens seguintes, defina o campo ver (version) no cabeçalho longo para 2, como de costume, mesmo se MLKEM-512 ou MLKEM-768 for suportado. As implementações também podem definir o valor para 3 ou 4, se a outra extremidade suportar, mas isso não é necessário. As implementações devem aceitar qualquer valor 2-4.

• (0) Solicitação de Sessão
• (1) Sessão Criada
• (9) Tentar Novamente
• (10) Solicitação de Token
• (11) Perfuração de Hole

Discussão: Definir o campo de versão para 3 ou 4 pode não ser estritamente necessário para todos os tipos de mensagem, mas fazê-lo ajuda na detecção mais precoce de falhas para conexões pós-quânticas não suportadas. Token Request e Retry (tipos 9 e 10) devem ter versões 3/4 para consistência. Mensagens Hole Punch (tipo 11) podem não exigir esse tratamento, mas seguiremos o mesmo padrão para uniformidade. Mensagens Peer Test (tipo 7) são fora de sessão e não indicam intenção de iniciar uma sessão.

• (7) Teste de Peer (mensagens fora de sessão 5-7)

Antes da criptografia do cabeçalho:

inalterado

  +----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: 8 bytes, unsigned big endian integer

  Packet Number :: 4 bytes, unsigned big endian integer

  type :: The message type = 0, 1, 7, 9, 10, or 11

  ver :: The protocol version = 2, 3, or 4 for non-PQ, MLKEM512, MLKEM768

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Source Connection ID :: 8 bytes, unsigned big endian integer

  Token :: 8 bytes, unsigned big endian integer

Cabeçalho Curto

inalterado

SessionRequest (Tipo 0)

Mudança KDF para Proteção contra Spoofing: Para abordar os problemas levantados na Proposta 165 [Prop165]_, mas com uma solução diferente, modificamos o KDF para Session Request. Isso é apenas para sessões PQ. O KDF para sessões não-PQ permanece inalterado.

Conteúdo bruto:

// End of KDF for initial chain key (unchanged)
  // Bob static key
  // MixHash(bpk)
  h = SHA256(h || bpk);

  // Start of KDF for session request
  // NEW for PQ only
  // bhash = Bob router hash (32 bytes)
  // MixHash(bhash)
  h = SHA256(h || bhash);

  // Rest of KDF for session request, unchanged, as in SSU2 spec
  // MixHash(header)
  h = SHA256(h || header)

  ...

Conteúdo bruto:

  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key         +
  |    See Header Encryption KDF          |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Bob intro key n=0     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +       X, ChaCha20 encrypted           +
  |       with Bob intro key n=0          |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (MLKEM)     |
  +          (length varies)              +
  |  k defined in KDF for Session Request |
  +  n = 0                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (payload)   |
  +          (length varies)              +
  |  k defined in KDF for Session Request |
  +  n = 0                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Dados não criptografados (tag de autenticação Poly1305 não mostrada):

  +----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                   X                   |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM encap_key            |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |     see below for allowed blocks      |
  +----+----+----+----+----+----+----+----+

Tamanhos, não incluindo overhead do IP:

MTU mínimo para MLKEM768_X25519: 1318 para IPv4 e 1338 para IPv6. Veja abaixo.

SessionCreated (Tipo 1)

Conteúdo bruto:

Conteúdo bruto:

  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key and     +
  | derived key, see Header Encryption KDF|
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with derived key n=0       +
  |  See Header Encryption KDF            |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +       Y, ChaCha20 encrypted           +
  |       with derived key n=0            |
  +              (32 bytes)               +
  |       See Header Encryption KDF       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (MLKEM)     |
  ~  length varies                        ~
  +  k defined in KDF for Session Created +
  |  (before mixKey)                      |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (payload)   |
  ~  length varies                        ~
  +  k defined in KDF for Session Created +
  |  (after mixKey)                       |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Dados não criptografados (tag de autenticação Poly1305 não mostrada):

  +----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                  Y                    |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM Ciphertext           |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |      see below for allowed blocks     |
  +----+----+----+----+----+----+----+----+

Tamanhos, não incluindo overhead do IP:

MTU mínimo para MLKEM768_X25519: 1318 para IPv4 e 1338 para IPv6. Veja abaixo.

SessionConfirmed (Tipo 2)

inalterado

KDF para fase de dados

inalterado

Retransmissão e Teste de Pares

Os seguintes blocos contêm campos de versão. Eles permanecerão na versão 2 (para compatibilidade com um Bob não-PQ), e não mudarão para a versão 3/4 para PQ.

• Solicitação de Relay
• Resposta de Relay
• Introdução de Relay
• Teste de Peer

Em todos os casos, use o nome do transporte SSU2 como de costume. MLKEM-1024 não é suportado.

Endereços Publicados

Use o mesmo endereço/porta que não-PQ, não-firewalled. Uma ou ambas as variantes PQ são suportadas. No endereço do router, publique v=2 (como usual) e o novo parâmetro pq=[3|4|3,4|4,3] para indicar MLKEM 512/768/ambos. Routers com MTU menor que o mínimo especificado abaixo não devem publicar um parâmetro “pq” contendo “4”. Publique 4,3 para indicar uma preferência por MLKEM-768 ou 3,4 para indicar uma preferência por MLKEM-512. A versão real fica a critério do iniciador, e a preferência pode não ser honrada. Routers com MTU menor que o mínimo especificado abaixo não devem conectar usando MLKEM768. Routers mais antigos irão ignorar o parâmetro pq e conectar não-pq como usual.

Endereço/porta diferentes como não-PQ, ou apenas PQ, não-firewalled NÃO é suportado. Isso não será implementado até que o SSU2 não-PQ seja desabilitado, dentro de alguns anos. Quando não-PQ for desabilitado, uma ou ambas as variantes PQ são suportadas. No endereço do router, publique v=[3|4|3,4|4,3] para indicar MLKEM 512/768/ambos. Routers mais antigos irão verificar o parâmetro v e pular este endereço como não suportado.

Endereços com firewall (nenhum IP publicado): No endereço do router, publique v=2 (como de costume). O parâmetro pq DEVE ser publicado em endereços com firewall, para suportar relay.

Alice pode conectar-se a um Bob PQ usando a variante PQ que Bob publica, independentemente de Alice anunciar ou não o suporte PQ em suas informações de router, ou se ela anuncia a mesma variante.

Na especificação atual, as mensagens 1 e 2 são definidas para ter uma quantidade “razoável” de preenchimento, com uma faixa de 0-31 bytes recomendada, e nenhum máximo especificado.

MTU

Tenha cuidado para não exceder o MTU com MLKEM768. O MTU mínimo para MLKEM768_X25519 é 1318 para IPv4 e 1338 para IPv6 (assumindo um payload mínimo de 10 bytes com um bloco DateTime e um bloco Padding ou RelayTagRequest). O MTU mínimo para SSU2 em geral é 1280, então nem todos os peers podem usar MLKEM768. Não publique ou use MLKEM768 se o MTU real for menor que o mínimo, seja localmente ou como anunciado pelo peer. Tenha cuidado para não incluir tamanho de padding de forma que a mensagem 1 ou 2 excederia o MTU local ou remoto.

Streaming

TODO

Arquivos SU3

A seção 8.1 do rascunho IETF não permite HashML-DSA em certificados X.509 e não atribui OIDs para HashML-DSA, devido a complexidades de implementação e segurança reduzida.

Para assinaturas apenas PQ de arquivos SU3, use os OIDs definidos no rascunho IETF das variantes não-prehash para os certificados. Não definimos assinaturas híbridas de arquivos SU3, porque podemos ter que fazer hash dos arquivos duas vezes (embora HashML-DSA e X2559 usem a mesma função hash SHA512). Além disso, concatenar duas chaves e assinaturas em um certificado X.509 seria completamente fora do padrão.

Note que não permitimos assinatura Ed25519 de arquivos SU3, e embora tenhamos definido assinatura Ed25519ph, nunca concordamos com um OID para ela, ou a usamos.

Os tipos de assinatura normais são proibidos para arquivos SU3; use as variantes ph (prehash).

O novo tamanho máximo de Destination será 2599 (3468 em base 64).

Outras Especificações

Atualize outros documentos que fornecem orientação sobre tamanhos de Destination, incluindo:

Aumento de tamanho (bytes):

• SAMv3
• Bittorrent
• Diretrizes para desenvolvedores
• Nomenclatura / catálogo de endereços / servidores de redirecionamento
• Outros documentos

Análise de Sobrecarga

Troca de Chaves

Velocidade:

Resultados preliminares de testes em Java:

Assinaturas

Tamanhos típicos de chave, assinatura, RIdent, Dest ou aumentos de tamanho (Ed25519 incluído para referência) assumindo tipo de criptografia X25519 para RIs. Tamanho adicionado para uma Router Info, LeaseSet, datagramas com resposta, e cada um dos dois pacotes de streaming (SYN e SYN ACK) listados. Destinations e Leasesets atuais contêm preenchimento repetido e são compressíveis em trânsito. Novos tipos não contêm preenchimento e não serão compressíveis, resultando em um aumento de tamanho muito maior em trânsito. Veja a seção de design acima.

Velocidade:

Resultados preliminares de testes em Java:

Análise de Segurança

As categorias de segurança NIST são resumidas no slide 10 da apresentação NIST . Critérios preliminares: Nossa categoria mínima de segurança NIST deve ser 2 para protocolos híbridos e 3 para PQ-only.

Handshakes

Categorias de segurança NIST FIPS 203 :

Esta proposta define tanto tipos de assinatura híbridos quanto apenas PQ. O híbrido MLDSA44 é preferível ao MLDSA65 apenas PQ. Os tamanhos de chaves e assinaturas para MLDSA65 e MLDSA87 são provavelmente grandes demais para nós, pelo menos no início.

Assinaturas

Categorias de segurança NIST FIPS 204 :

Embora vamos definir e implementar 3 tipos de criptografia e 9 tipos de assinatura, planejamos medir o desempenho durante o desenvolvimento e analisar ainda mais os efeitos do aumento dos tamanhos das estruturas. Também continuaremos a pesquisar e monitorar desenvolvimentos em outros projetos e protocolos.

Preferências de Tipo

Após desenvolvimento e testes, iremos definir um tipo preferido ou padrão para cada caso de uso. A seleção exigirá fazer compromissos entre largura de banda, CPU e nível de segurança estimado. Nem todos os tipos podem ser adequados ou permitidos para todos os casos de uso.

As preferências preliminares são as seguintes, sujeitas a alterações:

Encryption: MLKEM768_X25519

Assinaturas: MLDSA44_EdDSA_SHA512_Ed25519

As restrições preliminares são as seguintes, sujeitas a alterações:

Assinaturas: MLDSA87 e variante híbrida provavelmente muito grandes; MLDSA65 e variante híbrida podem ser muito grandes

As bibliotecas Bouncycastle, BoringSSL e WolfSSL agora suportam MLKEM e MLDSA. O suporte do OpenSSL estará em sua versão 3.5 lançada em 8 de abril de 2025 OpenSSL .

Notas de Implementação

Suporte de Biblioteca

A biblioteca Noise do southernstorm.com adaptada pelo Java I2P continha suporte preliminar para handshakes híbridos, mas removemos por não estar sendo usado; teremos que adicioná-lo de volta e atualizá-lo para corresponder à especificação Noise HFS .

Usaremos a variante de assinatura “hedged” ou randomizada, não a variante “determinística”, conforme definido na seção 3.4 do FIPS 204 . Isso garante que cada assinatura seja diferente, mesmo quando sobre os mesmos dados, e fornece proteção adicional contra ataques de canal lateral. Embora o FIPS 204 especifique que a variante “hedged” é o padrão, isso pode ou não ser verdade em várias bibliotecas. Os implementadores devem garantir que a variante “hedged” seja usada para assinatura.

Variantes de Assinatura

Utilizamos o processo de assinatura normal (chamado Pure ML-DSA Signature Generation) que codifica a mensagem internamente como 0x00 || len(ctx) || ctx || message, onde ctx é algum valor opcional de tamanho 0x00..0xFF. Não estamos usando nenhum contexto opcional. len(ctx) == 0. Este processo é definido no FIPS 204 Algorithm 2 step 10 e Algorithm 3 step 5. Note que alguns vetores de teste publicados podem requerer a configuração de um modo onde a mensagem não é codificada.

O aumento do tamanho resultará em muito mais fragmentação de tunnel para armazenamentos NetDB, handshakes de streaming e outras mensagens. Verifique mudanças de desempenho e confiabilidade.

Confiabilidade

Encontre e verifique qualquer código que limite o tamanho em bytes das informações do router e leasesets.

Tamanhos das Estruturas

Revisar e possivelmente reduzir o máximo de LS/RI armazenados na RAM ou no disco, para limitar o aumento de armazenamento. Aumentar os requisitos mínimos de largura de banda para floodfills?

NetDB

A classificação/detecção automática de múltiplos protocolos nos mesmos tunnels deve ser possível baseada numa verificação de comprimento da mensagem 1 (New Session Message). Usando MLKEM512_X25519 como exemplo, o comprimento da mensagem 1 é 816 bytes maior que o protocolo ratchet atual, e o tamanho mínimo da mensagem 1 (com apenas um payload DateTime incluído) é 919 bytes. A maioria dos tamanhos de mensagem 1 com ratchet atual tem um payload menor que 816 bytes, então podem ser classificadas como ratchet não-híbrido. Mensagens grandes são provavelmente POSTs que são raras.

Ratchet

Tunnels Compartilhados

Portanto, a estratégia recomendada é:

Isso deve nos permitir suportar eficientemente o ratchet padrão e o ratchet híbrido no mesmo destino, assim como anteriormente suportávamos ElGamal e ratchet no mesmo destino. Portanto, podemos migrar para o protocolo híbrido MLKEM muito mais rapidamente do que se não pudéssemos suportar protocolos duplos para o mesmo destino, porque podemos adicionar suporte MLKEM a destinos existentes.

• Se a mensagem 1 for menor que 919 bytes, é o protocolo ratchet atual.
• Se a mensagem 1 for maior ou igual a 919 bytes, provavelmente é MLKEM512_X25519. Tente MLKEM512_X25519 primeiro e, se falhar, tente o protocolo ratchet atual.

As combinações suportadas obrigatórias são:

As seguintes combinações podem ser complexas e NÃO são obrigatórias de serem suportadas, mas podem ser, dependendo da implementação:

• X25519 + MLKEM512
• X25519 + MLKEM768
• X25519 + MLKEM1024

Pode ser que não tentemos suportar múltiplos algoritmos MLKEM (por exemplo, MLKEM512_X25519 e MLKEM_768_X25519) no mesmo destino. Escolha apenas um; no entanto, isso depende de selecionarmos uma variante MLKEM preferida, para que os túneis de cliente HTTP possam usar uma. Dependente da implementação.

• Mais de um MLKEM
• ElG + um ou mais MLKEM
• X25519 + um ou mais MLKEM
• ElG + X25519 + um ou mais MLKEM

Nós PODEMOS tentar suportar três algoritmos (por exemplo X25519, MLKEM512_X25519, e MLKEM769_X25519) no mesmo destino. A classificação e estratégia de repetição podem ser muito complexas. A configuração e interface de configuração podem ser muito complexas. Dependente da implementação.

Provavelmente NÃO tentaremos suportar algoritmos ElGamal e híbridos no mesmo destino. ElGamal está obsoleto, e ElGamal + híbrido apenas (sem X25519) não faz muito sentido. Além disso, as Mensagens de Nova Sessão ElGamal e Híbridas são ambas grandes, então as estratégias de classificação muitas vezes teriam que tentar ambas as descriptografias, o que seria ineficiente. Dependente da implementação.

Os clientes podem usar as mesmas chaves estáticas X25519 ou chaves diferentes para os protocolos X25519 e híbrido nos mesmos tunnels, dependendo da implementação.

A especificação ECIES permite Garlic Messages no payload da New Session Message, o que possibilita a entrega 0-RTT do pacote de streaming inicial, geralmente um HTTP GET, juntamente com o leaseset do cliente. No entanto, o payload da New Session Message não possui forward secrecy. Como esta proposta está enfatizando forward secrecy aprimorada para ratchet, as implementações podem ou devem adiar a inclusão do payload de streaming, ou da mensagem de streaming completa, até a primeira Existing Session Message. Isso seria às custas da entrega 0-RTT. As estratégias também podem depender do tipo de tráfego ou tipo de tunnel, ou de GET vs. POST, por exemplo. Dependente da implementação.

Forward Secrecy

MLKEM, MLDSA, ou ambos no mesmo destino, aumentará drasticamente o tamanho da Nova Mensagem de Sessão, conforme descrito acima. Isso pode diminuir significativamente a confiabilidade da entrega da Nova Mensagem de Sessão através de tunnels, onde elas devem ser fragmentadas em múltiplas mensagens de tunnel de 1024 bytes. O sucesso da entrega é proporcional ao número exponencial de fragmentos. As implementações podem usar várias estratégias para limitar o tamanho da mensagem, às custas da entrega 0-RTT. Dependente da implementação.

Tamanho da Nova Sessão

Definimos o MSB da chave efêmera (key[31] & 0x80) na solicitação de sessão para indicar que esta é uma conexão híbrida. Isso nos permite executar tanto NTCP padrão quanto NTCP híbrido na mesma porta. Apenas uma variante híbrida seria suportada e anunciada no endereço do router. Por exemplo, v=2,3 ou v=2,4 ou v=2,5.

NTCP2

Como Alice, para uma conexão PQ, antes da ofuscação, defina X[31] |= 0x80. Isso torna X uma chave pública X25519 inválida. Após a ofuscação, AES-CBC irá randomizá-la. O MSB de X será aleatório após a ofuscação.

Ofuscação

Como Bob, teste se (X[31] & 0x80) != 0 após a des-ofuscação. Se for o caso, é uma conexão PQ.

A versão mínima do router necessária para NTCP2-PQ está por definir.

Nota: Os códigos de tipo são apenas para uso interno. Os routers permanecerão tipo 4, e o suporte será indicado nos endereços do router.

Nota: Os códigos de tipo são apenas para uso interno. Os routers permanecerão como tipo 4, e o suporte será indicado nos endereços do router.

SSU2

Usamos o campo de versão no cabeçalho longo e o definimos como 3 para MLKEM512 e 4 para MLKEM768. v=2,3,4 no endereço seria suficiente.

Nota: Os códigos de tipo são apenas para uso interno. Os routers permanecerão como tipo 4, e o suporte será indicado nos endereços do router.

Nota: Os códigos de tipo são apenas para uso interno. Os routers permanecerão como tipo 4, e o suporte será indicado nos endereços do router.

Compatibilidade do Router

Nomes de Transporte

Em todos os casos, use os nomes de transporte NTCP2 e SSU2 como de costume.

Tipos de Criptografia do Router

Não recomendado. Use apenas os novos transportes listados acima que correspondem ao tipo de router. Routers mais antigos não conseguem conectar, construir tunnels através, ou enviar mensagens netDb para. Levaria vários ciclos de lançamento para depurar e garantir suporte antes de habilitar por padrão. Pode estender a implementação por um ano ou mais em relação às alternativas abaixo.

Routers Tipo 5/6/7

Recomendado. Como PQ não afeta a chave estática X25519 ou protocolos de handshake N, poderíamos deixar os routers como tipo 4, e apenas anunciar novos transportes. Routers mais antigos ainda poderiam conectar, construir tunnels através, ou enviar mensagens netDb para.

Routers Tipo 4

MLKEM-768 é recomendado para Ratchet, NTCP2 e SSU2, como o melhor equilíbrio entre segurança e comprimento de chave.

Recomendações

Routers mais antigos verificam RIs e, portanto, não conseguem conectar, construir túneis ou enviar mensagens netDb. Levaria vários ciclos de lançamento para depurar e garantir suporte antes de ativar por padrão. Seriam os mesmos problemas do lançamento do tipo de criptografia 5/6/7; pode estender o lançamento por um ano ou mais em relação à alternativa de lançamento do tipo de criptografia tipo 4 listada acima.

Tipos de Assinatura do Router

Routers Tipo 12-17

Nenhuma alternativa.

Estas podem estar presentes no LS com chaves X25519 tipo 4 mais antigas. Routers mais antigos irão ignorar chaves desconhecidas.

Tipos de Criptografia LS

Chaves LS Tipo 5-7

Os destinos podem suportar múltiplos tipos de chave, mas apenas fazendo tentativas de descriptografia da mensagem 1 com cada chave. A sobrecarga pode ser mitigada mantendo contagens de descriptografias bem-sucedidas para cada chave, e tentando primeiro a chave mais usada. O Java I2P usa esta estratégia para ElGamal+X25519 no mesmo destino.

Os routers verificam as assinaturas do leaseSet e, portanto, não conseguem conectar ou receber leaseSets para destinos do tipo 12-17. Seriam necessários vários ciclos de lançamento para depurar e garantir suporte antes de habilitar por padrão.

Tipos de Assin. de Destino

Destinos Tipo 12-17

Nenhuma alternativa.

Estas podem estar presentes no LS com chaves X25519 tipo 4 mais antigas. Routers mais antigos irão ignorar chaves desconhecidas.

Prioridades e Implementação

Os dados mais valiosos são o tráfego fim-a-fim, criptografado com ratchet. Como um observador externo entre os saltos do tunnel, isso é criptografado duas vezes mais, com criptografia de tunnel e criptografia de transporte. Como um observador externo entre OBEP e IBGW, é criptografado apenas uma vez mais, com criptografia de transporte. Como participante OBEP ou IBGW, ratchet é a única criptografia. No entanto, como os tunnels são unidirecionais, capturar ambas as mensagens no handshake ratchet exigiria routers em conluio, a menos que os tunnels fossem construídos com o OBEP e IBGW no mesmo router.

O modelo de ameaça PQ de quebrar as chaves de autenticação em um período razoável de tempo (digamos alguns meses) e então se passar pela autenticação ou descriptografar em quase tempo real, está muito mais distante? E é quando gostaríamos de migrar para chaves estáticas PQC.

Portanto, o modelo de ameaça PQ mais antigo é OBEP/IBGW armazenando tráfego para descriptografia posterior. Devemos implementar hybrid ratchet primeiro.

Ratchet é a prioridade mais alta. Transportes são os próximos. Assinaturas são a prioridade mais baixa.

O lançamento de assinaturas também será um ano ou mais tarde do que o lançamento de criptografia, porque nenhuma compatibilidade com versões anteriores é possível. Além disso, a adoção do MLDSA na indústria será padronizada pelo CA/Browser Forum e pelas Autoridades Certificadoras. As CAs precisam primeiro de suporte a módulo de segurança de hardware (HSM), que atualmente não está disponível CA/Browser Forum . Esperamos que o CA/Browser Forum conduza as decisões sobre escolhas específicas de parâmetros, incluindo se deve apoiar ou exigir assinaturas compostas rascunho IETF .

A implementação da assinatura também ocorrerá um ano ou mais depois da implementação da criptografia, porque não é possível manter compatibilidade com versões anteriores.

O trabalho sobre o suporte à assinatura MLDSA no I2P está suspenso até o final de 2027 ou 2028, aguardando a definição por órgãos de padronização sobre os algoritmos, possivelmente reduzindo os tamanhos de chave e/ou assinatura, além de promover a adoção pela indústria. Veja CABFORUM e PLANTS . Além disso, a adoção do MLDSA pela indústria será padronizada pelo Fórum CA/Navegadores (CA/Browser Forum) e pelas Autoridades de Certificação (CAs). As CAs precisam primeiro de suporte em módulos de segurança de hardware (HSM), o que atualmente não está disponível CA/Browser Forum . Esperamos que o Fórum CA/Navegadores conduza as decisões sobre escolhas específicas de parâmetros, incluindo se apoiar ou exigir assinaturas compostas rascunho do IETF .

Migração

Se não conseguirmos suportar ambos os protocolos de catraca antigo e novo nos mesmos túneis, a migração será muito mais difícil.

Deveríamos ser capazes de simplesmente tentar um e depois o outro, como fizemos com o X25519, para ser comprovado.

Problemas

• Seleção de Noise Hash - manter SHA256 ou atualizar? SHA256 deve ser bom por mais 20-30 anos, não ameaçado por PQ, Veja apresentação NIST e apresentação NCCOE . Se SHA256 for quebrado, temos problemas piores (netdb).
• NTCP2 porta separada, endereço de router separado
• SSU2 relay / teste de peer
• Campo de versão SSU2
• Versão de endereço de router SSU2

Referências

• CABFORUM
• Choosing-Hash
• CLOUDFLARE
• COMMON
• COMPOSITE-SIGS
• ECIES
• FORUM
• FIPS202
• FIPS203
• FIPS204
• FIPS205
• MLDSA-OIDS
• NIST-PQ
• NIST-PQ-UPDATE
• NIST-PQ-END
• NIST-VECTORS
• Noise
• Noise-Hybrid
• NSA-PQ
• NTCP2
• OPENSSL
• Prop165
• PQ-WIREGUARD
• RFC-2104
• Rosenpass
• Rosenpass-Whitepaper
• SSH-HYBRID
• SSU2
• TLS-HYBRID