PQC StatusCRYSTALS-Kyber y ML-KEM no son dos algoritmos distintos. ML-KEM es la forma estandarizada de CRYSTALS-Kyber, publicada por el NIST como FIPS 203 el 13 de agosto de 2024. El cambio no es cosmético: FIPS 203 es una especificación con sus propios nombres de conjuntos de parámetros, sus propios formatos de clave y sus propias reglas de validación, y una implementación de la propuesta anterior del concurso no interopera con una implementación de ML-KEM. En TLS, por eso el grupo previo al estándar X25519Kyber768Draft00 (codepoint 0x6399) está obsoleto y debe sustituirse por los grupos ML-KEM.
Un diseño, dos nombres, una especificación aprobada
Un KEM (mecanismo de encapsulación de claves) es el componente de un handshake que permite a dos partes acordar un secreto compartido. CRYSTALS-Kyber era el nombre del KEM basado en retículos presentado al proceso de estandarización poscuántica del NIST. Cuando el NIST publicó el estándar definitivo, el algoritmo pasó a llamarse ML-KEM, abreviatura de Module-Lattice-Based Key-Encapsulation Mechanism, y quedó especificado en FIPS 203. Se publicó el mismo día que FIPS 204 (ML-DSA, firmas) y FIPS 205 (SLH-DSA, firmas basadas en hash sin estado).
En una conversación, Kyber y ML-KEM se refieren a la misma familia de diseños. En el código, en una lista de grupos o en un documento de cumplimiento, no son intercambiables. Solo ML-KEM tal como se especifica en FIPS 203 es un estándar aprobado. Todo lo que siga etiquetado como Kyber, Kyber768 o Draft00 es anterior a él. Nuestra página de referencia de ML-KEM sigue el estándar y su estado, y la página del borrador Kyber sigue los grupos previos al estándar que conviene eliminar ya de las configuraciones.
Qué cambió el paso del borrador al estándar definitivo
FIPS 203 se publicó primero como borrador público inicial para comentarios antes de que el NIST emitiera el texto definitivo. Tres categorías de cambios son relevantes para un ingeniero o un arquitecto.
Nombres y conjuntos de parámetros
Kyber512, Kyber768 y Kyber1024 pasaron a ser ML-KEM-512, ML-KEM-768 y ML-KEM-1024. FIPS 203 especifica exactamente estos tres conjuntos de parámetros. Una opción de compilación, una constante o un vector de prueba que todavía lleve un nombre Kyber indica que el código no se ha actualizado, no simplemente que alguien conservó una etiqueta antigua.
Detalles de la especificación que rompen la interoperabilidad
El estándar definitivo difiere de la propuesta anterior del concurso en detalles de la especificación que incluyen la generación de claves, la codificación de claves y la derivación del secreto compartido. Esos detalles son normativos en FIPS 203 y deben leerse allí en lugar de a través de resúmenes de segunda mano. La consecuencia práctica es simple y absoluta: un extremo que ejecute Kyber previo al estándar y un extremo que ejecute ML-KEM no derivarán el mismo secreto compartido. No hay negociación entre ellos, ni ruta de degradación, ni compatibilidad parcial. El handshake falla, o el grupo simplemente nunca se selecciona.
Reglas que una implementación debe seguir
FIPS 203 también especifica comprobaciones que una implementación realiza sobre el material de clave recibido antes de usarlo, y define el comportamiento de la desencapsulación cuando la entrada no es válida (rechazo implícito, que devuelve un secreto compartido pseudoaleatorio en lugar de un error). Los autores de bibliotecas soportan la mayor parte de este peso. Para quien consume una biblioteca, la lección es preferir una implementación mantenida que declare conformidad con FIPS 203 frente a una copia del código de referencia de la época del concurso, y revisar las notas de versión en lugar del nombre del algoritmo.
Los tres conjuntos de parámetros: 512, 768 y 1024
FIPS 203 define los tres conjuntos de parámetros en relación con las categorías de seguridad del NIST. El número no es una longitud de clave en bits: es una etiqueta del conjunto de parámetros.
| Conjunto de parámetros | Categoría de seguridad del NIST | Dónde aparece en la práctica |
|---|---|---|
| ML-KEM-512 | Categoría 1 | Registrado como grupo TLS puro (codepoint 512). Rara vez se despliega por sí solo para el tráfico web público. |
| ML-KEM-768 | Categoría 3 | La elección de facto del ecosistema: X25519MLKEM768 en los navegadores, mlkem768x25519-sha256 en OpenSSH. |
| ML-KEM-1024 | Categoría 5 | Exigido por NSA CNSA 2.0 para los National Security Systems de EE. UU. Combinado con P-384 en SecP384r1MLKEM1024. |
Para TLS y SSH de uso general, el ecosistema ha convergido en ML-KEM-768 dentro de una construcción híbrida. Si opera sistemas dentro del ámbito de NSA CNSA 2.0, la suite designa ML-KEM-1024 junto con ML-DSA-87, LMS o XMSS, AES-256 y SHA-384 o SHA-512, con un uso exclusivo previsto para finales de 2030 en la firma de software y firmware y en el equipamiento de red tradicional, y para finales de 2033 en navegadores y servidores web, servicios en la nube y sistemas operativos. Otras autoridades formulan sus posiciones como recomendaciones: BSI TR-02102-1 recomienda el acuerdo de claves poscuántico híbrido, y ANSSI hace obligatoria la hibridación dentro de su ámbito regulado, al tiempo que indica que sus recomendaciones poscuánticas aún no son obligaciones normativas fuera de él. Este artículo es informativo y no constituye asesoramiento jurídico.
Grupos TLS: qué está vigente y qué está obsoleto
El grupo con nombre es la parte visible de todo esto. Solo los codepoints siguientes existen en el registro de IANA para ML-KEM, y solo uno de ellos es la entrada obsoleta previa al estándar.
| Grupo | Codepoint | Estado |
|---|---|---|
| X25519Kyber768Draft00 | 0x6399 | Kyber previo al estándar. Obsoleto. Elimínelo. |
| X25519MLKEM768 | 0x11EC (4588) | Híbrido. Ofrecido por defecto por las versiones actuales de Chrome, Edge y Firefox. |
| SecP256r1MLKEM768 | 0x11EB (4587) | Híbrido, para pilas estandarizadas en curvas del NIST. |
| SecP384r1MLKEM1024 | 0x11ED (4589) | Híbrido, perfil de categoría 5. |
| MLKEM512 / MLKEM768 / MLKEM1024 | 512 / 513 / 514 | ML-KEM puro, sin componente clásico. Hoy no es una opción por defecto para servidores web públicos. |
Los grupos híbridos combinan un acuerdo de claves clásico con ML-KEM, de modo que la sesión sigue siendo al menos tan robusta como la parte clásica si se descubre una debilidad en la construcción basada en retículos, y obtiene protección poscuántica frente al tráfico grabado. Esa combinación se describe para TLS 1.3 en RFC 10024 (agosto de 2026). El tráfico grabado solo está protegido por el intercambio de claves, razón por la cual el acuerdo de claves migra primero y los certificados pueden seguir más adelante. La página de X25519MLKEM768 detalla el grupo que la mayoría de los servidores debería habilitar primero.
Qué revisar en bibliotecas, servidores y SSH
Ejecute primero comprobaciones de solo lectura, en un host de preproducción, antes de tocar una configuración de producción.
OpenSSL
Se necesita OpenSSL 3.5 o posterior para los grupos TLS de ML-KEM. Una rama anterior puede seguir anunciando un grupo del borrador Kyber a través de un provider o de un parche de la distribución: ese es el caso que hay que localizar y eliminar.
openssl version
openssl list -tls-groups | grep -i mlkem
openssl s_client -connect example.com:443 -groups X25519MLKEM768En la salida de s_client, lea el grupo negociado. Si la conexión falla con un error de handshake mientras que un grupo clásico funciona, el servidor aún no admite ML-KEM.
Configuración del servidor
Mantenga siempre un grupo clásico de respaldo después del grupo híbrido para que los clientes más antiguos puedan seguir conectándose. En nginx compilado con OpenSSL 3.5 o posterior:
ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;La sintaxis y los valores admitidos varían entre servidores y entre compilaciones de distribución, así que verifíquelos con su propia versión. Nuestra guía para habilitar ML-KEM en nginx, Apache, HAProxy y Caddy recoge la directiva de cada uno.
SSH
OpenSSH 9.9 (19 de septiembre de 2024) añadió mlkem768x25519-sha256, disponible por defecto. OpenSSH 10.0 (9 de abril de 2025) lo convirtió en el acuerdo de claves por defecto, y OpenSSH 10.1 (6 de octubre de 2025) avisa cuando una conexión negocia un acuerdo de claves que no es poscuántico, mediante la opción WarnWeakCrypto, activada por defecto. Las versiones anteriores, a partir de OpenSSH 9.0, usan por defecto el híbrido sntrup761x25519-sha512@openssh.com, que es poscuántico pero no es ML-KEM.
ssh -V
ssh -Q kex | grep mlkemCódigo de aplicación y dependencias
- Busque en sus repositorios y en su gestión de configuración las cadenas
Kyber,kyber768,Draft00y0x6399. Cada coincidencia es código muerto o una configuración errónea activa. - Revise las listas de grupos fijadas en balanceadores de carga, CDN, pasarelas de API, proxies inversos y terminadores TLS. Una lista fijada es la causa más habitual de que una biblioteca moderna siga negociando un grupo clásico.
- Revise las notas de versión de su biblioteca criptográfica, no el nombre del algoritmo, para confirmar que la implementación sigue FIPS 203. Si la validación FIPS le importa, compruebe el estado de validación del módulo y la versión concretos que distribuye.
- Registre en su inventario el conjunto de parámetros, no solo el algoritmo: ML-KEM-768 y ML-KEM-1024 son respuestas distintas para un auditor que pregunte cuál ha desplegado.
Compruebe qué negocian realmente sus servidores
La forma más rápida de saber si un dominio usa el estándar o sigue en un grupo del borrador es observar lo que ofrece en la red. Puede analizar su dominio con PQC Status de forma gratuita: el escáner informa de los grupos híbridos ML-KEM que acepta un servidor, las versiones de TLS y las suites de cifrado, y la cadena de certificados. Un análisis describe únicamente la configuración TLS visible desde el exterior. No es una certificación ni una declaración de cumplimiento. El siguiente paso concreto en este tema: confirme que cada endpoint público ofrece X25519MLKEM768 con un grupo clásico de respaldo y, a continuación, elimine cualquier referencia restante al grupo Kyber previo al estándar de su configuración y de su inventario.