ML-DSA frente a ECDSA: el paso a firmas poscuánticas

ML-DSA frente a ECDSA es la mitad de la transición poscuántica que corresponde a las firmas. ECDSA sobre P-256 da firmas de 64 bytes y está en todas partes, pero el algoritmo de Shor lo rompe. ML-DSA (FIPS 204, agosto de 2024) resiste los ataques cuánticos conocidos y es rápido, pero sus claves y firmas ocupan kilobytes. A diferencia del intercambio de claves, donde ML-KEM híbrido ya es la opción predeterminada en los navegadores, la migración de las firmas está todavía, en su mayor parte, por hacer.

De un vistazo

Las velocidades se midieron con openssl speed en un núcleo de un Apple M4 Max. El ML-DSA de OpenSSL está escrito en C portable; las implementaciones optimizadas firman varias veces más rápido.

Por qué hace falta el cambio

ECDSA se basa en el problema del logaritmo discreto en curvas elípticas, que el algoritmo de Shor resuelve de forma eficiente en una computadora cuántica grande y tolerante a fallos. Esa máquina aún no existe, y las estimaciones de cuándo podría existir varían mucho, pero las firmas tienen una propiedad que marca su urgencia: falsificar una firma más adelante no deshace una autenticación pasada. Un handshake TLS autenticado con ECDSA en 2026 no se puede atacar de forma retroactiva, como sí ocurre con los intercambios de claves capturados. Lo que sí requiere atención temprana es todo aquello cuyas firmas deban seguir siendo fiables durante muchos años: las claves de las CA raíz y de las CA intermedias, el firmware y las cadenas de arranque, las raíces de firma de código, los documentos legales y el archivado a largo plazo.

ML-DSA es una firma basada en retículos (derivada de CRYSTALS-Dilithium) cuya seguridad descansa en Module-LWE y Module-SIS, sin ninguna aceleración cuántica conocida más allá de las genéricas. NIST IR 8547 (un borrador público inicial) propone dejar de permitir ECDSA, EdDSA y RSA después de 2035, y la CNSA 2.0 de la NSA exige ML-DSA-87 para los sistemas de seguridad nacional, empezando por la firma de software y de firmware.

El problema del tamaño

El tamaño es lo que complica la migración. Un servidor TLS se autentica con una cadena de certificados y una firma en el handshake; con ECDSA, las claves del certificado hoja y del intermedio, sus firmas, dos SCT incrustados y la firma de CertificateVerify suman unos pocos cientos de bytes. Con ML-DSA-44, esos mismos elementos ocupan unos 14,7 KB (dos claves públicas de 1312 bytes más cinco firmas de 2420 bytes: dos en los certificados, dos en los SCT y la de CertificateVerify), y más aún con ML-DSA-65. Eso hace que el primer grupo de mensajes del servidor supere la ventana de congestión inicial de TCP, lo que añade viajes de ida y vuelta, y pone al límite las restricciones antiamplificación de QUIC.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
for alg in EC ML-DSA-44 ML-DSA-65; do
  if [ "$alg" = EC ]; then
    openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out key.pem 2>/dev/null
    label="ECDSA P-256"
  else
    openssl genpkey -algorithm "$alg" -out key.pem 2>/dev/null
    label="$alg"
  fi
  openssl req -new -x509 -key key.pem -subj "/CN=example.com" -days 90 -outform DER -out cert.der 2>/dev/null
  printf '%-12s certificate %5s bytes\n' "$label" "$(wc -c < cert.der | tr -d ' ')"
done
cd / && rm -rf "$dir"

ECDSA P-256  certificate   388 bytes
ML-DSA-44    certificate  3985 bytes
ML-DSA-65    certificate  5514 bytes

La respuesta de la PKI web todavía está en diseño. En febrero de 2026, Chrome anunció que piensa apoyarse en los certificados de árbol de Merkle (Merkle Tree Certificates, un Internet-Draft del grupo de trabajo PLANTS del IETF), que sustituyen la mayoría de las firmas de cada certificado por pruebas de inclusión cortas, y que no tiene previsto añadir certificados X.509 poscuánticos a su almacén raíz actual. El CA/Browser Forum aún no ha aprobado ML-DSA para los certificados TLS de confianza pública. Las PKI privadas ya pueden emitir certificados ML-DSA conforme al RFC 9881, y OpenSSL 3.5 y posteriores, Bouncy Castle y otras bibliotecas los admiten.

Opciones híbridas y compuestas

Durante la transición, muchos despliegues quieren firmas que se verifiquen tanto en clientes antiguos como en nuevos, o que sigan siendo seguras si falla cualquiera de los dos algoritmos:

• Las firmas compuestas (draft-ietf-lamps-pq-composite-sigs, todavía un Internet-Draft) definen un único identificador de algoritmo para cada combinación, como ML-DSA-65 con ECDSA P-256, cuya firma solo es válida si se verifican las dos partes. El RFC 9980 de OpenPGP sigue el mismo enfoque con ML-DSA-65+Ed25519, y OpenSSH 10.4 añadió un tipo de clave experimental ML-DSA-44+Ed25519.
• Las firmas duales adjuntan dos firmas independientes (CMS admite varias estructuras SignerInfo; algunos formatos de documento permiten varios campos de firma), de modo que cada verificador comprueba la que entiende.
• Las PKI paralelas emiten certificados clásicos y poscuánticos y dejan elegir a los clientes, que es el modelo que la negociación de TLS ya admite mediante signature_algorithms.

Cuándo elegir cada uno

• Certificados de servidor TLS públicos, llaves de acceso, OIDC y JWT públicos: ECDSA (o Ed25519) por ahora; sigue el trabajo de los navegadores y del IETF para saber cuándo cambiar.
• PKI privada para servicios y dispositivos de larga duración: ML-DSA-65, o ML-DSA compuesto con ECDSA donde haya verificadores de ambos tipos.
• Firmware y arranque seguro: ML-DSA-87 o los esquemas basados en hash LMS, XMSS o SLH-DSA, según necesites o no cumplir con CNSA 2.0.
• Firma de código y de paquetes: añade ML-DSA junto a las firmas existentes a medida que los ecosistemas (Sigstore, los fabricantes de sistemas operativos) lo vayan admitiendo.
• Cadenas de bloques: la elección no depende de ti; existen propuestas de firmas poscuánticas para varias cadenas, pero ninguna se ha desplegado de forma amplia en Bitcoin ni en Ethereum.
• Tokens y sesiones de corta duración: ECDSA sigue siendo adecuado hasta que los verificadores cambien, ya que el riesgo de falsificación solo existe mientras están vigentes.

Notas de migración

1. Haz un inventario de cada clave de firma y de cada verificador (una lista de materiales criptográficos ayuda), con la vida útil de las claves y quién verifica.
2. Elimina las suposiciones sobre el tamaño: columnas de bases de datos, límites de los encabezados HTTP (una firma ML-DSA-65 ocupa unos 4,4 KB en base64), almacenamiento de las tarjetas inteligentes, códigos QR y registros DNS.
3. Haz que los algoritmos sean negociables: identificadores de algoritmo en los formatos, listas de algoritmos permitidos en los verificadores e identificadores de clave para poder introducir claves nuevas junto a las antiguas.
4. Empieza por las raíces de larga duración: crea ya CA raíz e intermedias con ML-DSA o con firmas compuestas para las PKI privadas, porque las raíces tardan años en distribuirse.
5. Mide el rendimiento en condiciones reales: latencia del handshake con cadenas más grandes, velocidad de firma (un orden de magnitud inferior a la de ECDSA en código portable), verificación en dispositivos con recursos limitados.
6. Sigue de cerca el estado de FIPS y de las políticas: FIPS 204 es definitivo, NIST IR 8547 sigue siendo un borrador, las firmas compuestas siguen siendo borradores y las reglas de la PKI web aún no han cambiado.

Referencias

• FIPS 204, estándar de firma digital basado en retículos de módulos
• FIPS 186-5, estándar de firma digital
• RFC 9881, ML-DSA en X.509
• Borrador público inicial de NIST IR 8547
• draft-ietf-lamps-pq-composite-sigs (Internet-Draft)
• draft-ietf-plants-merkle-tree-certs (Internet-Draft)
• Programas raíz de Chrome, incluido el programa de raíces resistentes a la computación cuántica
• Preguntas frecuentes de la NSA sobre CNSA 2.0