ECDSA frente a RSA: qué algoritmo de firma usar y cuándo

Dos algoritmos, un mismo trabajo

Las firmas RSA se basan en la exponenciación modular con un módulo compuesto grande: la clave privada se deriva de dos números primos secretos, y la dificultad de factorizar su producto es lo que mantiene la clave en privado. ECDSA (algoritmo de firma digital de curva elíptica, estandarizado en FIPS 186-5), en cambio, trabaja en el grupo de puntos de una curva elíptica, donde el problema difícil es el logaritmo discreto de curva elíptica.

La consecuencia práctica de que los problemas difíciles sean distintos: los ataques contra la factorización escalan mejor que los ataques contra el logaritmo discreto de curva elíptica, así que las claves RSA tienen que crecer mucho más deprisa que las claves EC para conservar el mismo margen de seguridad. Ese único hecho explica la mayor parte de las diferencias de tamaño y de rendimiento que verás a continuación.

Tamaño: claves y firmas con la misma fortaleza

La comparación de fortalezas de seguridad del NIST (consulta SP 800-57 Part 1) sitúa una clave de curva elíptica de 256 bits en la misma clase de seguridad de 128 bits que un módulo RSA de 3072 bits:

(*codificación del punto sin comprimir / punto comprimido). En el nivel de 128 bits —el mínimo para los sistemas nuevos hoy en día—, una firma ECDSA P-256 ocupa 64 bytes frente a los 384 bytes de RSA-3072, y la clave pública mide aproximadamente una décima parte. Incluso RSA-2048, muy extendido (y con menos margen), produce firmas de 256 bytes. Donde cada byte cuenta —certificados en un handshake TLS, tokens en un encabezado HTTP, transacciones en una cadena de bloques—, las curvas elípticas ganan en tamaño, siempre.

Fíjate en las dos cifras de la firma ECDSA: 64 bytes «en bruto» frente a ~70–72 bytes con codificación DER. La misma firma matemática tiene dos codificaciones habituales para transmitirse, y confundirlas es una de las causas más frecuentes de los errores «invalid signature». El tema tiene su propio artículo.

Velocidad: la asimetría entre firma y verificación

Los dos algoritmos tienen perfiles de rendimiento opuestos, y conviene interiorizar esa asimetría porque decide arquitecturas reales:

• La verificación RSA es muy rápida. Verificar supone una sola exponenciación modular con el exponente público, que casi siempre es el valor pequeño 65537. Por eso RSA aguantó tanto tiempo en las cadenas de certificados: un certificado se firma una vez y se verifica miles de millones de veces.
• La firma RSA es lenta, porque eleva al exponente privado de tamaño completo sobre un módulo de 2048 a 4096 bits. La generación de claves RSA es aún más lenta: tiene que buscar números primos aleatorios grandes, lo que puede llevar fracciones apreciables de segundo y varía de forma impredecible.
• La firma ECDSA es rápida: una multiplicación escalar sobre un campo de 256 bits, normalmente entre varias veces y un orden de magnitud más rápida que una firma RSA-2048, y con una diferencia mucho mayor frente a RSA-3072. Generar una clave EC sale prácticamente gratis (una multiplicación escalar), lo que importa para las claves efímeras y las claves por dispositivo.
• La verificación ECDSA es más lenta que la verificación RSA (aproximadamente dos multiplicaciones escalares), aunque en el hardware actual sigue siendo rápida en términos absolutos.

Puedes ver la diferencia de tamaño directamente con unas pocas líneas de Node.js:

import { generateKeyPairSync, sign } from "node:crypto";

const message = Buffer.from("measure me");

const ec = generateKeyPairSync("ec", { namedCurve: "P-256" });
const rsa = generateKeyPairSync("rsa", { modulusLength: 3072 }); // slow: prime search

const ecSig = sign("sha256", message, ec.privateKey);  // DER-encoded by default
const rsaSig = sign("sha256", message, rsa.privateKey);

console.log("ECDSA P-256:", ecSig.length, "bytes"); // ~70-72 (64 raw)
console.log("RSA-3072:  ", rsaSig.length, "bytes"); // 384

Dónde se usa cada uno hoy

• TLS / X.509. Los dos están en todas partes. RSA sigue dominando el parque de certificados instalados, pero las grandes CA emiten certificados ECDSA (P-256, P-384) de forma habitual, y estos reducen notablemente el tamaño del handshake; muchos sitios grandes sirven ECDSA con RSA como alternativa. TLS 1.3 admite de forma nativa ambas familias de firma.
• SSH. El ecosistema ya usa curvas elípticas: Ed25519 (un esquema de firma EC emparentado, no ECDSA) es la opción por defecto habitual para claves nuevas, y ECDSA P-256 también es frecuente. Las claves RSA siguen funcionando, pero las versiones recientes de OpenSSH desactivan por defecto el esquema de firma heredado ssh-rsa (basado en SHA-1): las claves RSA deben usar las variantes SHA-2.
• JWT. RS256 (RSA) es la opción por defecto histórica del ecosistema de identidad; ES256 (ECDSA P-256) es la opción moderna y compacta, y la exigen varias plataformas (las API de tokens de Apple, DPoP, la mayoría de las credenciales WebAuthn y de llaves de acceso). Los pros y contras son lo bastante concretos como para que les dediquemos una guía aparte: ES256 frente a RS256 en JWT. Puedes inspeccionar tokens reales con el decodificador de JWT.
• Cadenas de bloques. En la práctica, territorio exclusivo de ECDSA: Bitcoin y Ethereum firman con ECDSA sobre la curva secp256k1 (Bitcoin adoptó además las firmas Schnorr con Taproot). El tamaño de las firmas RSA lo descarta de entrada allí donde se paga por cada byte de la transacción.
• Firma de código y firmware. Históricamente dominados por RSA, cada vez más mixtos; los dispositivos con recursos limitados prefieren ECDSA por sus claves pequeñas y su firma rápida y con poco consumo de memoria.

El inconveniente de ECDSA: el nonce tiene que ser perfecto

ECDSA tiene un requisito operativo que RSA sencillamente no tiene: cada firma consume un número secreto nuevo k (el nonce, un número de un solo uso), y la seguridad del esquema depende de que ese número sea único y uniformemente aleatorio en todas y cada una de las firmas. Los modos de fallo no perdonan:

• Si alguna vez se usa el mismo k para dos mensajes distintos con una misma clave, la clave privada se puede calcular a partir de las dos firmas con álgebra elemental. Es exactamente lo que ocurrió en el famoso incidente de la PlayStation 3 en 2010, en el que un nonce constante dejó al descubierto la clave de firma de la consola.
• Incluso un nonce parcialmente predecible o con un ligero sesgo, observado a lo largo de muchas firmas, puede bastar para reconstruir la clave con técnicas basadas en retículos. Por eso, un generador de números aleatorios del sistema que sea débil en el momento de firmar supone un riesgo de compromiso de la clave, no solo un problema de calidad.

La respuesta estándar es ECDSA determinista, especificado en RFC 6979: derivar k de la clave privada y del resumen del mensaje mediante HMAC, de modo que la misma entrada produzca siempre el mismo nonce, bien distribuido, y no haga falta aleatoriedad en el momento de firmar. FIPS 186-5 ya permite ECDSA determinista, y la mayoría de las bibliotecas modernas implementan RFC 6979 o una variante hedged (derivación determinista combinada con entropía adicional). Al elegir una biblioteca, es una de las primeras cosas que hay que comprobar. RSA, en cambio, no necesita aleatoriedad por firma con PKCS#1 v1.5, y la sal aleatoria de RSA-PSS no compromete la clave si se repite.

El reloj poscuántico corre para los dos

Elijas el que elijas, planifica su retirada. Una computadora cuántica lo bastante grande que ejecute el algoritmo de Shor rompe por igual la factorización y el logaritmo discreto de curva elíptica: RSA y ECDSA caen juntos. El NIST ha esbozado el calendario de transición en NIST IR 8547 (todavía un borrador público inicial): los algoritmos de firma clásicos —ECDSA, EdDSA y RSA— quedan prohibidos después de 2035 para uso federal, con cualquier conjunto de parámetros. Un hito anterior afecta solo al nivel de seguridad de 112 bits, que en firmas significa RSA-2048 y P-224: estos quedan obsoletos después de 2030, es decir, todavía se pueden usar, pero con un riesgo reconocido. La fecha de 2030 no afecta a P-256, P-384 ni RSA-3072, una distinción que conviene tener clara porque cambia cuáles de tus claves necesitan atención primero.

Los sucesores designados son ML-DSA (basado en retículos, estandarizado en FIPS 204) y SLH-DSA (basado en hash, FIPS 205), y después llegará FN-DSA, derivado de Falcon. Prepárate para un choque de tamaños: una firma ML-DSA-65 ocupa unos 3,3 KB —cincuenta veces una firma P-256—, y por eso el trabajo de protocolos sobre certificados híbridos y compuestos sigue en curso. La conclusión práctica para hoy no es «adopta PQC en todas partes ya», sino construye agilidad criptográfica: identifica todos los lugares donde firman tus sistemas, mantén configurable la elección de algoritmos y evita fijar en el código los tamaños de clave o de firma.

Entonces, ¿cuál deberías usar hoy?

¿Quieres ver las diferencias con bytes reales? Genera o pega una firma en el verificador de firmas ECDSA: detecta automáticamente la curva y la codificación, y muestra exactamente qué verifica.