Resumen

  • Los tres grupos finales de RFC 10024 son combinaciones ordenadas de ECDHE y ML-KEM dentro de TLS 1.3; su secreto pretende resistir mientras al menos un componente siga siendo seguro.
  • El propio RFC advierte de una excepción operacional concreta: si ambos algoritmos usan el mismo generador aleatorio inseguro, la exposición de su estado a través de uno puede perjudicar al otro.
  • Investigar y gobernar la migración exige evidencia de ServerHello y transcript, además de un mapa independiente de entropía, proceso, biblioteca, módulo, firma y control de rollback.

La cronología de un fallo no comienza en ServerHello

Supongamos que un equipo de respuesta recibe una alerta de exposición de estado en una implementación de ML-KEM. La primera consulta confirma que el servicio negociaba X25519MLKEM768; la segunda demuestra que X25519 no presenta la misma debilidad matemática. Alguien propone cerrar el incidente: el componente tradicional sigue intacto y la combinación fue diseñada precisamente para ese caso.

La reconstrucción cambia al revisar el proceso. La encapsulación ML-KEM y el escalar efímero X25519 tomaban sus valores del mismo CSPRNG. La instancia había heredado un estado defectuoso después de un fork. La salida observable por el cliente ofrecía información sobre ese estado. De pronto, preguntar qué algoritmo «sobrevivió» ya no basta: hay que saber si ambos secretos nacieron de la misma fuente comprometida.

El escenario es hipotético y no acusa a ningún producto. Tampoco afirma que compartir un CSPRNG sano sea inseguro. Sirve para ordenar la investigación: primero se localiza la dependencia expuesta; después se determina qué promesa criptográfica sigue siendo aplicable.

RFC 10024, publicado como estándar del IETF en agosto de 2026, define tres grupos híbridos poscuánticos/tradicionales para TLS 1.3. Cada uno combina un intercambio elíptico efímero con ML-KEM. La meta es que el secreto de sesión permanezca protegido si al menos uno de los mecanismos componentes continúa siendo seguro.

Esa propiedad diversifica supuestos matemáticos. No certifica la independencia del sistema en ejecución.

Un único grupo transporta una receta exacta

El marco de RFC 9954 trata cada combinación como un NamedGroup opaco. No se negocian dos piezas que luego pueda mezclar la aplicación a voluntad. Las claves públicas o los textos cifrados se concatenan en un orden fijo; los secretos de tamaño fijo siguen otro orden igualmente definido y ocupan el lugar del secreto (EC)DHE en el calendario de claves de TLS 1.3.

En X25519MLKEM768, código 4588, ML-KEM aparece primero. El cliente envía 1.184 bytes de clave de encapsulación ML-KEM-768 y 32 bytes X25519: 1.216 en total. El servidor responde con 1.088 bytes de texto cifrado ML-KEM y 32 bytes X25519: 1.120. El secreto final concatena 32 bytes ML-KEM y 32 X25519.

SecP256r1MLKEM768, código 4587, empieza por P-256. La parte del cliente reúne un punto no comprimido de 65 bytes y 1.184 bytes ML-KEM; la del servidor, 65 y 1.088. El secreto coloca primero 32 bytes ECDHE y luego 32 ML-KEM.

SecP384r1MLKEM1024, código 4589, une un punto P-384 de 97 bytes con 1.568 bytes ML-KEM-1024. Tanto cliente como servidor envían 1.665 bytes. El secreto contiene 48 bytes ECDHE y 32 ML-KEM.

Los tamaños fijos hacen inequívoca la concatenación. También dejan claro que cambiar orden, parámetros o protocolo produce otra construcción. No es válido copiar dos salidas a un protocolo interno y declarar que RFC 10024 cubre el resultado.

La seguridad está anclada al transcript

El TLS 1.3 vigente está especificado por RFC 9846. Su transcript enlaza ClientHello, un posible HelloRetryRequest, el segundo ClientHello, ServerHello y los mensajes de autenticación. El key share que selecciona el servidor entra en el calendario de claves; CertificateVerify firma el transcript; Finished demuestra posesión de las claves derivadas.

RFC 10024 dice de forma expresa que su análisis de seguridad depende críticamente de ese transcript. No es un detalle de transporte. Es lo que ata el grupo ofrecido, el grupo seleccionado y la sesión autenticada a una misma historia.

RFC 9794 proporciona un lenguaje prudente. Un esquema PQ/T híbrido contiene al menos un componente poscuántico y otro tradicional. La etiqueta «poscuántico» expresa la propiedad que se busca; no promete que nunca aparecerá un ataque clásico o cuántico.

Por eso la evidencia mínima de un incidente incluye qué grupos ofreció el cliente, qué key shares envió, si hubo reintento, qué grupo seleccionó ServerHello, qué validaciones fallaron, qué esquema firmó CertificateVerify y si Finished concluyó. Una opción habilitada en la consola no responde esas preguntas.

Las validaciones protegen entradas, no la cadena de producción

RFC 10024 obliga al servidor a validar la clave de encapsulación ML-KEM recibida según FIPS 203. Si falla, debe abortar con illegal_parameter. El cliente valida la longitud del texto cifrado. Los componentes ECDHE aplican sus comprobaciones de punto, y X25519 rechaza un secreto compartido todo cero. Ciertos fallos de desencapsulación ML-KEM generan internal_error.

Esas negativas son parte de la seguridad. Impiden que material mal formado se acepte como una sesión normal. Pero no atestiguan de dónde salió el azar, si la biblioteca resiste canales laterales, si el mismo proceso guardó ambos secretos o si el tráfico terminó realmente en el módulo examinado.

FIPS 203 estandariza ML-KEM-512, 768 y 1024 y lo describe como un mecanismo que se considera seguro contra adversarios con capacidad cuántica. El matiz importa: una norma común no elimina los riesgos de implementación, parámetros, aleatoriedad o criptoanálisis futuro.

NIST SP 800-227 amplía las recomendaciones para implementar y usar KEM de forma segura, incluidas construcciones híbridas. Citarlo en una política no demuestra qué controles ejecutó un binario concreto.

El RFC anticipa la causa común

ML-KEM necesita una cantidad aleatoria m durante la encapsulación. El cliente puede recuperarla al desencapsular. RFC 10024 observa que, si m contiene información sobre otras salidas del generador, esa información queda disponible para el cliente. Los escalares efímeros ECDHE también requieren aleatoriedad criptográficamente segura, aunque el escalar no se envíe.

La advertencia resultante es directa: cuando los dos algoritmos usan el mismo RNG inseguro, revelar el estado mediante uno afecta también la seguridad del otro.

«Inseguro» es una condición, no un adorno. Un CSPRNG correctamente diseñado y gestionado no rompe la combinación sólo porque lo invoquen ambos componentes. Tampoco es obligatorio duplicar dispositivos físicos. La obligación real es trazar la fuente de entropía, la semilla, el reseeding, los forks, snapshots, rollbacks, pruebas de salud, memoria y salidas observables.

RFC 8937 explica cómo una entropía inicial rota puede debilitar muchas instancias derivadas. También propone una envoltura opcional que mezcla material procedente de una operación con clave privada duradera para reforzar la aleatoriedad entre sesiones. La técnica es una opción; el inventario de dependencias es ineludible.

El mismo método de investigación descubre otras causas comunes. Una sola vulnerabilidad de ejecución remota en la biblioteca puede leer ambos componentes. Un firmware compartido puede atravesar dos algoritmos dentro del HSM. Una única cadena de compilación firmada puede sustituir las dos implementaciones. Un proveedor de terminación puede concentrar el control aunque la criptografía sea diversa. Son hechos operativos que limitan el alcance de la garantía, no una acusación contra la combinación matemática.

El orden FIPS responde una pregunta estrecha

En los grupos con P-256 y P-384, el secreto ECDHE aparece primero. RFC 10024 explica que, bajo la condición NIST descrita para alimentar HKDF con dos secretos distintos, la implementación ECDHE debe estar certificada para ese uso, mientras que el orden no exige certificar la implementación ML-KEM. En X25519MLKEM768, ML-KEM aparece primero y su implementación asume la exigencia de certificación.

Esto no clasifica la fuerza de los algoritmos. Un primer componente certificado no certifica automáticamente el segundo, el generador, el binario combinado, la política o el servicio. Un informe serio identifica certificado, versión y límite del módulo; no se detiene en «grupo híbrido compatible con FIPS».

IANA registra el lenguaje, no la ejecución

El registro IANA de grupos TLS asigna 4587, 4588 y 4589 a las combinaciones finales. Sólo X25519MLKEM768 tiene Recommended Y. Los otros dos muestran N; la propia nota de IANA aclara que eso no necesariamente implica un defecto, pues un algoritmo puede estar destinado a usos limitados.

Los grupos experimentales Kyber con códigos 25497 y 25498 quedaron obsoletos y desaconsejados. Una investigación debería distinguirlos de los códigos finales. Observar «PQC» sin el valor exacto oculta una diferencia de semántica en el cable.

El registro prueba que existe un nombre común. La configuración prueba una intención local. ClientHello prueba una oferta. ServerHello y el transcript prueban una selección concreta. Sólo la medición de la flota demuestra cobertura.

La consulta oficial de erratas de RFC 10024 no mostraba registros el 30 de agosto de 2026. Es una observación fechada, no una garantía sobre toda implementación.

El intercambio de claves no migra la firma

RFC 9954 deja la autenticación de nueva generación fuera de alcance. TLS 1.3 separa el acuerdo de claves de Certificate y CertificateVerify. Una conexión puede usar X25519MLKEM768 y seguir autenticando el servidor con una firma tradicional.

Las dos trayectorias responden a tiempos distintos. El acuerdo híbrido protege frente a grabar tráfico ahora y descifrarlo tras una ruptura futura. La futura falsificación de firmas y la migración de certificados requieren su propio programa. La frase «PQC completado» no debería ocultar esa separación.

La primacía del código en ejecución de Heng Lu, Running-Code Primacy, ofrece el principio forense: la evidencia del transcript tiene más autoridad que el icono de una consola. La doctrina de especificación inicial mínima y decisión futura localizada delimita el papel del estándar: fijar el mínimo interoperable sin decidir la arquitectura operativa de todos.

El análisis de capas de realidad y poder simbólico separa «híbrido» de las operaciones que esa palabra resume. El estudio del control práctico de los datos pregunta quién puede cambiar terminador, biblioteca, entropía, telemetría y rollback. Una investigación termina sólo cuando identifica a esos actores y sus límites.

El grupo puede haber funcionado exactamente como se diseñó. La causa raíz aún puede estar debajo de los dos algoritmos.