ECDSA determinista frente a aleatorizado: RFC 6979, nonces aleatorios y hedged

ECDSA determinista frente a aleatorizado es una cuestión de un solo valor: el nonce k de cada firma. Su calidad decide si la clave privada sigue siendo privada, porque basta un nonce repetido o un ligero sesgo a lo largo de muchas firmas para calcular la clave. FIPS 186-5 permite dos formas de generarlo, y una tercera, la firma hedged, combina ambas.

De un vistazo

Cómo falla cada uno

Los nonces aleatorios dependen por completo del generador de números aleatorios. Si repite un valor (la PlayStation 3 de Sony usaba una constante), basta con álgebra elemental para obtener la clave. Si solo está sesgado, por ejemplo porque los bits superiores son siempre cero o porque un canal lateral de temporización filtra la longitud del nonce, las técnicas de retículos que resuelven el problema del número oculto recuperan la clave con solo entre unos cientos y unos miles de firmas; Minerva y TPM-Fail (2019) hicieron exactamente eso contra tarjetas inteligentes y TPM. Los dispositivos embebidos que firman poco después de arrancar, las máquinas virtuales clonadas y los procesos duplicados con fork son los entornos de riesgo clásicos.

Los nonces deterministas sacan al generador de la ecuación: k se deriva con HMAC a partir de la clave privada y el hash del mensaje, de modo que la misma entrada produce siempre el mismo nonce, y mensajes distintos producen nonces sin relación entre sí. El riesgo se traslada a los ataques físicos. Si un atacante puede provocar un fallo transitorio (glitch) en el dispositivo mientras este firma dos veces el mismo mensaje, una firma correcta y otra defectuosa con el mismo nonce pueden revelar la clave; Poddebniak y sus colegas demostraron en 2018 este tipo de ataques por inyección de fallos contra ECDSA y EdDSA deterministas. La firma determinista también hace que las firmas sean repetibles, algo que algunos protocolos buscan y que otros no deben revelar.

Los nonces hedged introducen en la derivación tanto las entradas deterministas como aleatoriedad nueva. Un generador defectuoso degrada el esquema a una firma determinista, y un ataque por inyección de fallos se encuentra con un nonce distinto cada vez. El RFC 6979 §3.6 ya admite una entrada adicional, BIP-340 recomienda 32 bytes de aleatoriedad auxiliar, ML-DSA (FIPS 204 §3.4) es hedged de forma predeterminada, y un borrador del IRTF para estandarizar ECDSA y EdDSA hedged caducó en 2025 sin llegar a ser un RFC.

Los tres producen firmas corrientes. Un verificador no puede distinguirlas, lo que también significa que no puedes auditar la estrategia de nonces de un firmante a partir de su salida, salvo si observas que mensajes idénticos producen firmas idénticas.

Qué hacen las bibliotecas

• OpenSSL firma con nonces aleatorios de forma predeterminada. OpenSSL 3.2 (noviembre de 2023) añadió RFC 6979 mediante el parámetro de firma nonce-type con valor 1, que exige indicar de forma explícita el algoritmo de resumen, y OpenSSL 3.6 llevó ECDSA determinista a su proveedor FIPS. En la línea de comandos: openssl pkeyutl -sign -pkeyopt nonce-type:1 -pkeyopt digest:sha256.
• cryptography de Python usa nonces aleatorios de forma predeterminada y ofrece ec.ECDSA(hashes.SHA256(), deterministic_signing=True) desde la versión 43.0 (julio de 2024).
• crypto.sign() de Node.js y WebCrypto usan nonces aleatorios sin opción de cambiarlo.
• @noble/curves deriva k con RFC 6979 de forma predeterminada y genera nonces hedged cuando se le pasa extraEntropy: true o bytes adicionales.
• libsecp256k1, utilizada por Bitcoin Core, aplica RFC 6979 con datos adicionales opcionales.
• EdDSA es determinista por definición (RFC 8032); algunas implementaciones de plataforma añaden aleatoriedad de todos modos.

La diferencia se ve en unas pocas líneas de Python con cryptography 46.0.3:

from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec

key = ec.generate_private_key(ec.SECP256R1())
message = b"invoice 2026-10-20 #4411"

randomized = [key.sign(message, ec.ECDSA(hashes.SHA256())) for _ in range(2)]
deterministic = [
    key.sign(message, ec.ECDSA(hashes.SHA256(), deterministic_signing=True)) for _ in range(2)
]

print("randomized signatures equal:   ", randomized[0] == randomized[1])
print("deterministic signatures equal:", deterministic[0] == deterministic[1])
for sig in randomized + deterministic:
    key.public_key().verify(sig, message, ec.ECDSA(hashes.SHA256()))
print("all four verify with the same verifier")

randomized signatures equal:    False
deterministic signatures equal: True
all four verify with the same verifier

Pruebas y reproducibilidad

La firma determinista hace posibles las pruebas de respuesta conocida (known-answer tests): el apéndice A.2 del RFC 6979 enumera las firmas esperadas para las curvas de P-192 a P-521 y otras, y la herramienta de vectores de prueba y Project Wycheproof se basan en vectores de ese tipo. Con la firma aleatorizada o hedged solo puedes probar que las firmas se verifican y que las mal formadas no. En las auditorías, el modo determinista también sirve para comprobar un firmante sospechoso: firma el mismo mensaje dos veces y mira si la salida se repite.

Para detectar una reutilización real del nonce en firmas que ya tienes, compara los valores de r entre las firmas de una misma clave; un r repetido significa un nonce repetido, y el comprobador de reutilización de nonces lo hace para un lote de firmas.

Cuándo elegir cada uno

• Servidores y CI con un generador del sistema operativo en buen estado: cualquiera de los tres es aceptable; prefiere el determinista o el hedged para eliminar una dependencia.
• Dispositivos embebidos, código de arranque temprano, máquinas virtuales clonadas: determinista o hedged, nunca puramente aleatorio.
• Hardware expuesto a atacantes (billeteras de hardware, tarjetas inteligentes, terminales de pago): hedged, junto con contramedidas frente a la inyección de fallos, como verificar cada firma antes de entregarla.
• Conjuntos de pruebas y trabajo de interoperabilidad: determinista, para que los vectores sean reproducibles.
• Protocolos en los que firmas idénticas repetidas filtrarían información (por ejemplo, que se volvió a firmar el mismo mensaje): aleatorizado o hedged.

Notas de migración

Cambiar de estrategia de nonces solo afecta al firmante. Las claves, los formatos de firma y los verificadores no cambian.

1. Comprueba qué admite tu biblioteca y sus versiones: OpenSSL 3.2 o posterior, cryptography 43 o posterior, o una biblioteca con RFC 6979 integrado.
2. Asegúrate de indicar de forma explícita el algoritmo de resumen al activar RFC 6979, ya que la derivación depende de él.
3. Añade una prueba de regresión que firme un mensaje dos veces y compruebe el comportamiento esperado (firmas iguales con la firma determinista, distintas con la hedged).
4. Cuida la calidad de la aleatoriedad de todos modos: la firma hedged sigue beneficiándose de un buen generador, y la generación de claves siempre necesita uno.
5. Revisa cualquier lugar donde se comparen o se guarden en caché firmas, porque con las firmas deterministas «misma entrada, misma salida» se cumple por primera vez.

Referencias

• RFC 6979, uso determinista de DSA y ECDSA (§3.2, §3.6, apéndice A.2)
• FIPS 186-5, §6.3 número secreto por mensaje
• FIPS 204, §3.4 firma hedged y determinista
• draft-irtf-cfrg-det-sigs-with-noise (Internet-Draft caducado)
• BIP-340, firma predeterminada con aleatoriedad auxiliar
• Minerva: ataques de retículos a las filtraciones del nonce de ECDSA
• OpenSSL CHANGES (3.2.0: compatibilidad con RFC 6979)
• Registro de cambios de pyca/cryptography (43.0.0: ECDSA determinista)