Saltar al contenido
ecdsa.com

FN-DSA (Falcon) frente a ML-DSA: tamaño o sencillez

Las firmas de Falcon ocupan aproximadamente una cuarta parte de lo que ocupan las de ML-DSA, algo que importa en los certificados y en los enlaces con recursos limitados. ML-DSA está estandarizado, es más fácil de implementar de forma segura y hoy es la opción por defecto.

FN-DSA frente a ML-DSA compara los dos esquemas de firma basados en retículos que el NIST seleccionó en 2022. ML-DSA (derivado de CRYSTALS-Dilithium) se convirtió en FIPS 204 en agosto de 2024. FN-DSA, el nombre que el NIST da a Falcon, está en proceso de estandarización como FIPS 206, que en octubre de 2026 seguía siendo un borrador. Falcon es mucho más compacto; ML-DSA es mucho más fácil de implementar correctamente.

De un vistazo

FN-DSA-512 (Falcon-512)ML-DSA-44FN-DSA-1024 (Falcon-1024)ML-DSA-87
Categoría de seguridad1255
Clave pública897 bytes1312 bytes1793 bytes2592 bytes
Firma666 bytes (con relleno)2420 bytes1280 bytes (con relleno)4627 bytes
Clave pública + firma1563 bytes3732 bytes3073 bytes7219 bytes
Familia de retículosNTRUModule-LWE / Module-SISNTRUModule-LWE / Module-SIS
Aritmética de la firmaPunto flotante (muestreo gaussiano discreto)Solo enterosPunto flotanteSolo enteros
EstándarBorrador de FIPS 206FIPS 204 (definitivo, 2024)Borrador de FIPS 206FIPS 204
X.509Aún sin estandarizarRFC 9881Aún sin estandarizarRFC 9881

Los tamaños de Falcon proceden de la especificación de Falcon (las firmas también pueden usar una codificación comprimida de longitud variable de 752 y 1462 bytes como máximo); los de ML-DSA, de la tabla 2 de FIPS 204. ML-DSA-65 (categoría 3) no tiene equivalente en Falcon.

Por qué importa el tamaño

Falcon produce un vector corto en un retículo NTRU mediante una trampilla y un muestreo rápido de Fourier, lo que da la suma de clave pública y firma más pequeña de todas las firmas poscuánticas del NIST: unos 1,6 KB en la categoría 1, frente a 3,7 KB de ML-DSA-44. En una cadena de certificados TLS, donde cada certificado lleva una clave pública y una firma y el handshake añade más firmas y SCT, esa diferencia separa una cadena que aproximadamente duplica su tamaño de otra que lo cuadruplica. DNSSEC, donde las firmas deben caber en respuestas UDP, y las cadenas de bloques, donde cada byte cuesta comisiones, lo notan todavía más.

Por qué lo difícil es la implementación

El algoritmo de firma de Falcon toma muestras de una distribución gaussiana discreta sobre el retículo con aritmética de punto flotante. Eso crea tres problemas que ML-DSA no tiene:

  • Tiempo constante. En algunas CPU, las operaciones de punto flotante pueden tardar un tiempo que depende de los datos, y emularlas con enteros es lento; trabajos de investigación han demostrado ataques en los que las fugas de tiempo del muestreador revelan las claves.
  • Facilidad de prueba. Dos implementaciones correctas pueden producir firmas distintas para la misma entrada por culpa del redondeo, así que las pruebas de respuesta conocida no detectan un muestreador con un sesgo sutil, y un muestreador sesgado sigue produciendo firmas válidas mientras filtra información sobre la clave. En septiembre de 2026, el equipo de FIPS 206 del NIST propuso un procedimiento de firma en punto fijo precisamente para que las implementaciones sean deterministas y se puedan probar.
  • Portabilidad. Los procesadores embebidos sin unidad de punto flotante necesitan emulación por software, lo que cuesta velocidad y tamaño de código.

ML-DSA solo usa aritmética de enteros módulo 8.380.417 con muestreo por rechazo; es sencillo hacer que se ejecute en tiempo constante y FIPS 204 especifica por completo sus salidas. La verificación es fácil en ambos, y Falcon verifica especialmente rápido: la implementación de referencia del equipo de Falcon indica unas 27.900 verificaciones y 5900 firmas Falcon-512 por segundo en un Intel Core i5-8259U a 2,3 GHz. En un núcleo de un Apple M4 Max, el código portable de ML-DSA-44 de OpenSSL 3.6.5 alcanzó unas 20.800 verificaciones y 3900 firmas por segundo. Las máquinas son distintas, así que toma estas cifras como órdenes de magnitud y no como una comparación directa.

Estado de la estandarización

  • ML-DSA: definitivo desde el 13 de agosto de 2024 (FIPS 204), con identificadores X.509 (RFC 9881), perfiles para CMS y OpenPGP, elegido por CNSA 2.0 (ML-DSA-87) y con módulos validados.
  • FN-DSA: el NIST anunció en julio de 2022 que estandarizaría Falcon y planificó FIPS 206 para después de FIPS 204 y 205. En 2025, personal del NIST afirmó que el borrador público inicial estaba prácticamente redactado y a la espera de aprobación; en octubre de 2026 no existe ningún estándar definitivo, y la propuesta de punto fijo de septiembre de 2026 muestra que la especificación sigue cambiando. Los borradores del IETF para FN-DSA en JOSE, COSE y X.509 siguen la evolución del FIPS.

Como FIPS 206 puede diferir de la especificación de Falcon de la tercera ronda, las implementaciones escritas hoy quizá necesiten cambios para ajustarse al estándar definitivo.

Cuándo elegir cada uno

  • Firma poscuántica de uso general hoy: ML-DSA (44 o 65).
  • Despliegues guiados por el cumplimiento normativo (FIPS 140-3, CNSA 2.0): ML-DSA; FN-DSA no se puede validar hasta que FIPS 206 sea definitivo.
  • Protocolos con muchos certificados en el futuro (cadenas TLS, DNSSEC, actualizaciones de IoT con recursos limitados): sigue de cerca FN-DSA; es la vía más probable para mantener manejable la sobrecarga de las firmas sin cambiar la estructura del protocolo.
  • Hardware sin punto flotante o con requisitos estrictos frente a los canales laterales: ML-DSA, o Falcon solo con una implementación contrastada que use enteros y se ejecute en tiempo constante.
  • Raíces de larga duración en las que el tamaño es irrelevante: SLH-DSA, cuya seguridad se basa únicamente en funciones hash, o ML-DSA; ahí las firmas pequeñas de FN-DSA no aportan nada.

Notas de migración

  1. Diseña pensando en la agilidad criptográfica: incluye identificadores de algoritmo, evita tamaños de firma fijos y prepárate para añadir FN-DSA como segunda opción poscuántica junto a ML-DSA.
  2. Haz prototipos con cuidado: usa bibliotecas que implementen el muestreador de Falcon en tiempo constante y marquen su salida como previa al estándar; no las incluyas donde se exija un estándar.
  3. Mide el presupuesto de tamaño de tu protocolo con ML-DSA hoy; si cabe, puede que allí nunca necesites FN-DSA.
  4. Sigue la versión definitiva de FIPS 206: los nombres de los parámetros, las codificaciones y el procedimiento de firma pueden diferir de los de Falcon de la tercera ronda, y los vectores de prueba cambiarán en consecuencia.
  5. Ten presentes los esquemas híbridos: durante la transición, las firmas compuestas combinan un esquema poscuántico con ECDSA o EdDSA, sea cual sea el esquema de retículos que elijas.

Referencias

Todas las comparaciones