Protocolos de Criptografía Post-Cuántica

Estado

Descripción general

Si bien la investigación y la competencia por criptografía poscuántica (PQ) adecuada han avanzado durante una década, las opciones no se han aclarado hasta hace poco.

Comenzamos a analizar las implicaciones de la criptografía post-cuántica en 2022 zzz.i2p .

Los estándares TLS incorporaron soporte para cifrado híbrido en los últimos dos años y ahora se utiliza en una parte significativa del tráfico cifrado en internet gracias al soporte en Chrome y Firefox Cloudflare .

NIST ha finalizado y publicado recientemente los algoritmos recomendados para la criptografía post-cuántica NIST . Varias bibliotecas criptográficas comunes ya admiten los estándares NIST o lanzarán soporte en un futuro próximo.

Tanto Cloudflare como NIST recomiendan que la migración comience de inmediato. Véase también el FAQ de la NSA sobre criptografía post-cuántica de 2022 NSA . I2P debería ser un referente en seguridad y criptografía. Este es el momento de implementar los algoritmos recomendados. Utilizando nuestro flexible sistema de tipos criptográficos y de firma, añadiremos tipos para criptografía híbrida, así como para firmas post-cuánticas e híbridas.

Objetivos

• Seleccionar algoritmos resistentes a computación cuántica (PQ)
• Añadir algoritmos PQ puros e híbridos a los protocolos I2P donde corresponda
• Definir múltiples variantes
• Seleccionar las mejores variantes tras implementación, pruebas, análisis e investigación
• Añadir soporte de forma incremental y con compatibilidad hacia atrás

No Objetivos

• No cambiar los protocolos de cifrado unidireccionales (Noise N)
• No alejarse de SHA256, no está amenazado a corto plazo por la computación cuántica (PQ)
• No seleccionar las variantes preferidas definitivas en este momento

Modelo de Amenazas

• Routers en el OBEP o IBGW, posiblemente en colusión, almacenando mensajes garlic para descifrado posterior (confidencialidad directa)
• Observadores de red almacenando mensajes de transporte para descifrado posterior (confidencialidad directa)
• Participantes de la red falsificando firmas para RI, LS, streaming, datagramas u otras estructuras

Protocolos afectados

Modificaremos los siguientes protocolos, aproximadamente en orden de desarrollo. El despliegue general probablemente se llevará a cabo desde finales de 2025 hasta mediados de 2027. Consulte la sección de Prioridades y Despliegue a continuación para más detalles.

Diseño

Admitiremos los estándares NIST FIPS 203 y 204 FIPS 203 FIPS 204 , que están basados en, pero NO son compatibles con, CRYSTALS-Kyber y CRYSTALS-Dilithium (versiones 3.1, 3 y anteriores).

Intercambio de claves

Admitiremos el intercambio de claves híbrido en los siguientes protocolos:

Noise N no utiliza un intercambio de claves bidireccional, por lo que no es adecuado para cifrado híbrido.

Por lo tanto, solo admitiremos cifrado híbrido para NTCP2, SSU2 y Ratchet. Definiremos las tres variantes de ML-KEM tal como se especifica en FIPS 203 , para un total de 3 nuevos tipos de cifrado. Los tipos híbridos solo se definirán en combinación con X25519.

Los nuevos tipos de cifrado son:

Firmas

Admitiremos firmas PQ e híbridas en las siguientes estructuras:

Por lo tanto, admitiremos tanto firmas exclusivamente PQ como firmas híbridas. Definiremos las tres variantes de ML-DSA tal como se especifica en FIPS 204 , tres variantes híbridas con Ed25519 y tres variantes exclusivamente PQ con prehash únicamente para archivos SU3, lo que da un total de 9 nuevos tipos de firma. Los tipos híbridos solo se definirán en combinación con Ed25519. Utilizaremos el ML-DSA estándar, NO las variantes de pre-hash (HashML-DSA), excepto para los archivos SU3.

Los nuevos tipos de firma son:

Los certificados X.509 y otras codificaciones DER utilizarán las estructuras compuestas y OIDs definidos en el borrador de IETF .

Dado que los nuevos tipos de destino e identidad de router no contendrán relleno, no serán compresibles. Los tamaños de los destinos e identidades de router que se comprimen con gzip en tránsito aumentarán entre 12x y 38x dependiendo del algoritmo.

Para los Destinations (destinos), los nuevos tipos de firma son compatibles con todos los tipos de cifrado en el leaseSet. Establezca el tipo de cifrado en el certificado de clave en NONE (255).

Combinaciones Legales

Para RouterIdentities, el tipo de cifrado ElGamal está obsoleto. Los nuevos tipos de firma son compatibles únicamente con el cifrado X25519 (tipo 4). Los nuevos tipos de cifrado se indicarán en las RouterAddresses. El tipo de cifrado en el certificado de clave continuará siendo el tipo 4.

Los vectores de prueba para SHA3-256, SHAKE128 y SHAKE256 están disponibles en NIST .

Nueva Criptografía Requerida

• ML-KEM (anteriormente CRYSTALS-Kyber) FIPS 203
• ML-DSA (anteriormente CRYSTALS-Dilithium) FIPS 204
• SHA3-128 (anteriormente Keccak-256) FIPS 202 Utilizado únicamente para SHAKE128
• SHA3-256 (anteriormente Keccak-512) FIPS 202
• SHAKE128 y SHAKE256 (extensiones XOF de SHA3-128 y SHA3-256) FIPS 202

Ten en cuenta que la biblioteca Java bouncycastle admite todo lo anterior. La compatibilidad con la biblioteca C++ está disponible en OpenSSL 3.5 OpenSSL .

No admitiremos FIPS 205 (Sphincs+), ya que es mucho más lento y pesado que ML-DSA. No admitiremos el próximo FIPS 206 (Falcon), puesto que aún no ha sido estandarizado. No admitiremos NTRU ni otros candidatos de criptografía post-cuántica que no hayan sido estandarizados por el NIST.

Alternativas

Existe una investigación sobre la adaptación de Wireguard (IK) para criptografía puramente PQ (post-cuántica), aunque dicho trabajo presenta varias cuestiones abiertas sin resolver. Posteriormente, este enfoque fue implementado como Rosenpass Rosenpass whitepaper para PQ Wireguard.

Rosenpass

Rosenpass utiliza un handshake similar a Noise KK con claves estáticas preshared Classic McEliece 460896 (500 KB cada una) y claves efímeras Kyber-512 (esencialmente MLKEM-512). Dado que los textos cifrados de Classic McEliece tienen solo 188 bytes, y las claves públicas y textos cifrados de Kyber-512 son de tamaño razonable, ambos mensajes del handshake caben en un MTU UDP estándar. La clave compartida de salida (osk) del handshake PQ KK se utiliza como clave preshared de entrada (psk) para el handshake IK estándar de Wireguard. Por lo tanto, hay dos handshakes completos en total: uno puramente PQ y otro puramente X25519.

No podemos hacer nada de esto para reemplazar nuestros handshakes XK e IK porque:

Hay mucha información valiosa en el whitepaper, y lo revisaremos en busca de ideas e inspiración. PENDIENTE.

• No podemos usar KK, Bob no tiene la clave estática de Alice
• Las claves estáticas de 500KB son demasiado grandes
• No queremos un viaje de ida y vuelta adicional

Actualice las secciones y tablas en el documento de estructuras comunes /docs/specs/common-structures/ de la siguiente manera:

Especificación

Estructuras Comunes

Los nuevos tipos de Clave Pública son:

PublicKey

Las claves públicas híbridas son la clave X25519. Las claves públicas KEM son la clave PQ efímera enviada de Alice a Bob. La codificación y el orden de bytes se definen en FIPS 203 .

Los nuevos tipos de Clave Privada son:

PrivateKey

Las claves privadas híbridas son las claves X25519. Las claves privadas KEM son exclusivas para Alice. La codificación KEM y el orden de bytes se definen en FIPS 203 .

SigningPublicKey

Las claves públicas de firma híbridas consisten en la clave Ed25519 seguida de la clave PQ, tal como se define en el borrador IETF . La codificación y el orden de bytes se definen en FIPS 204 .

SigningPrivateKey

Las claves privadas de firma híbrida consisten en la clave Ed25519 seguida de la clave PQ (post-cuántica), tal como se define en el borrador IETF . La codificación y el orden de bytes se definen en FIPS 204 .

Firma

Las firmas híbridas son la firma Ed25519 seguida de la firma PQ (post-cuántica), tal como se define en el borrador IETF . Las firmas híbridas se verifican comprobando ambas firmas, y el proceso falla si cualquiera de ellas no es válida. La codificación y el orden de bytes se definen en FIPS 204 .

Certificados de clave

Las claves públicas de firma híbridas consisten en la clave Ed25519 seguida de la clave PQ, tal como se define en el borrador IETF . La codificación y el orden de bytes se definen en FIPS 204 .

Para destinos con tipos de firma Hybrid o PQ, utilice NONE (tipo 255) para el tipo de cifrado, pero no hay clave criptográfica, y la sección principal completa de 384 bytes está destinada a la clave de firma.

Tamaños de destino

A continuación se indican las longitudes para los nuevos tipos de Destination. El tipo de cifrado para todos es NONE (tipo 255) y la longitud de la clave de cifrado se trata como 0. La sección completa de 384 bytes se utiliza para la primera parte de la clave pública de firma. NOTA: Esto es diferente a la especificación para los tipos de firma ECDSA_SHA512_P521 y RSA, donde se mantuvo la clave ElGamal de 256 bytes en el destination aunque no se utilizara.

Sin relleno. La longitud total es 7 + longitud total de la clave. La longitud del certificado de clave es 4 + longitud excedente de la clave.

Ejemplo de flujo de bytes de destino de 1319 bytes para MLDSA44:

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

Tamaños de RouterIdent

A continuación se indican las longitudes para los nuevos tipos de Destination. El tipo de cifrado para todos es X25519 (tipo 4). La sección completa de 352 bytes tras la clave pública X25519 se utiliza para la primera parte de la clave pública de firma. Sin relleno. La longitud total es 39 + longitud total de la clave. La longitud del certificado de clave es 4 + longitud excedente de la clave.

Ejemplo de flujo de bytes de identidad de router de 1351 bytes para MLDSA44:

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

Patrones de Intercambio de Claves

Los handshakes (intercambios de autenticación) utilizan patrones de handshake del Protocolo Noise .

Se utiliza la siguiente asignación de letras:

• e = clave efímera de un solo uso
• s = clave estática
• p = carga útil del mensaje
• e1 = clave PQ efímera de un solo uso, enviada de Alice a Bob
• ekem1 = el texto cifrado KEM, enviado de Bob a Alice

Las siguientes modificaciones a XK e IK para la confidencialidad directa híbrida (hfs, por sus siglas en inglés) se especifican en la sección 5 de la especificación Noise HFS :

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)

El patrón e1 se define de la siguiente manera, tal como se especifica en la sección 4 de la especificación 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)

El patrón ekem1 se define de la siguiente manera, según lo especificado en la sección 4 de la especificación Noise HFS :

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 del protocolo de enlace Noise

Problemas

• ¿Deberíamos dejar de enviar datos ratchet 0-RTT (distintos del LS)?
• ¿Deberíamos cambiar el ratchet de IK a XK si no enviamos datos 0-RTT?

Descripción general

Esta sección aplica tanto a los protocolos IK como XK.

El handshake híbrido está definido en la especificación Noise HFS . El primer mensaje, de Alice a Bob, contiene e1, la clave de encapsulación, antes del payload del mensaje. Esto se trata como una clave estática adicional; se llama a EncryptAndHash() (como Alice) o DecryptAndHash() (como Bob). Luego se procesa el payload del mensaje de la manera habitual.

El segundo mensaje, de Bob a Alice, contiene ekem1, el texto cifrado, antes del payload del mensaje. Esto se trata como una clave estática adicional; se llama a EncryptAndHash() sobre él (como Bob) o DecryptAndHash() (como Alice). Luego, se calcula el kem_shared_key y se llama a MixKey(kem_shared_key). A continuación, se procesa el payload del mensaje de la manera habitual.

Operaciones ML-KEM definidas

Definimos las siguientes funciones correspondientes a los bloques de construcción criptográficos utilizados según se definen en 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.

Tenga en cuenta que tanto el encap_key como el texto cifrado están encriptados dentro de bloques ChaCha/Poly en los mensajes 1 y 2 del protocolo de enlace Noise. Serán descifrados como parte del proceso de protocolo de enlace.

La kem_shared_key se mezcla en la clave de encadenamiento mediante MixHash(). Consulte a continuación para más detalles.

KDF de Alice para el Mensaje 1

Para XK: Después del patrón de mensaje ’es’ y antes del payload (carga útil), añadir:

O

Para IK: Después del patrón de mensaje ’es’ y antes del patrón de mensaje ’s’, añadir:

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

KDF de Bob para el Mensaje 1

Para XK: Después del patrón de mensaje ’es’ y antes del payload (carga útil), añadir:

O

Para IK: Después del patrón de mensaje ’es’ y antes del patrón de mensaje ’s’, añadir:

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

KDF de Bob para el Mensaje 2

Para XK: Después del patrón de mensaje ’ee’ y antes del payload, añadir:

O

Para IK: Después del patrón de mensaje ’ee’ y antes del patrón de mensaje ‘se’, agregar:

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 de Alice para el Mensaje 2

Después del patrón de mensaje ’ee’ (y antes del patrón de mensaje ‘ss’ para IK), añadir:

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 el Mensaje 3

sin cambios

KDF para split()

sin cambios

Ratchet

Actualizar la especificación ECIES-Ratchet /docs/specs/ecies/ de la siguiente manera:

Identificadores de Noise

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

1b) Formato de nueva sesión (con vinculación)

Cambios: El ratchet actual contenía la clave estática en la primera sección ChaCha y el payload (carga útil) en la segunda sección. Con ML-KEM, ahora hay tres secciones. La primera sección contiene la clave pública PQ cifrada. La segunda sección contiene la clave estática. La tercera sección contiene el payload.

Formato cifrado:

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

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

Tamaños:

1g) Formato de respuesta de nueva sesión

Cambios: El ratchet actual tiene un payload vacío para la primera sección ChaCha, y el payload en la segunda sección. Con ML-KEM, ahora hay tres secciones. La primera sección contiene el texto cifrado PQ encriptado. La segunda sección tiene un payload vacío. La tercera sección contiene el payload.

Formato cifrado:

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

Payload Part 1:


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

  Payload Part 2:

  empty

  Payload Part 3:

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

Tamaños:

NTCP2

Actualizar la especificación NTCP2 /docs/specs/ntcp2/ de la siguiente manera:

Identificadores de 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

Cambios: El NTCP2 actual contiene únicamente las opciones de la sección ChaCha. Con ML-KEM, la sección ChaCha también contendrá la clave pública PQ cifrada.

Para que PQ y non-PQ NTCP2 puedan ser compatibles en la misma dirección y puerto del router, utilizamos el bit más significativo del valor X (clave pública efímera X25519) para indicar que se trata de una conexión PQ. Este bit siempre está sin activar en conexiones non-PQ.

Para Alice, después de que el mensaje sea cifrado por Noise, pero antes de la ofuscación AES de X, establece X[31] |= 0x7f.

Para Bob, después de la des-ofuscación AES de X, verificar X[31] & 0x80. Si el bit está establecido, limpiarlo con X[31] &= 0x7f y descifrar mediante Noise como una conexión PQ. Si el bit está limpio, descifrar mediante Noise como una conexión no PQ de la manera habitual.

Para PQ NTCP2 anunciado en una dirección de router y puerto diferente, esto no es necesario.

Para obtener información adicional, consulte la sección Direcciones publicadas a continuación.

Contenido sin procesar:

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

Datos sin cifrar (etiqueta de autenticación Poly1305 no 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: el campo de versión en el bloque de opciones del mensaje 1 debe establecerse en 2, incluso para conexiones PQ.

Tamaños:

2) SessionCreated

Cambios: el NTCP2 actual contiene solo las opciones en una única sección ChaCha. Con ML-KEM, habrá una nueva sección ChaCha antes de las opciones, que contendrá el texto cifrado PQ cifrado.

Contenido sin procesar:

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

Datos sin cifrar (etiqueta de autenticación Poly1305 no mostrada):

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

Tamaños:

3) SessionConfirmed

Sin cambios

Función de Derivación de Clave (KDF) (para la fase de datos)

Sin cambios

Direcciones publicadas

En todos los casos, utilice el nombre de transporte NTCP2 como de costumbre.

No se admite una dirección/puerto diferente a los no-PQ, ni PQ exclusivo sin firewall. Esto no se implementará hasta que se deshabilite NTCP2 no-PQ, lo cual ocurrirá en varios años. Cuando se deshabilite el modo no-PQ, podrían admitirse múltiples variantes PQ, pero solo una por dirección. En la dirección del router, se publica v=[3|4|5] para indicar MLKEM 512/768/1024. Alice no establece el MSB de la clave efímera. Los routers más antiguos verificarán el parámetro v y omitirán esta dirección por no ser compatible.

Direcciones con firewall (sin IP publicada): En la dirección del router, publicar v=2 (como de costumbre). No es necesario publicar un parámetro pq.

Alice puede conectarse a un Bob PQ utilizando la variante PQ que Bob publica, independientemente de si Alice anuncia soporte PQ en su router info, o si anuncia la misma variante.

En la especificación actual, los mensajes 1 y 2 están definidos para tener una cantidad “razonable” de relleno, con un rango recomendado de 0 a 31 bytes y sin un máximo especificado.

Relleno máximo

Hasta la API 0.9.68 (versión 2.11.0), Java I2P implementaba un máximo de 256 bytes de relleno para conexiones no-PQ, aunque esto no estaba documentado anteriormente. A partir de la API 0.9.69 (versión 2.12.0), Java I2P implementa el mismo relleno máximo para conexiones no-PQ que para MLKEM-512. Véase la tabla a continuación.

Utilizar el tamaño de mensaje definido como el relleno máximo, es decir, el relleno máximo duplicará el tamaño del mensaje para las conexiones PQ, de la siguiente manera:

Actualizar la especificación SSU2 /docs/specs/ssu2/ de la siguiente manera:

SSU2

Tenga en cuenta que MLKEM-1024 NO es compatible con SSU2, ya que las claves son demasiado grandes para caber dentro de un datagrama estándar de 1500 bytes.

Identificadores de Noise

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

El encabezado largo tiene 32 bytes. Se utiliza antes de que se cree una sesión, para los mensajes Token Request, SessionRequest, SessionCreated y Retry. También se utiliza para los mensajes Peer Test y Hole Punch fuera de sesión.

Encabezado largo

En los siguientes mensajes, establezca el campo ver (versión) en el encabezado largo a 3 o 4, para indicar MLKEM-512 o MLKEM-768.

En los siguientes mensajes, establece el campo ver (versión) en la cabecera larga a 2, como de costumbre, incluso si se admite MLKEM-512 o MLKEM-768. Las implementaciones también pueden establecer el valor en 3 o 4, si el otro extremo lo admite, pero no es necesario. Las implementaciones deben aceptar cualquier valor entre 2 y 4.

• (0) Solicitud de sesión
• (1) Sesión creada
• (9) Reintentar
• (10) Solicitud de token
• (11) Hole Punch

Discusión: Establecer el campo de versión en 3 o 4 puede no ser estrictamente necesario para todos los tipos de mensajes, pero hacerlo facilita la detección temprana de fallos en conexiones post-cuánticas no compatibles. Los mensajes Token Request y Retry (tipos 9 y 10) deberían tener versiones 3/4 por coherencia. Los mensajes Hole Punch (tipo 11) pueden no requerir este tratamiento, pero seguiremos el mismo patrón por uniformidad. Los mensajes Peer Test (tipo 7) están fuera de sesión y no indican la intención de iniciar una sesión.

• (7) Prueba de par (mensajes fuera de sesión 5-7)

Antes del cifrado de encabezado:

Antes del cifrado de cabecera:

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

Encabezado corto

sin cambios

SessionRequest (Tipo 0)

Cambio de KDF para protección contra suplantación: Para abordar los problemas planteados en la Propuesta 165 [Prop165]_, pero con una solución diferente, modificamos el KDF para la solicitud de sesión (Session Request). Esto aplica únicamente a las sesiones PQ. El KDF para las sesiones no PQ permanece sin cambios.

Cambio de KDF para protección contra suplantación: Para abordar los problemas planteados en la Propuesta 165 [Prop165]_, pero con una solución diferente, modificamos la KDF para la Solicitud de Sesión. Esto solo aplica para sesiones PQ. La KDF para sesiones no PQ permanece sin cambios.

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

  ...

Contenido sin procesar:

  +----+----+----+----+----+----+----+----+
  |  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 = 1                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Datos sin cifrar (etiqueta de autenticación Poly1305 no 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      |
  +----+----+----+----+----+----+----+----+

Tamaños, sin incluir la sobrecarga IP:

MTU mínimo para MLKEM768_X25519: 1318 para IPv4 y 1338 para IPv6. Ver más abajo.

SessionCreated (Tipo 1)

Cambios: el SSU2 actual contiene solo la carga útil en una única sección ChaCha. Con ML-KEM, habrá una nueva sección ChaCha antes de la carga útil, que contendrá el cifrado PQ cifrado.

Contenido sin procesar:

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

Datos sin cifrar (etiqueta de autenticación Poly1305 no 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     |
  +----+----+----+----+----+----+----+----+

Tamaños, sin incluir la sobrecarga IP:

MTU mínimo para MLKEM768_X25519: 1318 para IPv4 y 1338 para IPv6. Ver más abajo.

SessionConfirmed (Tipo 2)

sin cambios

KDF para la fase de datos

sin cambios

Relay y Prueba de Pares

Los siguientes bloques contienen campos de versión. Permanecerán en la versión 2 (por compatibilidad con un Bob no-PQ) y no cambiarán a la versión 3/4 para PQ.

• Relay Request (Solicitud de retransmisión)
• Relay Response (Respuesta de retransmisión)
• Relay Intro (Introducción de retransmisión)
• Peer Test (Prueba de par)

En todos los casos, utilice el nombre de transporte SSU2 como de costumbre. MLKEM-1024 no es compatible.

Direcciones publicadas

Usar la misma dirección/puerto que la variante sin PQ y sin firewall. Se admiten una o ambas variantes PQ. En la dirección del router, publicar v=2 (como de costumbre) y el nuevo parámetro pq=[3|4|3,4|4,3] para indicar MLKEM 512/768/ambos. Los routers con un MTU inferior al mínimo especificado a continuación no deben publicar un parámetro “pq” que contenga “4”. Publicar 4,3 para indicar preferencia por MLKEM-768, o 3,4 para indicar preferencia por MLKEM-512. La versión real queda a criterio del iniciador y la preferencia puede no ser respetada. Los routers con un MTU inferior al mínimo especificado a continuación no deben conectarse usando MLKEM768. Los routers más antiguos ignorarán el parámetro pq y se conectarán sin PQ como de costumbre.

Diferente dirección/puerto que el no-PQ, o solo-PQ, no-firewall NO está soportado. Esto no se implementará hasta que SSU2 no-PQ sea desactivado, dentro de varios años. Cuando el no-PQ sea desactivado, una o ambas variantes PQ estarán soportadas. En la dirección del router, publicar v=[3|4|3,4|4,3] para indicar MLKEM 512/768/ambos. Los routers más antiguos verificarán el parámetro v y omitirán esta dirección como no soportada.

Direcciones con firewall (sin IP publicada): En la dirección del router, publicar v=2 (como de costumbre). El parámetro pq DEBE publicarse en las direcciones con firewall para admitir el relay (retransmisión).

Direcciones detrás de firewall (sin IP publicada): En la dirección del router, publicar v=2 (como es habitual). El parámetro pq DEBE publicarse en direcciones detrás de firewall, para permitir el reenvío (relay).

En la especificación actual, los mensajes 1 y 2 están definidos para tener una cantidad “razonable” de relleno, con un rango recomendado de 0 a 31 bytes y sin un máximo especificado.

MTU

TODO: ¿Existe una forma más eficiente de definir la firma/verificación para evitar copiar la firma?

Streaming

TODO

Archivos SU3

La sección 8.1 del borrador IETF prohíbe HashML-DSA en certificados X.509 y no asigna OIDs para HashML-DSA, debido a la complejidad de implementación y la reducción de seguridad que implica.

Para firmas exclusivamente PQ de archivos SU3, utilice los OIDs definidos en el borrador IETF de las variantes sin pre-hash para los certificados. No definimos firmas híbridas de archivos SU3, porque podríamos tener que aplicar hash a los archivos dos veces (aunque HashML-DSA y X2559 utilizan la misma función hash SHA512). Además, concatenar dos claves y firmas en un certificado X.509 sería completamente no estándar.

Tenga en cuenta que no permitimos la firma Ed25519 de archivos SU3 y, aunque hemos definido la firma Ed25519ph, nunca hemos acordado un OID para ella ni la hemos utilizado.

Los tipos de firma normales no están permitidos para los archivos SU3; utilice las variantes ph (prehash).

El nuevo tamaño máximo de Destination será de 2599 bytes (3468 en base 64).

Otras Especificaciones

Actualizar otros documentos que ofrecen orientación sobre los tamaños de Destination, incluyendo:

Aumento de tamaño (bytes):

• SAMv3
• Bittorrent
• Guías para desarrolladores
• Nomenclatura / libreta de direcciones / servidores de salto
• Otros documentos

Análisis de Sobrecarga

Intercambio de claves

Velocidad:

Resultados preliminares de las pruebas en Java:

Firmas

Tamaños típicos de clave, firma, RIdent y Dest, o incrementos de tamaño (Ed25519 incluido como referencia) asumiendo el tipo de cifrado X25519 para RIs. Se indica el tamaño añadido para un Router Info, LeaseSet, datagramas respondibles y cada uno de los dos paquetes de streaming (SYN y SYN ACK). Los Destinations y Leasesets actuales contienen relleno repetido y son compresibles en tránsito. Los nuevos tipos no contienen relleno y no serán compresibles, lo que resulta en un incremento de tamaño en tránsito significativamente mayor. Véase la sección de diseño más arriba.

Tamaños típicos de clave, firma, RIdent y Dest o aumentos de tamaño (Ed25519 incluido como referencia), suponiendo el tipo de cifrado X25519 para RIs. Tamaño adicional para una Información de Router, LeaseSet, datagramas con respuesta y cada uno de los dos paquetes de transmisión (SYN y SYN ACK) listados. Las Destinaciones y LeaseSets actuales contienen relleno repetido y son compresibles durante la transmisión. Los nuevos tipos no contienen relleno y no serán compresibles, lo que resulta en un aumento de tamaño mucho mayor durante la transmisión. Ver sección de diseño anterior.

Resultados preliminares de las pruebas en Java:

Análisis de seguridad

Las categorías de seguridad del NIST se resumen en la presentación del NIST , diapositiva 10. Criterios preliminares: Nuestra categoría de seguridad NIST mínima debería ser 2 para protocolos híbridos y 3 para los exclusivamente poscuánticos (PQ-only).

Handshakes

Categorías de seguridad NIST FIPS 203 :

Esta propuesta define tanto tipos de firma híbrida como exclusivamente PQ (post-cuántica). El híbrido MLDSA44 es preferible al MLDSA65 exclusivamente PQ. Los tamaños de claves y firmas para MLDSA65 y MLDSA87 son probablemente demasiado grandes para nosotros, al menos en un principio.

Firmas

Categorías de seguridad NIST FIPS 204 :

Si bien definiremos e implementaremos 3 tipos de cifrado y 9 tipos de firma, planeamos medir el rendimiento durante el desarrollo y analizar más a fondo los efectos del aumento en los tamaños de las estructuras. También continuaremos investigando y monitoreando los avances en otros proyectos y protocolos.

Preferencias de tipo

Tras el desarrollo y las pruebas, se establecerá un tipo preferido o predeterminado para cada caso de uso. La selección requerirá equilibrar el ancho de banda, la CPU y el nivel de seguridad estimado. No todos los tipos pueden ser adecuados o estar permitidos para todos los casos de uso.

Las preferencias preliminares son las siguientes, sujetas a cambios:

Cifrado: MLKEM768_X25519

Firmas: MLDSA44_EdDSA_SHA512_Ed25519

Las restricciones preliminares son las siguientes, sujetas a cambios:

Firmas: MLDSA87 y su variante híbrida probablemente son demasiado grandes; MLDSA65 y su variante híbrida pueden ser demasiado grandes

Las bibliotecas Bouncycastle, BoringSSL y WolfSSL ya son compatibles con MLKEM y MLDSA. El soporte de OpenSSL estará disponible en su versión 3.5 el 8 de abril de 2025 OpenSSL .

Notas de implementación

Soporte de Biblioteca

La biblioteca Noise de southernstorm.com adaptada por Java I2P contenía soporte preliminar para handshakes híbridos, pero lo eliminamos por no utilizarse; tendremos que volver a añadirlo y actualizarlo para que coincida con la especificación Noise HFS .

Utilizaremos la variante de firma “hedged” (con aleatorización) en lugar de la variante “determinista”, tal como se define en la sección 3.4 de FIPS 204 . Esto garantiza que cada firma sea diferente, incluso cuando se aplica sobre los mismos datos, y proporciona protección adicional contra ataques de canal lateral. Si bien FIPS 204 especifica que la variante “hedged” es la predeterminada, esto puede o no ser así en las distintas bibliotecas. Los implementadores deben asegurarse de que se utilice la variante “hedged” para la firma.

Variantes de Firma

Utilizamos el proceso de firma estándar (denominado Pure ML-DSA Signature Generation) que codifica el mensaje internamente como 0x00 || len(ctx) || ctx || message, donde ctx es un valor opcional de tamaño 0x00..0xFF. No se utiliza ningún contexto opcional. len(ctx) == 0. Este proceso está definido en FIPS 204 Algoritmo 2, paso 10 y Algoritmo 3, paso 5. Nótese que algunos vectores de prueba publicados pueden requerir configurar un modo en el que el mensaje no sea codificado.

El aumento de tamaño resultará en una mayor fragmentación de túneles para los almacenes en NetDB, los handshakes de streaming y otros mensajes. Verifique los cambios en rendimiento y fiabilidad.

Confiabilidad

Encuentra y verifica cualquier código que limite el tamaño en bytes de los router infos y leasesets.

Tamaños de Estructura

Revisar y posiblemente reducir el máximo de LS/RI almacenados en RAM o en disco, para limitar el aumento del almacenamiento. ¿Aumentar los requisitos mínimos de ancho de banda para los floodfills?

NetDB

La clasificación/detección automática de múltiples protocolos en los mismos tunnels debería ser posible basándose en una verificación de longitud del mensaje 1 (New Session Message). Usando MLKEM512_X25519 como ejemplo, la longitud del mensaje 1 es 816 bytes mayor que la del protocolo ratchet actual, y el tamaño mínimo del mensaje 1 (con solo un payload DateTime incluido) es de 919 bytes. La mayoría de los tamaños del mensaje 1 con el ratchet actual tienen un payload inferior a 816 bytes, por lo que pueden clasificarse como ratchet no híbrido. Los mensajes de gran tamaño probablemente sean POSTs, que son poco frecuentes.

Ratchet

Túneles Compartidos

Por lo tanto, la estrategia recomendada es:

Esto debería permitirnos soportar eficientemente el ratchet estándar y el ratchet híbrido en el mismo destino, tal como anteriormente soportábamos ElGamal y ratchet en el mismo destino. Por lo tanto, podemos migrar al protocolo híbrido MLKEM mucho más rápidamente que si no pudiéramos soportar protocolos duales para el mismo destino, ya que podemos añadir soporte MLKEM a los destinos existentes.

• Si el mensaje 1 tiene menos de 919 bytes, corresponde al protocolo ratchet actual.
• Si el mensaje 1 tiene 919 bytes o más, probablemente sea MLKEM512_X25519. Intentar primero con MLKEM512_X25519 y, si falla, intentar con el protocolo ratchet actual.

Las combinaciones compatibles requeridas son:

Las siguientes combinaciones pueden ser complejas y NO es obligatorio que sean compatibles, aunque podrían serlo dependiendo de la implementación:

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

Es posible que no intentemos admitir múltiples algoritmos MLKEM (por ejemplo, MLKEM512_X25519 y MLKEM_768_X25519) en el mismo destino. Selecciona solo uno; sin embargo, eso depende de que elijamos una variante MLKEM preferida, para que los túneles de cliente HTTP puedan usar una. Depende de la implementación.

• Más de un MLKEM
• ElG + uno o más MLKEM
• X25519 + uno o más MLKEM
• ElG + X25519 + uno o más MLKEM

PODEMOS intentar soportar tres algoritmos (por ejemplo X25519, MLKEM512_X25519 y MLKEM769_X25519) en el mismo destino. La clasificación y la estrategia de reintento pueden resultar demasiado complejas. La configuración y la interfaz de usuario de configuración pueden ser demasiado complejas. Depende de la implementación.

Probablemente NO intentaremos dar soporte a ElGamal y a los algoritmos híbridos en el mismo destino. ElGamal está obsoleto, y ElGamal + híbrido sin X25519 no tiene mucho sentido. Además, tanto los mensajes de nueva sesión de ElGamal como los híbridos son de gran tamaño, por lo que las estrategias de clasificación frecuentemente tendrían que intentar ambas descifraciones, lo cual resultaría ineficiente. Depende de la implementación.

Los clientes pueden usar las mismas claves estáticas X25519 o claves diferentes para los protocolos X25519 e híbrido en los mismos tunnels, según la implementación.

La especificación ECIES permite Garlic Messages en el payload del New Session Message, lo que posibilita la entrega 0-RTT del paquete de streaming inicial, generalmente un HTTP GET, junto con el leaseSet del cliente. Sin embargo, el payload del New Session Message no tiene forward secrecy (secreto hacia adelante). Dado que esta propuesta enfatiza un forward secrecy mejorado para el ratchet, las implementaciones pueden o deberían diferir la inclusión del payload de streaming, o del mensaje de streaming completo, hasta el primer Existing Session Message. Esto tendría como costo la entrega 0-RTT. Las estrategias también pueden depender del tipo de tráfico o del tipo de tunnel, o bien de si se trata de un GET vs. POST, por ejemplo. Depende de la implementación.

Secreto hacia adelante

MLKEM, MLDSA, o ambos en el mismo destino, aumentarán drásticamente el tamaño del New Session Message, como se describe anteriormente. Esto puede reducir significativamente la fiabilidad de la entrega del New Session Message a través de tunnels, donde deben fragmentarse en múltiples mensajes de tunnel de 1024 bytes. El éxito de la entrega es proporcional al número exponencial de fragmentos. Las implementaciones pueden utilizar diversas estrategias para limitar el tamaño del mensaje, a expensas de la entrega 0-RTT. Dependiente de la implementación.

Tamaño de nueva sesión

Establecemos el bit más significativo de la clave efímera (key[31] & 0x80) en la solicitud de sesión para indicar que se trata de una conexión híbrida. Esto nos permite ejecutar tanto NTCP estándar como NTCP híbrido en el mismo puerto. Solo se admitirá una variante híbrida, que se anunciará en la dirección del router. Por ejemplo, v=2,3 o v=2,4 o v=2,5.

NTCP2

Como Alice, para una conexión PQ, antes de la ofuscación, establece X[31] |= 0x80. Esto convierte a X en una clave pública X25519 no válida. Después de la ofuscación, AES-CBC la aleatorizará. El MSB de X será aleatorio después de la ofuscación.

Ofuscación

Como Bob, verificar si (X[31] & 0x80) != 0 después de la des-ofuscación. Si es así, se trata de una conexión PQ.

La versión mínima del router requerida para NTCP2-PQ está por determinar.

La versión mínima del router requerida para NTCP2-PQ está por determinarse (TBD).

Nota: Los códigos de tipo son solo para uso interno. Los routers permanecerán como tipo 4, y el soporte se indicará en las direcciones del router.

SSU2

Verificar que SSU2 pueda manejar un RI firmado con MLDSA fragmentado en múltiples paquetes (¿6-8?).

Compruebe y verifique que SSU2 pueda manejar RI firmado con MLDSA fragmentado en múltiples paquetes (6-8?).

Nota: Los códigos de tipo son solo para uso interno. Los routers permanecerán como tipo 4, y el soporte se indicará en las direcciones del router.

Compatibilidad del Router

Nombres de Transporte

Tenemos varias alternativas a considerar:

Tipos de Enc. del Router

No recomendado. Utilice únicamente los nuevos transportes listados anteriormente que coincidan con el tipo de router. Los routers más antiguos no pueden conectarse, construir tunnels a través de, ni enviar mensajes de netDb. Requeriría varios ciclos de versiones para depurar y garantizar el soporte antes de habilitarlo por defecto. Podría extender el despliegue en un año o más en comparación con las alternativas que se describen a continuación.

Routers de Tipo 5/6/7

Recomendado. Dado que PQ no afecta a la clave estática X25519 ni a los protocolos de handshake N, podríamos dejar los routers como tipo 4 y simplemente anunciar nuevos transportes. Los routers más antiguos aún podrían conectarse, construir tunnels a través de ellos o enviarles mensajes netdb.

Routers de Tipo 4

MLKEM-768 es el recomendado para Ratchet, NTCP2 y SSU2, como el mejor equilibrio entre seguridad y longitud de clave.

Recomendaciones

Los routers más antiguos verifican los RIs y, por lo tanto, no pueden conectarse, construir tunnels a través de ellos ni enviarles mensajes netdb. Llevaría varios ciclos de lanzamiento depurar y garantizar el soporte antes de habilitarlo por defecto. Presentaría los mismos problemas que el despliegue de los tipos de cifrado 5/6/7; podría extender el despliegue un año o más en comparación con la alternativa de despliegue del tipo de cifrado 4 mencionada anteriormente.

Tipos de firma del router

Routers de tipo 12-17

Sin alternativas.

Estas pueden estar presentes en el LS con claves X25519 de tipo 4 más antiguas. Los routers más antiguos ignorarán las claves desconocidas.

Tipos de Cifrado LS

Claves LS de tipo 5-7

Los destinos pueden admitir múltiples tipos de clave, pero solo mediante intentos de descifrado del mensaje 1 con cada clave. La sobrecarga puede mitigarse manteniendo un recuento de descifrados exitosos para cada clave e intentando primero con la clave más utilizada. Java I2P utiliza esta estrategia para ElGamal+X25519 en el mismo destino.

Los routers verifican las firmas de los leaseSet y, por lo tanto, no pueden conectarse ni recibir leaseSets para destinos de tipo 12-17. Se necesitarían varios ciclos de lanzamiento para depurar y garantizar el soporte antes de habilitarlo por defecto.

Tipos de Firma de Destino

Destinos de tipo 12-17

Los routers verifican las firmas de los leaseset y por lo tanto no pueden conectarse, ni recibir leasesets para destinos de tipo 12-17. Se necesitarían varios ciclos de lanzamiento para depurar y garantizar el soporte antes de habilitarlo por defecto.

Estas pueden estar presentes en el LS con claves X25519 de tipo 4 más antiguas. Los routers más antiguos ignorarán las claves desconocidas.

Prioridades y Despliegue

El modelo de amenaza PQ (poscuántica) más preocupante en este momento es el almacenamiento de tráfico hoy, para descifrarlo muchos años en el futuro (secreto hacia adelante). Un enfoque híbrido protegería contra eso.

El modelo de amenaza PQ de romper las claves de autenticación en un período de tiempo razonable (digamos unos pocos meses) y luego suplantar la autenticación o descifrar en tiempo casi real, ¿está mucho más lejos? Y es en ese momento cuando querríamos migrar a claves estáticas PQC.

Por lo tanto, el modelo de amenaza PQ (post-cuántica) más temprano es el OBEP/IBGW almacenando tráfico para descifrado posterior. Deberíamos implementar el ratchet híbrido primero.

Ratchet es la prioridad más alta. Los transportes son los siguientes. Las firmas tienen la prioridad más baja.

El despliegue de firmas también llegará un año o más después que el despliegue del cifrado, ya que no es posible ninguna compatibilidad con versiones anteriores. Además, la adopción de MLDSA en la industria será estandarizada por el CA/Browser Forum y las Autoridades de Certificación. Las CAs necesitan primero soporte de módulo de seguridad de hardware (HSM), que actualmente no está disponible CA/Browser Forum . Esperamos que el CA/Browser Forum impulse las decisiones sobre opciones de parámetros específicos, incluyendo si se deben admitir o requerir firmas compuestas borrador IETF .

La implementación de la firma también ocurrirá un año o más tarde que la implementación del cifrado, porque no es posible la compatibilidad hacia atrás.

El trabajo sobre el soporte de firmas MLDSA en I2P está en pausa hasta finales de 2027 o 2028, a la espera de que los organismos de estándares seleccionen algoritmos, posiblemente reduzcan el tamaño de las claves y/o de las firmas, y promuevan la adopción industrial. Véase CABFORUM y PLANTS . Además, la adopción de MLDSA en la industria será estandarizada por el CA/Browser Forum y las Autoridades de Certificación (CA). Las CA necesitan primero soporte de módulos de seguridad hardware (HSM), que actualmente no está disponible CA/Browser Forum . Esperamos que el CA/Browser Forum impulse las decisiones sobre opciones específicas de parámetros, incluyendo si apoyar o requerir firmas compuestas borrador de IETF .

Migración

Si no podemos admitir tanto los protocolos de trinquete antiguos como los nuevos en los mismos túneles, la migración será mucho más difícil.

Deberíamos poder simplemente intentar uno y luego el otro, como hicimos con X25519, para comprobarlo.

Problemas

• Selección de Hash para Noise - ¿quedarse con SHA256 o actualizar? SHA256 debería ser seguro durante otros 20-30 años, no está amenazado por PQ (computación cuántica post-cuántica), Ver presentación del NIST y presentación del NCCOE . Si SHA256 se rompe, tendremos problemas peores (netdb).
• NTCP2 puerto separado, dirección de router separada
• SSU2 relay / prueba de pares
• Campo de versión SSU2
• Versión de dirección de router SSU2

Referencias

• 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