Protocolos de Criptografía Post-Cuántica

Estado

Descripción general

Aunque la investigación y competencia por criptografía post-cuántica (PQ) adecuada ha estado en curso durante una década, las opciones no se han vuelto claras hasta hace poco.

Comenzamos a analizar las implicaciones de la criptografía PQ en 2022 zzz.i2p .

Los estándares TLS agregaron soporte para cifrado híbrido en los últimos dos años y ahora se usa para una porción significativa del tráfico cifrado en internet debido al soporte en Chrome y Firefox Cloudflare .

NIST recientemente finalizó y publicó los algoritmos recomendados para la criptografía post-cuántica NIST . Varias bibliotecas de criptografía comunes ahora soportan los estándares NIST o lanzarán soporte en un futuro próximo.

Tanto Cloudflare como NIST recomiendan que la migración comience inmediatamente. Consulta también las preguntas frecuentes sobre PQ de 2022 de la NSA . I2P debería ser líder en seguridad y criptografía. Ahora es el momento de implementar los algoritmos recomendados. Utilizando nuestro sistema flexible de tipos de cripto y tipos de firma, añadiremos tipos para cripto híbrida, y para firmas PQ e híbridas.

Objetivos

• Seleccionar algoritmos resistentes a PQ
• Añadir algoritmos solo PQ e híbridos a los protocolos I2P donde sea apropiado
• Definir múltiples variantes
• Seleccionar las mejores variantes después de implementación, pruebas, análisis e investigación
• Añadir soporte de manera incremental y con compatibilidad hacia atrás

No Objetivos

• No cambiar los protocolos de cifrado unidireccional (Noise N)
• No abandonar SHA256, no está amenazado a corto plazo por PQ
• No seleccionar las variantes preferidas finales en este momento

Modelo de Amenazas

• Routers en el OBEP o IBGW, posiblemente en colusión, almacenando mensajes garlic para descifrado posterior (forward secrecy)
• Observadores de red almacenando mensajes de transporte para descifrado posterior (forward secrecy)
• 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 será desde finales de 2025 hasta mediados de 2027. Consulta la sección de Prioridades y Despliegue a continuación para más detalles.

Diseño

Soportaremos 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 y por lo tanto no es adecuado para el cifrado híbrido.

Así que solo admitiremos cifrado híbrido, para NTCP2, SSU2 y Ratchet. Definiremos las tres variantes ML-KEM como 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:

Usaremos la variante de firma “hedged” o aleatorizada, no la variante “determinística”, como se define en FIPS 204 sección 3.4. Esto garantiza que cada firma sea diferente, incluso cuando se aplique sobre los mismos datos, y proporciona protección adicional contra ataques de canal lateral. Consulte la sección de notas de implementación a continuación para obtener detalles adicionales sobre las opciones del algoritmo incluyendo codificación y contexto.

Los nuevos tipos de firma son:

La sobrecarga será sustancial. Los tamaños típicos de identidad de destino y router Ed25519 son de 391 bytes. Estos aumentarán de 3.5x a 6.8x dependiendo del algoritmo. Las firmas Ed25519 son de 64 bytes. Estas aumentarán de 38x a 76x dependiendo del algoritmo. Los RouterInfo firmados típicos, leaseSet, datagramas con respuesta y mensajes de streaming firmados son de aproximadamente 1KB. Estos aumentarán de 3x a 8x dependiendo del algoritmo.

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

Combinaciones Legales

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

Para RouterIdentities, el tipo de cifrado ElGamal está obsoleto. Los nuevos tipos de firma solo son compatibles con 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 tipo 4.

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 Usado solo para SHAKE128
• SHA3-256 (anteriormente Keccak-512) FIPS 202
• SHAKE128 y SHAKE256 (extensiones XOF para SHA3-128 y SHA3-256) FIPS 202

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

Ten en cuenta que la biblioteca Java bouncycastle soporta todo lo anterior. El soporte de la biblioteca C++ está en OpenSSL 3.5 OpenSSL .

Alternativas

No daremos soporte a FIPS 205 (Sphincs+), es mucho más lento y más grande que ML-DSA. No daremos soporte al próximo FIPS206 (Falcon), aún no está estandarizado. No daremos soporte a NTRU u otros candidatos PQ que no fueron estandarizados por NIST.

Rosenpass

Existe alguna investigación paper sobre la adaptación de Wireguard (IK) para criptografía PQ pura, pero hay varias preguntas abiertas en ese documento. Posteriormente, este enfoque fue implementado como Rosenpass Rosenpass whitepaper para PQ Wireguard.

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

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

• No podemos hacer 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

Hay mucha información valiosa en el documento técnico, y lo revisaremos en busca de ideas e inspiración. PENDIENTE.

Especificación

Estructuras Comunes

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

PublicKey

Los nuevos tipos de Clave Pública son:

Las claves MLKEM*_CT no son realmente claves públicas, son el “texto cifrado” enviado de Bob a Alice en el handshake de Noise. Se listan aquí para completitud.

PrivateKey

Los nuevos tipos de clave privada son:

SigningPublicKey

Los nuevos tipos de Signing Public Key son:

SigningPrivateKey

Los nuevos tipos de Clave Privada de Firma son:

Firma

Los nuevos tipos de Signature son:

Certificados de Clave

Los nuevos tipos de Signing Public Key son:

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

Tamaños de destino

Aquí están las longitudes para los nuevos tipos de Destination. El tipo Enc para todos es NONE (tipo 255) y la longitud de la clave de cifrado se trata como 0. Toda la sección de 384 bytes se usa 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 mantuvimos la clave ElGamal de 256 bytes en el destination aunque no se usara.

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

Aquí están las longitudes para los nuevos tipos de Destination. El tipo de cifrado para todos es X25519 (tipo 4). Toda la sección de 352 bytes después de la clave pública X28819 se usa 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 Handshake

Los handshakes utilizan patrones de handshake del Protocolo Noise .

Se utiliza la siguiente correspondencia 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 el secreto perfecto hacia adelante híbrido (hfs) se especifican según la especificación Noise HFS sección 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)

El patrón e1 se define de la siguiente manera, como se especifica en la especificación Noise HFS sección 4:

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 se especifica en la especificación Noise HFS sección 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 de Handshake Noise

Problemas

• ¿Deberíamos cambiar la función hash del handshake? Ver comparación . SHA256 no es vulnerable a PQ, pero si queremos actualizar nuestra función hash, ahora es el momento, mientras estamos cambiando otras cosas. La propuesta actual de SSH del IETF borrador IETF es usar MLKEM768 con SHA256, y MLKEM1024 con SHA384. Esa propuesta incluye una discusión de las consideraciones de seguridad.
• ¿Deberíamos dejar de enviar datos de ratchet 0-RTT (distintos del LS)?
• ¿Deberíamos cambiar el ratchet de IK a XK si no enviamos datos 0-RTT?

Resumen

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

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

El segundo mensaje, de Bob a Alice, contiene ekem1, el texto cifrado, antes de la carga útil del mensaje. Esto se trata como una clave estática adicional; llama a EncryptAndHash() en él (como Bob) o DecryptAndHash() (como Alice). Luego, calcula el kem_shared_key y llama a MixKey(kem_shared_key). Después procesa la carga útil del mensaje como de costumbre.

Operaciones ML-KEM Definidas

Definimos las siguientes funciones correspondientes a los bloques de construcción criptográficos utilizados según se define 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 la encap_key como el texto cifrado están encriptados dentro de bloques ChaCha/Poly en los mensajes 1 y 2 del handshake Noise. Serán descifrados como parte del proceso de handshake.

El kem_shared_key se mezcla en la clave de encadenamiento con MixHash(). Consulta los detalles a continuación.

KDF de Alice para el Mensaje 1

Para XK: Después del patrón de mensaje ’es’ y antes de la carga útil, agregar:

O

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

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 Mensaje 1

Para XK: Después del patrón de mensaje ’es’ y antes de la carga útil, agregar:

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

Bob KDF para Mensaje 2

Para XK: Después del patrón de mensaje ’ee’ y antes de la carga útil, 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.

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), agregar:

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.

KDF para Mensaje 3 (solo XK)

sin cambios

KDF para split()

sin cambios

Ratchet

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

Identificadores de ruido

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

1b) Nuevo formato de sesión (con vinculación)

Cambios: El ratchet actual contenía la clave estática en la primera sección ChaCha, y la 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 la carga útil.

Formato encriptado:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   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 una carga útil vacía para la primera sección ChaCha, y la carga útil 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 una carga útil vacía. La tercera sección contiene la carga útil.

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

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

Identificadores de ruido

• “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 solo las opciones en la sección ChaCha. Con ML-KEM, la sección ChaCha también contendrá la clave pública PQ encriptada.

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

Para que PQ y NTCP2 no-PQ puedan ser soportados en la misma dirección de router y puerto, utilizamos el bit más significativo del valor X (clave pública efímera X25519) para marcar que es una conexión PQ. Este bit siempre está desactivado para conexiones no-PQ.

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

Para Bob, después de la de-ofuscación AES de X, probar X[31] & 0x80. Si el bit está establecido, borrarlo con X[31] &= 0x7f, y descifrar vía Noise como una conexión PQ. Si el bit está limpio, descifrar vía Noise como una conexión no-PQ como de costumbre.

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

Para obtener información adicional, consulta la sección Direcciones Publicadas más abajo.

Contenidos sin procesar:

  +----+----+----+----+----+----+----+----+
  |        MS bit set to 1 and then       |
  +        obfuscated with RH_B           +
  |       AES-CBC-256 encrypted X         |
  +             (32 bytes)                +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaChaPoly frame (MLKEM)            |
  +      (see table below for length)     +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  ~   n = 0                               ~
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaChaPoly frame (options)          |
  +         32 bytes                      +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  +----+----+----+----+----+----+----+----+
  |     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

Contenido sin procesar:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +        obfuscated with RH_B           +
  |       AES-CBC-256 encrypted Y         |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaChaPoly frame (MLKEM)            |
  +   Encrypted and authenticated data    +
  -      (see table below for length)     -
  +   k defined in KDF for message 2      +
  |   n = 0; see KDF for associated data  |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaChaPoly frame (options)          |
  +   Encrypted and authenticated data    +
  -           32 bytes                    -
  +   k defined in KDF for message 2      +
  |   n = 0; see KDF for associated data  |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     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 Claves (KDF) (para fase de datos)

Sin cambios

Direcciones Publicadas

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

Usa la misma dirección/puerto que sin PQ, sin firewall. Solo se admite una variante PQ. En la dirección del router, publica v=2 (como siempre) y el nuevo parámetro pq=[3|4|5] para indicar MLKEM 512/768/1024. Alice establece el MSB de la clave efímera (key[31] & 0x80) en la solicitud de sesión para indicar que esta es una conexión híbrida. Ver arriba. Los routers más antiguos ignorarán el parámetro pq y se conectarán sin PQ como siempre.

Dirección/puerto diferente como no-PQ, o solo-PQ, sin firewall NO está soportado. Esto no se implementará hasta que NTCP2 no-PQ esté deshabilitado, dentro de varios años. Cuando no-PQ esté deshabilitado, múltiples variantes PQ pueden ser soportadas, pero solo una por dirección. En la dirección del router, 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 como no soportada.

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

Alice puede conectarse a un Bob PQ usando la variante PQ que Bob publica, independientemente de si Alice anuncia soporte pq en su información de router, o si anuncia la misma variante.

Relleno Máximo

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-31 bytes, y sin máximo especificado.

Java I2P implementa un máximo de 256 bytes de relleno para conexiones que no son PQ, sin embargo esto no estaba documentado previamente.

Usa el tamaño de mensaje definido como el relleno máximo, es decir, el relleno máximo duplicará el tamaño del mensaje, de la siguiente manera:

SSU2

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

Identificadores de ruido

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

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

Encabezado Largo

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

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

• (0) Solicitud de Sesión
• (1) Sesión Creada
• (9) Reintentar
• (10) Solicitud de Token
• (11) Perforación de Agujero

En los siguientes mensajes, establece el campo ver (versión) en el encabezado largo a 2, como es habitual, incluso si MLKEM-512 o MLKEM-768 es compatible. Las implementaciones también pueden establecer el valor a 3 o 4, si el otro extremo lo admite, pero esto no es necesario. Las implementaciones deben aceptar cualquier valor 2-4.

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

Discusión: Establecer el campo de versión a 3 o 4 puede no ser estrictamente necesario para todos los tipos de mensaje, pero hacerlo ayuda a la detección temprana de fallos para conexiones post-cuánticas no compatibles. Token Request y Retry (tipos 9 y 10) deberían tener versiones 3/4 por consistencia. 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 intención de iniciar una sesión.

Antes del cifrado de cabeceras:

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

Cambios: El SSU2 actual contiene solo los datos del bloque en la sección ChaCha. Con ML-KEM, la sección ChaCha también contendrá la clave pública PQ cifrada.

Cambio de KDF para Protección contra Spoofing: Para abordar los problemas planteados en la Propuesta 165 [Prop165]_, pero con una solución diferente, modificamos el KDF para Session Request. Esto es solo para sesiones PQ. El 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          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (payload)   |
  +          (length varies)              +
  |  k defined in KDF for Session Request |
  +  n = 0                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Datos no cifrados (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: Aproximadamente 1316 para IPv4 y 1336 para IPv6.

SessionCreated (Tipo 1)

Cambios: El SSU2 actual contiene solo los datos del bloque en la sección ChaCha. Con ML-KEM, la sección ChaCha también contendrá la clave pública PQ cifrada.

Contenidos en 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 data (MLKEM)               |
  +   Encrypted and authenticated data    +
  |  length varies                        |
  +  k defined in KDF for Session Created +
  |  n = 0; see KDF for associated data   |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 data (payload)             |
  +   Encrypted and authenticated data    +
  |  length varies                        |
  +  k defined in KDF for Session Created +
  |  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 de IP:

MTU mínimo para MLKEM768_X25519: Aproximadamente 1316 para IPv4 y 1336 para IPv6.

SessionConfirmed (Tipo 2)

sin cambios

KDF para fase de datos

sin cambios

Relay y Prueba de Pares

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

• Solicitud de Relay
• Respuesta de Relay
• Introducción de Relay
• Prueba de Par

Firmas PQ: Los bloques de retransmisión (Relay), bloques de prueba de pares (Peer Test) y mensajes de prueba de pares contienen firmas. Desafortunadamente, las firmas PQ son más grandes que la MTU. Actualmente no existe un mecanismo para fragmentar los bloques de retransmisión o prueba de pares o mensajes a través de múltiples paquetes UDP. El protocolo debe extenderse para soportar fragmentación. Esto se hará en una propuesta separada por determinar. Hasta que eso se complete, Relay y Peer Test no serán compatibles.

Direcciones Publicadas

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

Usa la misma dirección/puerto que la versión no-PQ, sin firewall. Se admiten una o ambas variantes PQ. En la dirección del router, publica v=2 (como es habitual) y el nuevo parámetro pq=[3|4|3,4] para indicar MLKEM 512/768/ambos. Los routers más antiguos ignorarán el parámetro pq y se conectarán de forma no-pq como es habitual.

Dirección/puerto diferente como no-PQ, o solo-PQ, sin firewall NO está soportado. Esto no se implementará hasta que SSU2 no-PQ sea deshabilitado, dentro de varios años. Cuando no-PQ sea deshabilitado, una o ambas variantes PQ son soportadas. En la dirección del router, publicar v=[3|4|3,4] 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 es habitual). El parámetro pq DEBE ser publicado en direcciones con firewall, para soportar relay.

Alice puede conectarse a un Bob PQ usando la variante PQ que Bob publica, sin importar si Alice anuncia soporte pq en su información de router, o si anuncia la misma variante.

MTU

Ten cuidado de no exceder la MTU con MLKEM768. La MTU mínima para SSU2 es 1280, que es el tamaño del mensaje 1 sin relleno. No incluyas relleno en el mensaje 1 si la MTU de Alice o Bob es 1280.

Problemas

Podríamos usar internamente el campo de versión y usar 3 para MLKEM512 y 4 para MLKEM768.

Para los mensajes 1 y 2, MLKEM768 aumentaría los tamaños de paquete más allá del MTU mínimo de 1280. Probablemente simplemente no lo soportaría para esa conexión si el MTU fuera demasiado bajo.

Para los mensajes 1 y 2, MLKEM1024 aumentaría el tamaño de los paquetes más allá del MTU máximo de 1500. Esto requeriría fragmentar los mensajes 1 y 2, y sería una gran complicación. Probablemente no lo haremos.

Relay y Peer Test: Ver arriba

Streaming

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

Archivos SU3

POR HACER

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 las complejidades de implementación y la seguridad reducida.

Para firmas únicamente PQ de archivos SU3, utilice los OID 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 hacer hash de 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.

Ten 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 archivos SU3; usa las variantes ph (prehash).

Otras Especificaciones

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

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

• SAMv3
• Bittorrent
• Pautas para desarrolladores
• Nomenclatura / libreta de direcciones / servidores de salto
• Otros documentos

Análisis de Sobrecarga

Intercambio de Claves

Aumento de tamaño (bytes):

Velocidades según reporta Cloudflare :

Firmas

Tamaño:

Tamaños típicos de key, sig, RIdent, Dest o incrementos de tamaño (Ed25519 incluido como referencia) asumiendo tipo de cifrado X25519 para RIs. Tamaño agregado para un Router Info, LeaseSet, datagramas que pueden ser respondidos, y cada uno de los dos paquetes de streaming (SYN y SYN ACK) listados. Los Destinations y Leasesets actuales contienen padding repetido y son compresibles en tránsito. Los nuevos tipos no contienen padding y no serán compresibles, resultando en un incremento de tamaño mucho mayor en tránsito. Ver la sección de diseño arriba.

Velocidades según reporta Cloudflare :

Análisis de Seguridad

Las categorías de seguridad NIST se resumen en la presentación NIST diapositiva 10. Criterios preliminares: Nuestra categoría mínima de seguridad NIST debería ser 2 para protocolos híbridos y 3 para PQ únicamente.

Apretones de manos

Todos estos son protocolos híbridos. Las implementaciones deberían preferir MLKEM768; MLKEM512 no es lo suficientemente seguro.

Categorías de seguridad NIST FIPS 203 :

Firmas

Esta propuesta define tanto tipos de firma híbridos como solo PQ. El híbrido MLDSA44 es preferible al solo PQ MLDSA65. Los tamaños de claves y firmas para MLDSA65 y MLDSA87 son probablemente demasiado grandes para nosotros, al menos al principio.

Categorías de seguridad NIST FIPS 204 :

Preferencias de Tipo

Aunque definiremos e implementaremos 3 tipos de criptografía 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 estructura. También continuaremos investigando y monitoreando los desarrollos en otros proyectos y protocolos.

Después de un año o más de desarrollo intentaremos establecer un tipo preferido o predeterminado para cada caso de uso. La selección requerirá hacer compensaciones entre ancho de banda, CPU y nivel de seguridad estimado. Es posible que no todos los tipos sean adecuados o estén permitidos para todos los casos de uso.

Las preferencias preliminares son las siguientes, sujetas a cambios:

Cifrado: MLKEM768_X25519

Signatures: MLDSA44_EdDSA_SHA512_Ed25519

Las restricciones preliminares son las siguientes, sujetas a cambios:

Cifrado: MLKEM1024_X25519 no permitido para SSU2

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

Notas de Implementación

Soporte de Bibliotecas

Las librerías Bouncycastle, BoringSSL y WolfSSL ya soportan MLKEM y MLDSA. El soporte de OpenSSL estará en su versión 3.5 el 8 de abril de 2025 OpenSSL .

La librería Noise de southernstorm.com adaptada por Java I2P contenía soporte preliminar para handshakes híbridos, pero lo eliminamos por no estar en uso; tendremos que agregarlo de nuevo y actualizarlo para que coincida con la especificación Noise HFS .

Variantes de Firma

Utilizaremos la variante de firma “hedged” o aleatorizada, no la variante “determinística”, como se define en FIPS 204 sección 3.4. Esto garantiza que cada firma sea diferente, incluso cuando se aplique sobre los mismos datos, y proporciona protección adicional contra ataques de canal lateral. Aunque FIPS 204 especifica que la variante “hedged” es la predeterminada, esto puede o no ser cierto en varias bibliotecas. Los implementadores deben asegurarse de que se utilice la variante “hedged” para firmar.

Utilizamos el proceso de firma normal (llamado Pure ML-DSA Signature Generation) que codifica el mensaje internamente como 0x00 || len(ctx) || ctx || message, donde ctx es algún valor opcional de tamaño 0x00..0xFF. No estamos utilizando ningún contexto opcional. len(ctx) == 0. Este proceso se define en FIPS 204 Algoritmo 2 paso 10 y Algoritmo 3 paso 5. Tenga en cuenta que algunos vectores de prueba publicados pueden requerir establecer un modo donde el mensaje no esté codificado.

Confiabilidad

El aumento de tamaño resultará en mucha más fragmentación de tunnel para almacenes NetDB, handshakes de streaming y otros mensajes. Verificar cambios en rendimiento y confiabilidad.

Tamaños de Estructuras

Encuentra y verifica cualquier código que limite el tamaño en bytes de la información de routers y leasesets.

NetDB

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

Ratchet

Tunnels Compartidos

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 el protocolo ratchet actual, y el tamaño mínimo del mensaje 1 (con solo una carga útil DateTime incluida) es de 919 bytes. La mayoría de los tamaños de mensaje 1 con el ratchet actual tienen una carga útil menor a 816 bytes, por lo que pueden clasificarse como ratchet no híbrido. Los mensajes grandes probablemente son POSTs, que son raros.

Por lo tanto, la estrategia recomendada es:

• Si el mensaje 1 es menor que 919 bytes, es el protocolo ratchet actual.
• Si el mensaje 1 es mayor o igual a 919 bytes, probablemente sea MLKEM512_X25519. Prueba MLKEM512_X25519 primero, y si falla, prueba el protocolo ratchet actual.

Esto debería permitirnos soportar de manera eficiente el ratchet estándar y el ratchet híbrido en el mismo destino, tal como previamente 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, porque podemos agregar soporte MLKEM a destinos existentes.

Las combinaciones soportadas requeridas son:

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

Las siguientes combinaciones pueden ser complejas, y NO se requiere que sean compatibles, pero pueden serlo, dependiendo 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

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

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

Probablemente NO intentaremos soportar algoritmos ElGamal e híbridos en el mismo destino. ElGamal está obsoleto, y ElGamal + híbrido solamente (sin X25519) no tiene mucho sentido. Además, tanto los Mensajes de Nueva Sesión ElGamal como los Híbridos son grandes, por lo que las estrategias de clasificación a menudo tendrían que intentar ambos descifrados, lo cual sería ineficiente. Dependiente de la implementación.

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

Secreto Hacia Adelante

La especificación ECIES permite Garlic Messages en la carga útil del New Session Message, lo que permite la entrega 0-RTT del paquete de streaming inicial, generalmente un HTTP GET, junto con el leaseset del cliente. Sin embargo, la carga útil del New Session Message no tiene forward secrecy (secreto perfecto hacia adelante). Como esta propuesta enfatiza el forward secrecy mejorado para ratchet, las implementaciones pueden o deberían diferir la inclusión de la carga útil de streaming, o el mensaje de streaming completo, hasta el primer Existing Session Message. Esto sería a expensas de la entrega 0-RTT. Las estrategias también pueden depender del tipo de tráfico o tipo de túnel, o en GET vs. POST, por ejemplo. Depende de la implementación.

Tamaño de Nueva Sesión

MLKEM, MLDSA, o ambos en el mismo destino, aumentarán dramáticamente el tamaño del Mensaje de Nueva Sesión, como se describió anteriormente. Esto puede disminuir significativamente la confiabilidad de la entrega del Mensaje de Nueva Sesión a través de túneles, donde deben fragmentarse en múltiples mensajes de túnel de 1024 bytes. El éxito de la entrega es proporcional al número exponencial de fragmentos. Las implementaciones pueden usar varias estrategias para limitar el tamaño del mensaje, a expensas de la entrega 0-RTT. Dependiente de la implementación.

NTCP2

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

Ofuscación

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

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

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

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

Utilizamos el campo de versión en el encabezado largo y lo establecemos en 3 para MLKEM512 y 4 para MLKEM768. v=2,3,4 en la dirección sería suficiente.

Verificar y comprobar que SSU2 puede manejar RI firmado con MLDSA fragmentado a través de 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

En todos los casos, usa los nombres de transporte NTCP2 y SSU2 como de costumbre.

Tipos de Cifrado del Router

Tenemos varias alternativas a considerar:

Routers Tipo 5/6/7

No recomendado. Usa solo los nuevos transportes listados arriba que coincidan con el tipo de router. Los routers más antiguos no pueden conectarse, construir túneles a través de, o enviar mensajes netDb hacia ellos. Tomaría varios ciclos de lanzamiento depurar y asegurar el soporte antes de habilitarlo por defecto. Podría extender el despliegue por un año o más sobre las alternativas de abajo.

Routers Tipo 4

Recomendado. Como PQ no afecta la clave estática X25519 o 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 enviar mensajes netDb.

Recomendaciones

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

Tipos de Firma del Router

Routers Tipo 12-17

Los routers más antiguos verifican los RIs y por lo tanto no pueden conectarse, construir túneles a través de ellos, o enviar mensajes netDb hacia ellos. Tomaría varios ciclos de lanzamiento depurar y asegurar el soporte antes de habilitarlo por defecto. Serían los mismos problemas que el despliegue del tipo de cifrado 5/6/7; podría extender el despliegue por un año o más sobre la alternativa de despliegue del tipo de cifrado tipo 4 listada arriba.

Sin alternativas.

Tipos de Cifrado LS

Claves LS Tipo 5-7

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

Los destinos pueden soportar múltiples tipos de clave, pero solo mediante el descifrado de prueba del mensaje 1 con cada clave. La sobrecarga puede mitigarse manteniendo conteos 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.

Tipos de Firma de Destino

Destinos Tipo 12-17

Los routers verifican las firmas de leaseSet y por lo tanto no pueden conectarse, o recibir leaseSets para destinos de tipo 12-17. Tomaría varios ciclos de lanzamiento depurar y asegurar el soporte antes de habilitarlo por defecto.

No hay alternativas.

Prioridades y Implementación

Los datos más valiosos son el tráfico de extremo a extremo, cifrado con ratchet. Como observador externo entre saltos de tunnel, está cifrado dos veces más, con cifrado de tunnel y cifrado de transporte. Como observador externo entre OBEP e IBGW, está cifrado solo una vez más, con cifrado de transporte. Como participante OBEP o IBGW, ratchet es el único cifrado. Sin embargo, como los tunnels son unidireccionales, capturar ambos mensajes en el handshake de ratchet requeriría routers coludidos, a menos que los tunnels fueran construidos con el OBEP e IBGW en el mismo router.

El modelo de amenaza PQ más preocupante en este momento es almacenar tráfico hoy, para descifrarlo dentro de muchos muchos años (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 casi en tiempo real, ¿está mucho más lejos? Y es entonces cuando querríamos migrar a claves estáticas PQC.

Entonces, el modelo de amenaza PQ más temprano es OBEP/IBGW almacenando tráfico para descifrado posterior. Deberíamos implementar ratchet híbrido primero.

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

El despliegue de firmas también será un año o más tarde que el despliegue de cifrado, porque no es posible la compatibilidad hacia atrás. 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ódulos de seguridad de 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 IETF draft .

Migración

Si no podemos soportar tanto los protocolos de ratchet 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 probarlo.

Problemas

• Selección de Hash Noise - ¿mantener SHA256 o actualizar? SHA256 debería ser bueno por otros 20-30 años, no está amenazado por PQ, Ver presentación NIST y presentación NCCOE . Si SHA256 es comprometido tenemos problemas peores (netDb).
• NTCP2 puerto separado, dirección de router separada
• SSU2 relay / peer test
• 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