Explicación de las normas NIST PQC: FIPS 203, 204 y 205 para equipos empresariales

Respuesta rápida: El NIST finalizó tres estándares de criptografía post-cuántica el 13 de agosto de 2024: FIPS 203 (ML-KEM) para el establecimiento de claves, FIPS 204 (ML-DSA) para firmas digitales de propósito general y FIPS 205 (SLH-DSA) como alternativa conservadora para firmas basadas en funciones hash. La mayoría de las implementaciones empresariales utilizan por defecto ML-KEM-768 y ML-DSA-65 para uso civil, o ML-KEM-1024 y ML-DSA-87 para entornos CNSA 2.0, y reservan SLH-DSA para casos específicos donde la diversidad de algoritmos es más importante que el rendimiento.

La publicación de tres estándares el mismo día no equivale a que tres estándares resuelvan el mismo problema. Los equipos empresariales siguen preguntando qué documento FIPS se aplica realmente a su pila TLS, su canalización de firma de código o su autoridad de certificación, y la respuesta honesta es que los estándares FIPS 203, 204 y 205 nunca se concibieron para competir entre sí. Cubren funciones diferentes, presentan perfiles de rendimiento distintos y se encuentran en diferentes etapas de madurez de implementación en bibliotecas, módulos de seguridad de hardware (HSM) y plataformas en 2026.

Esta guía desglosa lo que especifica cada estándar, compara ML-KEM, ML-DSA y SLH-DSA directamente, y relaciona cada uno con el caso de uso, el perfil de rendimiento y la dependencia de migración que deben guiar la decisión. Para una versión más rápida y centrada en la toma de decisiones de esta comparación y los errores de selección más comunes, consulte nuestra guía de decisión ML-KEM vs ML-DSA vs SLH-DSA.

Puntos Clave

• Las normas FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) fueron finalizadas por el NIST el 13 de agosto de 2024, poniendo fin a un proceso de evaluación pública de ocho años.
• ML-KEM resuelve el establecimiento de claves; ML-DSA y SLH-DSA resuelven las firmas digitales. No son intercambiables, y la mayoría de los sistemas necesitan tanto un KEM como un algoritmo de firma.
• ML-DSA es la firma de propósito general por defecto; SLH-DSA sacrifica rendimiento y tamaño a cambio de una suposición de seguridad conservadora basada en hash, independiente de las matemáticas de retículo.
• La elección del conjunto de parámetros depende del objetivo de implementación: ML-KEM-768 y ML-DSA-65 para sistemas civiles, ML-KEM-1024 y ML-DSA-87 cuando se aplica CNSA 2.0.
• En 2026, el nivel de madurez en la implementación varía notablemente según el algoritmo y la plataforma, y ​​esa brecha de madurez, y no la preferencia por un algoritmo, debería ser lo que determine la secuenciación.

Qué estandarizan realmente las normas FIPS 203, 204 y 205.

El proyecto de criptografía postcuántica del NIST comenzó en 2016 con una convocatoria abierta para la presentación de algoritmos y pasó por varias rondas de criptoanálisis público antes de que el NIST seleccionara a los finalistas en 2022. El Secretario de Comercio aprobó los estándares resultantes el 13 de agosto de 2024, con vigencia a partir del día siguiente.

Estándar	Algoritmo	Basado en	Función	Reemplaza
FIP 203	ML-KEM (Mecanismo de encapsulación de claves basado en módulos y redes)	CRISTALES-Kyber	Establecimiento clave	Intercambio de claves RSA y Diffie-Hellman, ECDH
FIP 204	ML-DSA (Algoritmo de firma digital basado en retícula modular)	CRISTALES-Dilithium	Firmas digitales	Firmas RSA y ECDSA
FIP 205	SLH-DSA (Algoritmo de firma digital basado en hash sin estado)	SPHINCS +	Firmas digitales	Firmas RSA y ECDSA, como medida de precaución.

ML-KEM es un mecanismo de encapsulación de claves, el equivalente poscuántico de establecer un secreto compartido a través de un canal inseguro, la función que desempeñan actualmente los algoritmos clásicos Diffie-Hellman y ECDH. ML-DSA y SLH-DSA son algoritmos de firma digital que demuestran que un mensaje, certificado o software proviene de una clave privada específica y no ha sido alterado, la función que desempeñan actualmente RSA y ECDSA. Un cuarto estándar, FN-DSA (FALCON), permaneció como borrador (FIPS 206) hasta mediados de 2026, y el NIST también seleccionó HQC en 2025 como un mecanismo de encapsulación de claves de respaldo estructuralmente independiente para ML-KEM.

ML-KEM vs. ML-DSA vs. SLH-DSA: una visión general

Los tres algoritmos difieren en algo más que su función. El tamaño de las claves y las firmas, el supuesto de seguridad en el que se basa cada uno y el coste computacional determinan dónde encaja cada uno en una implementación real.

Propiedad	ML-KEM (FIPS 203)	ML-DSA (FIPS 204)	SLH-DSA (FIPS 205)
Base de seguridad	Módulo de aprendizaje con errores (retículo)	Módulo de aprendizaje con errores y módulo de solución de enteros cortos (retículo)	Seguridad basada únicamente en funciones hash, sin asumir estructuras reticulares.
Conjuntos de parámetros	ML-KEM-512, 768, 1024	ML-DSA-44, 65, 87	Múltiple, por ejemplo SLH-DSA-128s/f, 192s/f, 256s/f
Predeterminado civil	ML-KEM-768 (clave pública ~1,184 bytes, texto cifrado ~1,088 bytes)	ML-DSA-65 (clave pública ~1,952 bytes, firma ~3,309 bytes)	No es una opción predeterminada; se usa de forma selectiva.
Parámetro CNSA 2.0	ML-KEM-1024 (clave pública ~1,568 bytes, texto cifrado ~1,568 bytes)	ML-DSA-87 (clave pública ~2,592 bytes, firma ~4,627 bytes)	No incluido en el paquete CNSA 2.0
Tamaño de la firma/texto cifrado frente al clásico	Aproximadamente de 15 a 25 veces más grande que ECDH	Aproximadamente entre 15 y 50 veces más grande que ECDSA.	Aproximadamente entre 100 y 700 veces más grande que ECDSA (de 7,856 a 49,856 bytes).
Velocidad relativa	Rápido; comparable o más rápido que los KEM clásicos en hardware moderno.	Rápido; adecuado para firmas de alto volumen	Lento; la firma puede tardar cientos de milisegundos por operación.
Mejor ajuste	TLS, VPN y cualquier intercambio de claves	Firma de propósito general: código, documentos, certificados, protocolos	Firma de larga duración y bajo volumen donde la diversidad de algoritmos es más importante

La diferencia de tamaño es importante desde el punto de vista operativo, no solo académico. Una cadena de cuatro certificados basada en ML-DSA-87 contiene aproximadamente entre 15 y 20 veces más datos de firma que la misma cadena en ECDSA P-384, lo que se traduce en intercambios de claves TLS más extensos, más bytes de respuesta OCSP y mayores requisitos de rendimiento de firma de HSM. Las firmas de SLH-DSA son entre uno y dos órdenes de magnitud mayores, lo que representa la contrapartida directa de una suposición de seguridad que no depende de que la robustez de la red se mantenga.

Selección del estándar adecuado según el caso de uso

La mayoría de los sistemas necesitan un KEM y un algoritmo de firma que trabajen conjuntamente, no una única opción entre los tres.

• Intercambio de claves TLS y VPN: ML-KEM es la opción ideal. Las construcciones híbridas como X25519MLKEM768 lo combinan con un intercambio de claves clásico durante la ventana de transición.
• Firma de código y firma de firmware: ML-DSA es la opción práctica por defecto. Los artefactos firmados a menudo deben permanecer verificables durante años, y el perfil de rendimiento de ML-DSA admite el volumen de firmas que requieren la mayoría de los procesos de compilación.
• Jerarquías de autoridades de certificación: ML-DSA es la opción principal para las autoridades de certificación emisoras y raíz, siguiendo la misma lógica de parámetros que la firma de código.
• Firmas de alta fiabilidad, bajo volumen y larga duración: SLH-DSA resulta adecuado cuando una organización desea un segundo esquema de firma, estructuralmente independiente, como medida de seguridad contra una futura vulnerabilidad en la criptografía reticular, aceptando a cambio el tamaño y la velocidad que esto conlleva.
• Sistemas de seguridad nacional y la base industrial de defensa: ML-KEM-1024 y ML-DSA-87 son los conjuntos de parámetros requeridos según CNSA 2.0; SLH-DSA no forma parte de ese conjunto.

Madurez de la implementación en 2026

El estado estándar y la preparación para la implementación no son lo mismo. Los tres estándares FIPS son definitivos, pero la compatibilidad con bibliotecas, HSM y plataformas para cada uno ha madurado a un ritmo diferente.

ML-KEM cuenta con la mayor compatibilidad con navegadores y bibliotecas TLS de las tres, y el intercambio de claves híbridas ya es negociable en las versiones actuales de los principales navegadores y pilas TLS. La compatibilidad con ML-DSA ha llegado a las plataformas PKI empresariales convencionales, incluyendo la disponibilidad general en Microsoft Active Directory Certificate Services en Windows Server 2025 a partir de la actualización de mayo de 2026, aunque la cobertura varía según el escenario: la firma de código es la vía más fiable, mientras que los escenarios más amplios de TLS, VPN y Escritorio remoto requieren una validación específica para cada carga de trabajo. La compatibilidad con SLH-DSA existe en las principales bibliotecas criptográficas, pero se implementa en producción con mucha menos frecuencia, lo que refleja su función más específica y especializada. La compatibilidad del firmware HSM para ML-KEM y ML-DSA está disponible en el hardware de última generación de los principales proveedores, mientras que los módulos HSM más antiguos suelen requerir una actualización de firmware o una renovación del hardware antes de poder realizar operaciones PQC.

Dependencia de la migración y secuenciación

Ninguno de estos algoritmos se implementa de forma aislada, y la secuencia de ejecución es más importante que la elección del algoritmo.

1. Las jerarquías de autoridades de certificación deben migrar comenzando por la raíz. Emitir un certificado hoja en ML-DSA antes de que se migren la CA emisora ​​y la raíz sin conexión rompe la cadena de confianza que la migración pretendía establecer.
2. La preparación del HSM limita el rendimiento de la firma. Tanto ML-DSA como SLH-DSA aumentan la carga computacional y de almacenamiento por operación de firma, y ​​las particiones HSM más antiguas necesitan validación de firmware antes de que se pueda confiar en que mantengan el ritmo en producción.
3. Las construcciones híbridas dan tiempo, pero requieren una segunda migración posteriormente. Los diseños compuestos o de doble pila que combinan un algoritmo clásico con ML-KEM o ML-DSA protegen actualmente contra las implementaciones inmaduras de PQC, pero aún necesitan eliminar el componente clásico antes de la fecha de prohibición propuesta por el NIST para 2035 para los algoritmos de clave pública vulnerables a la computación cuántica.
4. El descubrimiento debe ser lo primero. Un inventario preciso de dónde se utilizan actualmente RSA, ECDSA y ECDH, con su correspondiente responsable y nivel de criticidad, es la información fundamental para cada decisión de secuenciación.

Lo que realmente recomendamos

Para la mayoría de los equipos empresariales fuera de los Sistemas de Seguridad Nacional, ML-KEM-768 para el intercambio de claves y ML-DSA-65 para la firma es la configuración predeterminada correcta: ambas se encuentran en el nivel de seguridad de Categoría 3 del NIST, ambas cuentan con un sólido soporte de biblioteca y plataforma en 2026, y ambas mantienen los tamaños de los certificados y los protocolos de enlace más manejables que los conjuntos de parámetros más altos. Los equipos que esperan vender a los Sistemas de Seguridad Nacional o a la base industrial de defensa deben diseñar para ML-KEM-1024 y ML-DSA-87 desde el principio en lugar de realizar adaptaciones posteriores, ya que CNSA 2.0 no acepta las configuraciones predeterminadas civiles. Reserve SLH-DSA para un conjunto limitado de casos de uso de firma de alta seguridad donde una segunda suposición de seguridad independiente justifique el costo de tamaño y rendimiento, no como una configuración predeterminada de propósito general. Cualquiera que sea la combinación que elija un equipo, el problema más difícil rara vez es la selección del algoritmo. Es saber dónde se están ejecutando realmente los algoritmos clásicos hoy en día, razón por la cual el descubrimiento criptográfico, no la selección de estándares, suele ser el primer obstáculo real con el que se encuentran los equipos.

Cómo puede ayudar la consultoría de cifrado

Elegir la combinación adecuada de ML-KEM, ML-DSA y SLH-DSA es una decisión que depende de los sistemas específicos de la organización, las obligaciones regulatorias y la infraestructura criptográfica actual, no de una solución predeterminada que sirva para todos. Nuestros Servicios de Asesoramiento PQC le ayudan a tomar precisamente esa decisión: evaluando qué conjuntos de parámetros se ajustan a cada categoría de sistema, secuenciando la ruta de migración de CA con prioridad raíz descrita anteriormente y creando una hoja de ruta por fases alineada con los requisitos FIPS 203, 204 y 205 y, cuando corresponda, con los requisitos de CNSA 2.0.

Este trabajo de asesoramiento solo es válido si parte de una imagen precisa de cómo se ejecutan actualmente los algoritmos clásicos. CBOM Secure crea y mantiene continuamente este inventario, mapeando cada instancia de RSA, ECDSA y ECDH, junto con las bibliotecas y particiones HSM asociadas, a los propietarios de los sistemas que deberán tomar decisiones sobre la selección de estándares descritas en esta guía. Esta información es fundamental para todas las decisiones de secuenciación de migración mencionadas anteriormente, y es la razón por la que la selección de algoritmos suele estancarse sin ella.

Ese inventario alimenta dos rutas de ejecución distintas, ya que ML-KEM y ML-DSA/SLH-DSA se gestionan a través de infraestructuras diferentes. HSM-as-a-Service lleva la decisión de establecimiento de claves ML-KEM a producción, con gestión de claves validada por FIPS para TLS, VPN y cualquier carga de trabajo de intercambio de claves. CodeSign Secure hace lo mismo para la decisión de firma ML-DSA y SLH-DSA, con firma respaldada por HSM para código, firmware y artefactos de larga duración. Cuando la decisión de firma se aplica específicamente a la emisión de certificados, CertSecure Manager emite y gestiona certificados ML-DSA e híbridos en Microsoft AD CS y otras plataformas de CA desde un único plano de políticas.

¿En qué situación quedan los equipos empresariales?

FIPS 203, 204 y 205 responden a tres preguntas de ingeniería distintas, no a una sola. ML-KEM garantiza el intercambio seguro de claves, ML-DSA se encarga de la firma de propósito general y SLH-DSA se reserva para los casos específicos en los que una segunda suposición de seguridad independiente justifica su tamaño y velocidad. Los estándares en sí están definidos; lo que aún varía según la organización es la selección de parámetros, la madurez de la implementación en las plataformas específicas que se utilizan y la secuencia necesaria para migrar una jerarquía PKI de forma segura. Los equipos que consideran la selección de estándares como la parte más difícil suelen descubrir que la verdadera limitación reside en saber dónde reside su criptografía clásica.

Preguntas frecuentes

¿Las normas FIPS 203, 204 y 205 son normas definitivas o borradores?

Las tres normas son definitivas. El Secretario de Comercio del NIST las aprobó el 13 de agosto de 2024 y entraron en vigor el 14 de agosto de 2024. Son normas aptas para la producción, no borradores, a diferencia de la norma NIST IR 8547 o el borrador FIPS 206 (FN-DSA), que permanecieron en estado de borrador hasta mediados de 2026.

¿Necesito los tres estándares o puedo elegir solo uno?

Casi todos los sistemas requieren al menos un KEM y un algoritmo de firma, por lo que ML-KEM más ML-DSA o SLH-DSA es el mínimo realista. SLH-DSA suele ser complementario a ML-DSA, en lugar de sustituirlo, y se utiliza selectivamente cuando su suposición de seguridad independiente justifica el coste de rendimiento.

¿Por qué el NIST tiene dos estándares de firma en lugar de uno?

La diversidad de algoritmos es una medida de precaución deliberada. ML-DSA y SLH-DSA se basan en supuestos matemáticos diferentes (problemas de retículos frente a seguridad de funciones hash), por lo que una futura vulnerabilidad descubierta en la criptografía de retículos no comprometería ambas a la vez. El NIST mantiene SLH-DSA específicamente como esa alternativa estructuralmente independiente.

¿Qué conjuntos de parámetros deberían utilizar las organizaciones reguladas por la CNSA 2.0?

ML-KEM-1024 para el establecimiento de claves y ML-DSA-87 para firmas, ambos en la categoría 5 del NIST. CNSA 2.0 no incluye SLH-DSA en su conjunto de algoritmos.

¿Adoptar estos estándares implica que AES también deba cambiar?

No. Las normas FIPS 203, 204 y 205 abordan la criptografía de clave pública, donde el algoritmo de Shor otorga a una computadora cuántica una ventaja exponencial. AES-256 es un algoritmo simétrico y ya se considera resistente a la computación cuántica con ese tamaño de clave, teniendo en cuenta el algoritmo de Grover.