¿Qué son ML-KEM, ML-DSA y SLH-DSA — y cuál usa tu navegador hoy?

¿Qué estandarizó NIST exactamente el 13 de agosto de 2024?

Tres algoritmos, cada uno con su propio estándar federal: FIPS 203 (ML-KEM), un mecanismo de encapsulamiento de llaves derivado de CRYSTALS-Kyber; FIPS 204 (ML-DSA), un esquema de firma digital derivado de CRYSTALS-Dilithium; y FIPS 205 (SLH-DSA), un esquema de firma basado en hashes derivado de SPHINCS+ (anuncio de NIST, 13-ago-2024). Esa fecha importa: es el momento en que la criptografía post-cuántica dejó de ser un menú de investigación y se volvió un objeto de cumplimiento — parámetros exactos, formatos de bytes exactos, vectores de prueba y una ruta de validación FIPS que un departamento de compras puede escribir en un contrato.

Los nombres confunden, así que Rosetta Quantum deja el mapeo dicho una vez y en claro: Kyber se convirtió en ML-KEM (Module-Lattice Key-Encapsulation Mechanism), Dilithium en ML-DSA (Module-Lattice Digital Signature Algorithm) y SPHINCS+ en SLH-DSA (Stateless Hash-based Digital Signature Algorithm). Una ficha técnica que todavía dice «Kyber» describe el algoritmo pre-estándar; el objeto desplegado y estandarizado es ML-KEM (FIPS 203, 13-ago-2024).

Un solo número ordena todo lo que sigue, y es la asimetría de esta transición: de esos tres estándares, exactamente uno corre hoy en tu navegador — y no es una firma.

¿Qué es ML-KEM — el que ya estás usando?

ML-KEM es el caballo de carga del intercambio de llaves: un mecanismo de encapsulamiento (KEM) cuyo trabajo es que dos máquinas que nunca se vieron acuerden una llave secreta compartida, que luego cifra la sesión. Su seguridad descansa en problemas de retículos estructurados (Module-LWE), y FIPS 203 (13-ago-2024) define tres juegos de parámetros — ML-KEM-512, ML-KEM-768 y ML-KEM-1024 — en las categorías de seguridad 1, 3 y 5 de NIST.

Lo que tu navegador corre de verdad es X25519MLKEM768: un híbrido que ejecuta a la vez un intercambio clásico X25519 y un encapsulamiento ML-KEM-768 y mezcla ambos secretos, de modo que un atacante tendría que romper los dos a la vez (borrador IETF draft-ietf-tls-ecdhe-mlkem). Chrome lo trae por defecto desde Chrome 131 (blog de seguridad de Google, sep-2024), Firefox desde 132 y Safari desde la versión 26; la matriz de soporte por stack, con versiones y fechas, está en la pieza de adopción que Rosetta publicó ayer: cuánto tráfico de Internet ya negocia cifrado post-cuántico.

El resultado medido, no la promesa: ≈70% del tráfico HTTPS generado por navegadores hacia la red de Cloudflare ya negociaba acuerdo de llaves post-cuántico en la lectura del 29-sep-2026 — unos 45.000 millones de conexiones post-cuánticas por día — mientras solo ≈15% de los servidores de origen escaneados lo soportaba de su lado (blog de Cloudflare, 29-sep-2026). Si no hiciste nada, los navegadores de tus usuarios ya están pidiendo ML-KEM; que tus servidores respondan es la parte que depende de ti.

¿Qué son ML-DSA y SLH-DSA — y por qué todavía no protegen nada en tu navegador?

Son los estándares de firma, y la respuesta directa es: cero certificados TLS públicamente confiables los usan hoy. Las firmas hacen un trabajo distinto al intercambio de llaves — prueban con quién estás hablando. Cada conexión TLS que haces hoy sigue autenticada por certificados RSA o ECDSA; la parte post-cuántica de tu conexión, donde existe, es solo el acuerdo de llaves.

ML-DSA (FIPS 204, 13-ago-2024) es el sucesor de propósito general: basado en retículos, rápido, con firmas de 2.420 a 4.627 bytes según el juego de parámetros. SLH-DSA (FIPS 205, 13-ago-2024) es el respaldo conservador: depende solo de funciones hash — el supuesto más probado de la criptografía — al precio de firmas desde ≈7,9 KB hasta ≈49 KB, lo que lo orienta a firmware y firma de código antes que a handshakes TLS.

¿Por qué la demora en la Web PKI? Aritmética, sobre todo. Un handshake TLS típico lleva hoy cinco firmas y dos llaves públicas; cambiarlas todas a ML-DSA empujaría un solo handshake por encima de 10 KB (cobertura del roadmap de Let's Encrypt, Help Net Security, 5-jun-2026). Se están construyendo en público dos salidas: meter ML-DSA en certificados X.509 clásicos de todos modos, y los Merkle Tree Certificates (MTC) — un rediseño que colapsa el handshake a una firma, una llave y una prueba de inclusión, que Let's Encrypt apuntará con un entorno de staging a fines de 2026 y producción en 2027 (Help Net Security, 5-jun-2026). Las dos fechas son planes declarados, no sistemas en producción.

Los reguladores ya pusieron precio a esta asimetría: el plazo federal de EE. UU. para intercambio de llaves post-cuántico en activos de alto valor es el 31-dic-2030, mientras las firmas tienen hasta el 31-dic-2031 (EO 14412 / OMB M-26-15, lectura del 22-jun-2026). Y si hace falta un recordatorio de por qué la infraestructura de firma merece la atención, el mayor robo de la historia hace cinco días — ≈US$6.360 millones a Binance (TRM Labs, 30-oct-2026) — comprometió la capa de firma convencional, con cero computadores cuánticos involucrados: qué cambia para tu seguridad el mayor hackeo de la historia.

¿Qué son HQC y FN-DSA — los dos que siguen en el pipeline?

HQC es la póliza de seguro. NIST lo seleccionó el 11-mar-2025 como quinto algoritmo y KEM de respaldo precisamente porque se construye sobre códigos correctores de errores, una familia matemática distinta de los retículos de ML-KEM — de modo que un avance matemático contra una no se llevaría a las dos (boletín PQC de NIST, 11-mar-2025). NIST anunció un borrador de estándar para 2026 y un estándar final esperado para 2027; al escaneo documental de Rosetta del 1-nov-2026, todavía no se encontró ningún borrador de HQC publicado, así que ambas fechas siguen siendo declaradas, no entregadas.

FN-DSA (Falcon, el futuro FIPS 206) es el candidato de firmas compactas — llaves públicas de 897 bytes y firmas de ≈666 bytes en su juego de parámetros más chico, según la propuesta Falcon. Su borrador sigue sin publicarse: NIST escribió el 13-abr-2026 que FIPS 206 estaba «en la cadena administrativa de aprobación para publicación», sin fecha concreta (pqc-forum de NIST, consultado 1-nov-2026). Si un vendor te dice que su producto está «certificado FIPS 206», ese certificado todavía no existe.

¿Qué algoritmo corre en qué capa de tu stack?

Esta es la tabla que Rosetta Quantum sugiere guardar. Los cinco algoritmos, para qué sirve cada uno y qué es verdad en producción hoy:

Y los tamaños, porque explican el orden del despliegue mejor que cualquier roadmap — el intercambio de llaves fue primero en parte porque su peaje post-cuántico es chico, mientras que el de las firmas se multiplica:

Las consecuencias de ingeniería completas de esos números — qué romperán en DNSSEC, en dispositivos restringidos, en cadenas de certificados — tendrán su propia pieza en esta serie.

¿Dónde está parado el tablero PQC hoy?

El tablero PQC de Rosetta, una fila por indicador, última lectura por fila, re-verificado donde la fecha es de hoy:

¿Qué hace un gerente de seguridad con estos cuatro nombres?

Primero, inventariar por capa, no por eslogan. La «preparación post-cuántica» no es una casilla: son al menos tres — intercambio de llaves (FIPS 203: ya desplegable, y del lado cliente muchas veces ya desplegado), certificados TLS (FIPS 204/205: nada que desplegar todavía en la Web PKI pública) y firma de código/firmware (FIPS 204/205: donde los datos viven más tiempo y donde aplica la lección Binance sobre infraestructura de firma, sin ningún computador cuántico a la vista).

Segundo, una sola pregunta para cada vendor: ¿qué número FIPS, en qué capa, en qué modo? «Quantum-safe» sin número de estándar es marketing; «ML-KEM, híbrido, para transporte» es una respuesta verificable. Una certificación FIPS 206 o HQC afirmada hoy es una afirmación sobre un estándar que no se publicó.

Tercero, secuenciar con el reloj medido, no con el ruidoso. El intercambio híbrido es barato de encender ahora, y la aritmética de harvest-now-decrypt-later — cuánto tiempo deben seguir secretos tus datos versus cuándo podría existir un computador cuántico criptográficamente relevante — es la forma honesta de elegir tu propio plazo: qué es harvest-now-decrypt-later y qué datos están en riesgo hoy. Para las firmas, los calendarios regulatorios de arriba son las fechas vinculantes; el recorrido de la casa está en cuándo expiran de verdad RSA y ECC.

Cuarto, mantener los ceros a la vista. El registro público sigue mostrando 0 llaves RSA-2048 rotas por un computador cuántico y 0 brechas atribuidas a un ataque cuántico (ambos re-verificados el 1-nov-2026, revisión documental de Rosetta). La posición Q-Day de la casa — piso 2031, ventana central 2033–2039 (juicio sellado RQ-PRED-QDAY-001, 9-oct-2026) — es exactamente eso: un juicio sellado y refutable, no una medición, publicado para poder puntuarse después: cuándo llegará el Q-Day, según lo que se puede medir hoy. Quien te venda urgencia sin números al lado te está vendiendo cajas.

Qué no sabemos

• Si el borrador de HQC aparecerá de verdad antes de que termine 2026, y si la expectativa de final en 2027 se sostendrá. Ambas son declaraciones de NIST (11-mar-2025); nuestro escaneo del 1-nov-2026 no encontró borrador publicado.
• Cuándo se publicará FIPS 206 (FN-DSA) — NIST mismo no da fecha (pqc-forum, 13-abr-2026).
• En qué ruta de firmas convergerá la Web PKI — ML-DSA en X.509 clásico, Merkle Tree Certificates, o ambas. La respuesta cambiará cómo se ve un plan de migración, y la producción de MTC es una meta 2027, no un producto.
• Si el ≈70% de Cloudflare generaliza más allá de la red de Cloudflare — es el mejor instrumento público disponible hasta que alguien más publique una serie comparable, y sus letras chicas están detalladas en la pieza de adopción.
• Si los supuestos de retículos estructurados, que ML-KEM y ML-DSA comparten, se sostienen por décadas. Esa incertidumbre no es el rumor de una ruptura — no hay ninguna pública — sino la razón declarada por la que HQC y SLH-DSA existen como respaldos sobre otra matemática.

Rosetta Quantum publica veredictos con datos crudos reproducibles y fuentes fechadas. Esto es contenido educativo, no un claim de producto ni una recomendación de compra; Rosetta no recomienda ningún vendor.