La criptografía que usás para firmar digitalmente tiene fecha de vencimiento: qué publicó NIST y cómo migrar tu HSM

Si hoy tenés un sistema que firma digitalmente algo — un documento, un JWT, un certificado, un binario — y ese sistema usa RSA o ECDSA, NIST te está diciendo que ese sistema tiene fecha de vencimiento.

No es FUD. No es "en el futuro". Los estándares finales ya están publicados desde agosto de 2024. La migración ya arrancó en las organizaciones serias. Y el reloj corre porque hay ataques que se están ejecutando ahora mismo — aunque el resultado lo van a ver recién cuando tengan la computadora cuántica.

Voy a explicarte qué publicó NIST, qué rompe exactamente, cómo impacta a los HSMs, y qué podés hacer desde hoy.

Por qué esto es urgente aunque la computadora cuántica no exista todavía

El ataque se llama harvest now, decrypt later. Actores estatales están capturando tráfico TLS cifrado y datos firmados digitalmente hoy, los están almacenando, y esperan a tener acceso a un quantum computer suficientemente potente para romperlos.

Para el cifrado simétrico (AES, HMAC), el impacto es manejable: duplicás el tamaño de clave y listo. Para la criptografía asimétrica — RSA, ECDSA, EdDSA — Shor's algorithm la rompe completamente. No hay parche de tamaño de clave que alcance.

Si firmás documentos que tienen que ser válidos en 10 o 15 años, el problema ya es tuyo.

Qué publicó NIST en agosto de 2024

Tres estándares finales y uno en borrador. Para firma digital son relevantes tres:

FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm) El sucesor directo de ECDSA. Basado en CRYSTALS-Dilithium, que resistió varios años de criptoanálisis en la competencia de NIST. Es el que vas a usar en la práctica.

Tiene tres niveles de seguridad:

Para comparar: una firma ECDSA P-256 ocupa 64 bytes. Una firma ML-DSA-44 ocupa 2.420 bytes — casi 38 veces más. Esto importa mucho cuando firmás en volumen o cuando el tamaño del certificado tiene restricciones.

FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature) Basado en SPHINCS+. Su seguridad se basa únicamente en funciones de hash — si SHA-3 resiste, SLH-DSA resiste. Es el backup conservador para escenarios donde querés la menor cantidad posible de supuestos matemáticos. Firmas más grandes, operaciones más lentas, pero el argumento de seguridad es el más sólido de los tres.

FIPS 206 (borrador) — FN-DSA (Fast Fourier Transform-based Digital Signature) Basado en FALCON. Firmas más compactas que ML-DSA, pero la implementación en tiempo constante es notoriamente difícil — especialmente en hardware con operaciones de punto flotante. Por ahora, a menos que tengas una necesidad muy específica de tamaño, ML-DSA es la elección práctica.

Lo que cambia en tu HSM

Acá está el problema concreto para la mayoría de las implementaciones de firma digital en producción.

El tamaño de las claves explotó.

Una clave privada RSA-2048 tiene 256 bytes. Una clave privada ML-DSA-44 tiene dos representaciones: el seed compacto (32 bytes) y la clave expandida para operaciones (2.528 bytes para ML-DSA-44, 4.032 bytes para ML-DSA-65). Los HSMs están diseñados para almacenar y operar con claves RSA y ECDSA — las restricciones de memoria interna y los buffers de transferencia no necesariamente soportan estas dimensiones sin cambios.

PKCS#11 necesita actualizarse.

El estándar PKCS#11 que usan virtualmente todos los HSMs para exponer sus operaciones criptográficas no tenía OIDs ni tipos de clave para ML-DSA. Las actualizaciones de firmware de los vendors incluyen extensiones a PKCS#11 para soportar los nuevos algoritmos. Pero eso significa que tu middleware — tu librería que habla con el HSM — también tiene que actualizarse.

No todos los HSMs tienen el mismo camino.

Utimaco lanzó Quantum Protect, un paquete de aplicación que se activa en-field sobre su línea Se-Series, sin reemplazar el hardware. Se entrega vía PKCS#11 actualizado y soporta ML-KEM y ML-DSA más las firmas hash-based stateful (LMS, XMSS). Esto es buena noticia: si tenés hardware Utimaco moderno, probablemente no necesitás reemplazarlo.

Thales tiene sus HSEs (High Speed Encryptors) construidos sobre FPGAs reprogramables, lo que les da flexibilidad similar. Su línea de Luna Network HSM también está recibiendo soporte PQC.

El YubiHSM 2, que muchos usan para development o deployments pequeños, tiene restricciones de memoria que limitan su escalabilidad con claves ML-DSA expandidas. Ahí el camino puede ser reemplazo.

La validación FIPS 140-3 todavía está al día.

Un HSM que soporta ML-DSA via firmware update no tiene automáticamente la validación FIPS 140-3 para esos algoritmos. La validación requiere un proceso con laboratorio acreditado que puede tomar 12-18 meses. Si tu compliance requiere FIPS 140-3 validado para el módulo, chequeá el estado de validación de tu vendor específicamente para PQC — no asumas que el firmware update lo cubre.

El enfoque híbrido: cómo migrar sin romper nada

La recomendación práctica tanto de NIST como de los vendors es migrar en modo híbrido: firmar con el algoritmo clásico y con el algoritmo PQC simultáneamente durante el período de transición.

Esto significa:

Firma del documento = ECDSA(hash) || ML-DSA(hash)

El verificador que no soporta PQC sigue verificando con ECDSA. El verificador que sí soporta PQC puede verificar con ML-DSA. Cuando todos los participantes del sistema migraron, sacás el ECDSA.

Para certificados X.509, el IETF está trabajando en el borrador para certificados híbridos (draft-ietf-lamps-pq-composite-sigs). Ya hay implementaciones experimentales en algunos stacks.

Para JWTs y otros formatos de token, el grupo de trabajo todavía está finalizando los algoritmos. El algoritmo identifier para ML-DSA en JWA va a ser ML-DSA-44, ML-DSA-65 y ML-DSA-87 (o con el prefijo id- dependiendo del RFC final).

Lo que cambia en el código

Si hoy usás OpenSSL o una librería similar para verificar firmas, el cambio a nivel de código es más chico de lo que parece — si la librería ya soporta los nuevos algoritmos.

OpenSSL 3.x ya tiene soporte experimental para ML-DSA via el Open Quantum Safe provider. En la práctica:

# Instalar el proveedor OQS para OpenSSL 3
# (disponible en oqs-provider: https://github.com/open-quantum-safe/oqs-provider)

# Generar un par de claves ML-DSA-65
openssl genpkey -algorithm mldsa65 -out private.pem

# Generar el certificado autofirmado
openssl req -new -x509 -key private.pem -out cert.pem -days 365 \
  -subj "/CN=test/O=JuanchiDev"

# Ver el certificado — la clave pública va a ser de 1952 bytes
openssl x509 -in cert.pem -text -noout | grep "Public Key"
# Public Key Size: 1952 bytes (ML-DSA-65)

En Node.js, la librería node-forge todavía no soporta ML-DSA de forma nativa. Para producción hoy, el camino es:

1. El HSM firma via PKCS#11 con ML-DSA (cuando el vendor actualice el firmware)
2. Tu aplicación usa el binding PKCS#11 (pkcs11js en Node.js o equivalente) sin necesidad de que la librería de crypto del runtime soporte ML-DSA directamente
3. La verificación puede hacerse con liboqs via binding nativo

// Ejemplo conceptual — firma via PKCS#11 hacia HSM con ML-DSA
import { PKCS11 } from "pkcs11js"

const pkcs11 = new PKCS11()
pkcs11.load("/usr/lib/softhsm/libsofthsm2.so") // o el driver de tu HSM

// El HSM expone ML-DSA como CKM_ML_DSA (nuevo mecanismo en PKCS#11 v3.x)
const mechanism = { mechanism: pkcs11.CKM_ML_DSA }

// La API de firma es la misma que con ECDSA
// El cambio está en el mecanismo y en los handles de clave
const signature = pkcs11.C_Sign(session, data, mechanism)

// La firma va a tener 3309 bytes para ML-DSA-65
// vs 64 bytes para ECDSA P-256
console.log(`Tamaño de firma: ${signature.length} bytes`)

El punto importante: si tu arquitectura ya pasa toda la criptografía por el HSM (que es como debería ser), el cambio en el código de aplicación es mínimo. El quilombo está en actualizar el HSM, el middleware, y los certificados — no en reescribir la lógica de negocio.

El demo funcional: SoftwareHSM con ML-DSA en TypeScript

Para acompañar este post construí un proyecto que implementa todo lo que describí arriba: un HSM en software que nunca expone las claves privadas, con soporte real para ML-DSA y SLH-DSA usando @noble/post-quantum — la implementación TypeScript pura de los nuevos estándares NIST.

El repo: JuanTorchia/pq-signing-demo

git clone https://github.com/JuanTorchia/pq-signing-demo
npm install
npm run demo       # demo interactivo completo
npm run benchmark  # comparativa de tamaños y tiempos

Lo que hace el demo:

1. SoftwareHSM con 6 algoritmos

Toda la lógica de clave privada está encapsulada. El exterior solo recibe KeyPair (con la clave pública) y SignatureResult (solo la firma). Mismo modelo de seguridad que un HSM de hardware, sin el hardware.

interface HSMProvider {
  generateKeyPair(algorithm: Algorithm, label: string): Promise<KeyPair>
  sign(keyId: string, data: Uint8Array): Promise<SignatureResult>
  verify(keyId: string, data: Uint8Array, signature: Uint8Array): Promise<VerifyResult>
}

Cuando llegue el firmware de tu vendor, reemplazás la implementación. El resto del código no cambia — eso es crypto-agility en la práctica.

2. Firma de documentos

const doc = "Acuerdo de servicios — Abril 2026"
const ecdsaDoc = await signDocument(doc, "ecdsa-p256")  // 64 bytes
const mldsaDoc = await signDocument(doc, "ml-dsa-65")   // 3309 bytes

const valid = await verifyDocument(mldsaDoc)             // ✅

3. JWT con ML-DSA-65

El demo implementa el formato del borrador IETF draft-ietf-cose-dilithium, con alg: "ML-DSA-65" en el header. El token resultante tiene ~4.600 chars vs ~250 de un JWT ES256 típico. La implicancia práctica: para tokens de larga vida o firma de documentos, perfecto. Para millones de access tokens de corta vida por día, vas a querer esperar a que salga ML-DSA-44 o FN-DSA.

4. El benchmark muestra los trade-offs reales

── Tamaño de Firma ─────────────────────────────────
ecdsa-p256              ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░     64 bytes  (1x)
ml-dsa-44               █████████░░░░░░░░░░░░░░░░░░░░░   2420 bytes  (38x)
ml-dsa-65               █████████████░░░░░░░░░░░░░░░░░   3309 bytes  (52x)
slh-dsa-sha2-128s       ██████████████████████████████   7856 bytes  (123x)

── Tiempo de Firma (promedio 20 iteraciones) ───────
ecdsa-p256              ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░    0.99 ms
ml-dsa-65               ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░    4.64 ms
slh-dsa-sha2-128s       ██████████████████████████████ 3806.09 ms

SLH-DSA tiene firmas grandes Y es lento — está ahí como backup de máxima seguridad, no como reemplazo práctico de ECDSA. ML-DSA-65 a 4.6ms de firma es completamente viable en producción.

Qué hacer ahora mismo

1. Inventariá tu superficie criptográfica.

Mapeá dónde firmás digitalmente hoy: certificados TLS, firma de documentos, JWTs, firma de código, certificados de CA intermedias. Para cada uno, anotá: qué algoritmo usa, qué HSM lo respalda, y cuánto tiempo tiene que seguir siendo válida esa firma.

Los documentos firmados con ECDSA que tienen que ser válidos en 2035 son los primeros en la lista.

2. Consultá con tu vendor de HSM.

Las preguntas concretas:

• ¿Tu modelo de HSM tiene soporte ML-DSA planificado vía firmware?
• ¿En qué timeline?
• ¿El update mantiene la validación FIPS 140-3 para ML-DSA?
• ¿Cómo migran las claves existentes?

3. Empezá a probar con el stack OQS.

El proyecto Open Quantum Safe (liboqs + oqs-provider para OpenSSL) te deja experimentar con ML-DSA hoy, sin hardware real. Es el ambiente para entender cómo cambian los tamaños, los tiempos, y qué impacto tiene en tu infraestructura de certificados.

docker run -it openquantumsafe/oqs-ossl3-img
# Ya tiene OpenSSL 3 + oqs-provider instalados
openssl list -signature-algorithms | grep mldsa

4. Revisá el tamaño de firma en tus protocolos.

Si tenés un protocolo que asume firmas ECDSA de 64 bytes y vas a mover a ML-DSA-65 de 3.309 bytes, hay implicancias en MTU, en buffers, en validación de tamaño de payload. Mejor descubrirlo en staging.

5. Para sistemas nuevos: arrancá con crypto-agility desde el diseño.

Crypto-agility significa que el algoritmo de firma es configurable, no hardcodeado. La abstracción correcta:

interface SigningProvider {
  algorithm: "ecdsa-p256" | "ml-dsa-65" | "hybrid-ecdsa-mldsa65"
  sign(data: Buffer): Promise<Buffer>
  verify(data: Buffer, signature: Buffer, publicKey: Buffer): Promise<boolean>
  publicKey(): Promise<Buffer>
}

Cuando llegue el momento de migrar, cambiás la implementación, no la arquitectura.

El deadline real

La NSA requiere que todos los sistemas de seguridad nacional (NSS) completen la migración a PQC antes de 2030. NIST IR 8547 establece que los algoritmos vulnerables a quantum (RSA, ECDSA, ECDH, DH) van a ser deprecados y removidos de los estándares NIST antes de 2035.

La Comisión Europea espera que todos los estados miembro tengan un plan de migración completo implementado para fin de 2026.

No es ciencia ficción. Es un calendario de compliance que ya está corriendo.

El problema no es que la computadora cuántica exista hoy. El problema es que la infraestructura de clave pública tarda años en migrar, los certificados tienen vidas largas, y los documentos firmados hoy tienen que seguir siendo verificables en 2035. Ese tiempo ya está consumiendo.

El código de ejemplo de OpenSSL y PKCS#11 asume OpenSSL 3.x con oqs-provider y PKCS#11 v3.x con soporte ML-DSA del vendor. Para firmé digital en producción, chequeá el estado de soporte de tu HSM antes de commitear a una implementación.