Algoritmos PQC del NIST: Diferencias e Implementación.

NIST significa National Institute of Standards and Technology (Instituto Nacional de Estándares y Tecnología). Es una agencia del gobierno de los Estados Unidos que forma parte del Departamento de Comercio, y su misión es promover la innovación y la competitividad industrial mediante el avance en la ciencia de la medición, los estándares y la tecnología. El NIST juega un papel importante en crear estándares y guías para la ciberseguridad. Esto incluye algoritmos de criptografía, como los de criptografía poscuántica (PQC).

NIST ha publicado las especificaciones finales de los algoritmos de criptografía poscuántica. Esto genera la pregunta: ¿cuáles son las diferencias entre el borrador público inicial y la versión final?

Analizaremos los cambios en los algoritmos PQC de NIST y la dificultad de implementar los nuevos estándares.

Cómo surgieron los algoritmos PQC del NIST

En 2016, NIST inició una competencia para abordar las amenazas de la computación cuántica sobre la criptografía de clave pública. Se seleccionaron cuatro algoritmos: un mecanismo de encapsulación de claves (KEM) y tres esquemas de firma digital. Los borradores iniciales se publicaron el 24 de agosto de 2023, y las versiones finales el 13 de agosto de 2024.

Durante el transcurso de la competencia, los nombres de los esquemas seleccionados sufrieron algunos cambios:

El Estándar Federal de Procesamiento de Información (FIPS) 203, denominado en las especificaciones como ML-KEM, es un KEM basado en Redes Modulares inicialmente presentado bajo el nombre de CRYSTALS-Kyber.

FIPS 204, conocido como ML-DSA en las especificaciones, es un Algoritmo de Firma Digital basado en Redes Modulares presentado originalmente como CRYSTALS-Dilithium.

FIPS 205, etiquetado como SLH-DSA en las especificaciones, es un esquema de firma sin estado basado en hash que comenzó como Sphincs+.

FIPS-206, designado FN-DSA (Algoritmo de Firma Digital basado en Redes NTRU y Transformada de Fourier Rápida), fue presentado originalmente como FALCON. Las especificaciones finales para este candidato aún no se incluyeron en el lanzamiento reciente.

Comparación entre el IPD y las versiones finales

Cada algoritmo fue revisado varias veces durante la competencia. Las revisiones incluyeron cambios pequeños en el orden de los bytes. También hubo cambios grandes en su estructura. Con cada actualización, la comunidad criptográfica ajustaba sus implementaciones para mantenerse al día con las últimas versiones. El lanzamiento del borrador final también requirió nuevas actualizaciones en las implementaciones.

Hemos hecho una comparación de tres aspectos clave de cada algoritmo estandarizado. Esto va desde el IPD hasta la versión final. Destacamos las principales diferencias, la interoperabilidad y la dificultad de implementar los cambios.

ML-KEM/FIPS 203

Diferencias

La principal diferencia radica en cómo se generan los valores públicos ⍴ y la semilla secreta σ. En el nuevo enfoque, estos valores se obtienen con un separador de dominios. Este separador usa un parámetro 𝐾. Este parámetro es específico para cada variante de ML-KEM. Este parámetro actúa como un identificador único en el proceso. Ahora, los valores ⍴ y σ se generan mediante la función hash 𝐺, invocando 𝐺(𝑟𝑎𝑛𝑑𝑜𝑚_𝑠𝑒𝑒𝑑∣∣𝐾) en lugar del método anterior 𝐺(𝑟𝑎𝑛𝑑𝑜𝑚_𝑠𝑒𝑒𝑑), asegurando la integración de 𝐾 en la generación.

Interoperabilidad

No habrá problemas de compatibilidad entre las versiones temporales de ML-KEM. Estas versiones seguirán la especificación IPD. También serán compatibles con la versión final del borrador. Esto es porque el valor ⍴, que está en la clave pública, se mantiene constante. Los procesos de encapsulación y decapsulación no dependen de cómo se calcule ⍴.

En versiones estáticas de ML-KEM puede haber incompatibilidades, especialmente al cargar claves privadas generadas con la versión IPD en una versión final validada por FIPS. Esta incompatibilidad depende de cómo se realice la prueba de consistencia. Aunque es una posibilidad, es poco probable y se puede descartar en la mayoría de los casos.

Dificultad de cambio

El cambio es trivial.

ML-DSA/FIPS 204

Diferencias

La nueva especificación incorpora una variante de hash-then-sign, llamada HashML-DSA. Aunque la generación de claves (Keygen) permanece sin cambios, se han añadido nuevas funciones de firma y verificación: HashML-DSA.Sign (Algoritmo 4) y HashML-DSA.Verify (Algoritmo 5). Además, se recomienda utilizar identificadores de objetos (OIDs) distintos para diferenciar ML-DSA de HashML-DSA.

Se añadió un nuevo parámetro llamado "cadena de contexto" a las funciones de firma y verificación. Este parámetro se coloca antes del mensaje. Además, se indica su longitud antes de firmarlo. En la verificación de firmas, la función HintBitUnpack (Algoritmo 21, antes Algoritmo 15 en el IPD) ahora incluye una verificación para detectar indicaciones malformadas, reintroducida para prevenir desbordamientos de búfer.

Se han modificado las reglas para generar el desafío del verificador. Ahora se utiliza el hash completo del compromiso en lugar de solo los primeros 256 bits para la función SampleInBall. Este cambio afecta a ML-DSA-65 y ML-DSA-87, pero no a ML-DSA-44, cuyo hash ya genera 256 bits. Además, la generación de los valores públicos ⍴ y las semillas secretas ⍴' y 𝐾 ahora utiliza un separador de dominios que incluye los parámetros 𝐾 y 𝐼, específicos de cada variante de ML-DSA. Estos valores se generan con la función hash 𝐻 invocando 𝐻(𝑟𝑎𝑛𝑑𝑜𝑚_𝑠𝑒𝑒𝑑∣∣𝐾∣∣𝐼), en lugar del método anterior 𝐻(𝑟𝑎𝑛𝑑𝑜𝑚_𝑠𝑒𝑒𝑑).

Por último, la función ExpandMask, que se utiliza para calcular el compromiso del firmante, supuestamente se modificó. Sin embargo, al examinar los dos algoritmos (Algoritmo 34; anteriormente Algoritmo 28 en IPD), no se observaron diferencias.

Interoperabilidad

La introducción del parámetro de cadena de contexto en la firma rompe completamente la interoperabilidad. Aunque este parámetro no sea visible para los clientes, la compatibilidad retroactiva queda comprometida. Por lo tanto, HashML-DSA no es compatible con ML-DSA, ni ahora ni en el futuro.

Dificultad de cambio

La integración de ML-DSA y HashML-DSA a nivel de protocolo presentará importantes desafíos. Las diferencias y la falta de uso de HashML-DSA para firmar complican la implementación del protocolo.

SLH-DSA/FIPS 205

Diferencias

Se ha introducido la variante HashSLH-DSA en la especificación, manteniendo la función de generación de claves, pero añadiendo nuevas funciones de firma y verificación: hash_slh_sign (Algoritmo 23) y hash_slh_verify (Algoritmo 25). No se mencionan diferencias en los identificadores de objetos (OID) entre SLH-DSA y HashSLH-DSA. Además, se incorpora un parámetro adicional, la cadena de contexto, que se antepone al mensaje y su longitud antes de firmarlo.

Interoperabilidad

Debido a la adición de la cadena de contexto de la firma, no hay compatibilidad retroactiva para SLH-DSA. En el futuro, HashSLH-DSA no será compatible con SLH-DSA.

Dificultad de cambio

La adición de las variantes hash-then-sign presenta los mismos desafíos que las versiones hash-then-sign de ML-DSA. Una vez que se resuelvan los desafíos asociados con ML-DSA, esas soluciones se aplicarán directamente a SLH-DSA. Todos los demás cambios son triviales.

¿Qué sigue para PQC?

El concepto de firmas separadas por dominios en operaciones de hash-then-sign es nuevo para NIST. Este tema necesita un análisis más profundo. Es importante gestionar bien la cadena de contexto en las firmas. Se sugiere consultar a expertos para establecer un estándar adecuado. Esta opción podría ocultarse para facilitar su uso.

La implementación será rápida. Sin embargo, el principal desafío es crear vectores de prueba. También es necesario realizar pruebas de compatibilidad, las cuales aún no existen. DigiCert ha agregado algoritmos de criptografía post-cuántica (PQC) a sus productos. Su plataforma DigiCert® ONE PKI y el SDK TrustCore ahora son compatibles con ML-KEM/FIPS 203 y firmas PQC.

Conclusión

El NIST está trabajando en algoritmos de criptografía poscuántica. Este trabajo es una colaboración entre universidades y empresas. El objetivo es protegerse de las amenazas que presentan las computadoras cuánticas. Las mejoras entre el borrador inicial y las versiones finales se centran en aumentar la resistencia y eficiencia de los algoritmos.

A pesar de los desafíos de interoperabilidad, la adopción de los nuevos estándares será factible y no debería retrasarse. DigiCert ha liderado este proceso. Han adaptado sus productos y plataformas. Esto asegura una transición fácil hacia un futuro seguro contra amenazas cuánticas.