RSA-2048 o RSA-4096: tamaño, velocidad y el plazo de 2030

RSA-2048 frente a RSA-4096 es la duda sobre el tamaño de clave más frecuente en PKI. RSA-2048 es el mínimo permitido para los certificados de confianza pública y se sitúa en el nivel de seguridad de 112 bits del NIST; RSA-4096 queda muy por encima de los 128 bits. El coste de la clave más grande se nota en el tiempo de firma, en el tiempo de generación de claves y en cada firma que viaja por la red, así que la respuesta correcta depende de la frecuencia con la que firma una clave y del tiempo durante el que debe seguir siendo fiable.

De un vistazo

Medido con openssl speed rsa2048 rsa3072 rsa4096 en un núcleo de un Apple M4 Max.

Margen de seguridad

La seguridad de RSA se basa en la dificultad de factorizar el módulo con la criba general del cuerpo de números, cuyo coste crece de forma subexponencial con el tamaño de clave; por eso las claves RSA tienen que crecer mucho más deprisa que las claves de curva elíptica. NIST SP 800-57 Part 1 equipara RSA de 2048 bits a una seguridad de 112 bits, 3072 bits a 128 y 7680 a 192; no incluye ninguna fila para 4096 bits, que queda entre 128 y 192. El mayor número del desafío RSA factorizado públicamente tiene 829 bits (RSA-250, 2020), muy lejos de 2048.

El plazo que más importa es el cuántico. El algoritmo de Shor factoriza los tres tamaños en tiempo polinómico en una computadora cuántica grande y tolerante a fallos, y duplicar la clave aproximadamente duplica los cúbits y alarga moderadamente el tiempo de ejecución; no cambia el resultado. La estimación de Craig Gidney de 2025 situaba RSA-2048 en menos de una semana con menos de un millón de cúbits ruidosos. Por eso NIST IR 8547 (un borrador público inicial) propone la misma fecha final, 2035, para todos los tamaños de RSA, y además propone declarar RSA-2048 obsoleto después de 2030 por su nivel clásico de 112 bits. RSA-4096 amplía tu margen frente a los ataques clásicos; no retrasa tu fecha límite poscuántica.

Rendimiento

El coste de las operaciones con la clave privada crece aproximadamente con el cubo del tamaño del módulo, y el de las operaciones con la clave pública, con el cuadrado:

openssl speed -seconds 2 rsa2048 rsa3072 rsa4096

                   sign    verify    encrypt   decrypt   sign/s verify/s  encr./s  decr./s
rsa  2048 bits 0.000334s 0.000009s 0.000009s 0.000339s   2994.9 114178.1 108513.6   2950.3
rsa  3072 bits 0.000957s 0.000019s 0.000019s 0.000965s   1044.7  53948.7  52312.0   1036.7
rsa  4096 bits 0.002117s 0.000032s 0.000032s 0.002121s    472.4  31522.3  30870.7    471.6

En un servidor TLS que firma una vez por cada handshake completo, pasar de 2048 a 4096 multiplica ese coste aproximadamente por seis. En una CA raíz que firma unos pocos certificados intermedios por década, el coste es irrelevante. La generación de claves también se ralentiza mucho, porque busca dos números primos grandes: unos 26 ms de media para 2048 bits en esta máquina frente a un cuarto de segundo para 4096, con una cola larga, lo que importa en dispositivos pequeños y en pruebas que generan claves una y otra vez.

La verificación sigue siendo barata con cualquier tamaño porque el exponente público es pequeño (65537); por eso RSA conserva su lugar en las cadenas de certificados, que se verifican miles de millones de veces.

Límites del hardware y de los protocolos

Los límites de tamaño vienen más del entorno que del propio RSA:

• Tarjetas inteligentes y tokens: muchas tarjetas PIV y tokens de seguridad antiguos solo admiten RSA-2048; los dispositivos más recientes añaden 3072 y 4096. Compruébalo antes de pedir el hardware.
• HSM y KMS en la nube: los tres tamaños son estándar (AWS KMS ofrece RSA_2048, RSA_3072 y RSA_4096), pero los precios por operación y los límites de rendimiento hacen que 4096 salga bastante más caro con mucho volumen.
• DNS: una clave DKIM de 4096 bits ocupa 736 caracteres base64 y hay que dividirla en varias cadenas TXT; algunos proveedores de DNS y resolvedores antiguos gestionan mal los registros largos. Las zonas DNSSEC con RSA-4096 producen respuestas grandes que pueden requerir TCP.
• Cadenas de certificados: cada certificado RSA-4096 añade unos 512 bytes de firma y 550 bytes de clave, frente a unos pocos cientos de bytes con ECDSA, lo que importa en clientes con recursos limitados.

Cuándo elegir cada uno

• Certificados nuevos de servidor TLS: primero ECDSA P-256; si tiene que ser RSA, todos los clientes y todas las CA siguen aceptando RSA-2048, pero RSA-3072 da margen más allá de 2030.
• CA raíz y CA intermedias de larga duración: RSA-4096 (o ECDSA P-384); el coste de firma es despreciable y la vida útil es larga. ISRG Root X1, la raíz de Let's Encrypt, es RSA-4096, mientras que sus certificados intermedios RSA son RSA-2048.
• Firma de JWT (RS256): RSA-2048 es habitual y está permitido (el RFC 7518 exige al menos 2048), RSA-3072 para claves nuevas; plantéate usar ES256 en su lugar.
• Claves SSH: elige Ed25519; si es RSA, al menos 3072.
• Claves de firma de código y de documentos: RSA-3072 o 4096, según lo que ofrezca la CA y la vida esperada de la firma, más sellos de tiempo.
• Hardware con recursos limitados: lo que admita, normalmente RSA-2048, con un plan de sustitución documentado.

Notas de migración

Cambiar el tamaño de la clave RSA implica un par de claves nuevo y, en el caso de los certificados, un certificado nuevo.

1. Haz inventario de las claves por tamaño: certificados (openssl x509 -noout -text), JWKS (longitud de n), claves SSH (ssh-keygen -l), registros DKIM e identificadores de claves en los HSM. Las claves RSA-2048 cuya vida útil va más allá de 2030 son las primeras que hay que rotar.
2. Genera las claves nuevas donde van a residir: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072, o el equivalente del HSM; evita exportar claves para cambiarles el tamaño.
3. Mantén en paralelo las claves antiguas y las nuevas: publica ambas en el JWKS con valores de kid distintos, añade el selector DKIM nuevo antes del cambio y sirve las dos claves de host SSH durante la transición.
4. Prueba con la clave más grande los sistemas que la consumen: los búferes de tamaño fijo, los límites de los registros DNS y las pilas TLS embebidas son los fallos habituales.
5. Aprovecha la rotación para replantearte el algoritmo: si todos los consumidores admiten ECDSA o EdDSA, abandonar RSA por completo suele ser mejor inversión, y las firmas poscuánticas exigirán otra rotación antes de 2035.

Referencias

• NIST SP 800-57 Part 1 Rev. 5, tabla 2
• Borrador público inicial de NIST IR 8547
• FIPS 186-5 §5, RSA
• RFC 8017, PKCS #1 v2.2
• RFC 7518 §3.3, tamaño mínimo de clave RSA para JWS
• Gidney (2025), factorización de RSA-2048 con menos de un millón de cúbits ruidosos
• CA/Browser Forum Baseline Requirements §6.1.5