Cómo funciona RSA: llaves, números primos y por qué 1024 bits ya no basta, con un demostrador

Cada vez que ves el candado en el navegador, entras a un servidor por SSH o instalas una actualización firmada, es muy probable que RSA esté trabajando. Es el sistema de criptografía de llave pública más usado de la historia, y su idea cabe en una frase: multiplicar dos números primos es fácil, pero separar el resultado en esos dos primos es dificilísimo. Esta guía lo explica desde cero, con números que caben en una calculadora, y después cuenta qué tamaño de llave usar hoy, por qué 1024 bits ya no alcanza y qué cambia con las computadoras cuánticas.

La idea: un candado que cualquiera cierra

Imagina que repartes por todo el mundo copias de un candado abierto. Cualquiera puede meter un mensaje en una caja y cerrarla con tu candado, pero solo tú tienes la llave que lo abre. Nadie tuvo que mandarte un secreto antes: el candado se puede regalar sin riesgo. Eso es la criptografía de llave pública, y RSA fue el primer sistema práctico para hacerlo con números.

• La llave pública es el candado: se publica, va dentro de los certificados y se la das a quien sea.
• La llave privada es la que abre: nunca sale de tu computadora o de tu servidor.
• Y funciona también al revés: lo que tú «sellas» con la privada, cualquiera puede comprobar con la pública que salió de ti. Eso es una firma digital.

Lo publicaron en 1977 Ron Rivest, Adi Shamir y Leonard Adleman, del MIT; el nombre son sus iniciales. Años después se supo que Clifford Cocks, matemático de la agencia de inteligencia británica GCHQ, había llegado a la misma idea en 1973, pero su trabajo fue secreto hasta 1997.

Dónde lo usas sin saberlo

• Certificados de los sitios web. Cuando una autoridad certificadora firma el certificado de un sitio, muy a menudo lo hace con RSA, y tu navegador comprueba esa firma en cada conexión. Lo contamos en cómo sabe tu navegador en qué certificados confiar y en HTTPS por dentro.
• SSH. Muchos servidores todavía aceptan llaves RSA para entrar. Las versiones recientes de OpenSSH ya crean llaves Ed25519 si no le dices otra cosa; en nuestro laboratorio, con OpenSSH 10.0, ssh-keygen sin opciones dio una llave (ED25519). Cómo se usan está en Asegurar SSH en tu servidor.
• Firmas de programas y documentos. Actualizaciones de sistemas, paquetes de software, PDF firmados y, en México, la e.firma del SAT, cuyos archivos convertimos en OpenSSL en la práctica.

Lo que RSA ya casi no hace es cifrar la conexión misma. TLS 1.3, la versión actual del protocolo de HTTPS, quitó el intercambio de llaves con RSA: ahora las dos partes acuerdan un secreto con curvas elípticas (ECDHE) o, cada vez más, con un método poscuántico como X25519MLKEM768. RSA se quedó sobre todo con el trabajo de firmar.

La aritmética del reloj

Toda la matemática de RSA ocurre en un reloj. En un reloj de 12 horas, si son las 10 y pasan 5 horas, no son las 15: son las 3. Al llegar a 12 se vuelve a empezar. Eso se escribe así:

• 10 + 5 = 15, y 15 mód 12 = 3: el residuo de dividir 15 entre 12.
• 17 mód 12 = 5, porque 17 = 1 × 12 + 5.
• 3 × 5 = 15, y 15 mód 12 = 3.

RSA usa un reloj mucho más grande, de tamaño n, y en vez de sumar eleva a potencias: calcula me mód n. Hay dos datos curiosos de esa operación que lo explican todo:

• Es rápida aunque los números sean enormes. Para elevar a la 65,537 no hace falta multiplicar 65,537 veces: se eleva al cuadrado una y otra vez y se toma el residuo en cada paso, así que basta con unas 17 multiplicaciones. Con números de 617 cifras, tu computadora lo hace en milésimas de segundo.
• Hacia atrás es difícil. Si te dan el resultado c, el exponente e y el reloj n, no hay forma conocida de recuperar m… a menos que conozcas un número secreto d que «deshace» la potencia. Y para calcular d hace falta saber de qué primos está hecho n.

Cómo se hacen las llaves, con números de juguete

Vamos con números pequeños, los clásicos de los libros de texto. Con números de este tamaño RSA se rompe en un instante, pero las cuentas son exactamente las mismas que con llaves reales.

1. Elige dos primos secretos: p = 61 y q = 53. En una llave real cada uno tiene más de 300 cifras y se eligen al azar.
2. Multiplícalos: n = 61 × 53 = 3233. Este es el tamaño del reloj, y es público. Cuando se dice «RSA de 2048 bits», se habla del tamaño de n.
3. Calcula un número auxiliar: φ = (p − 1) × (q − 1) = 60 × 52 = 3120. Se lee «fi», y es secreto: para calcularlo hay que conocer p y q.
4. Elige el exponente público e, que no comparta divisores con 3120: e = 17. En las llaves reales casi siempre es 65537, que es 2¹⁶ + 1 y hace muy rápida la potencia.
5. Calcula el exponente privado d, el número que cumple que e × d deja residuo 1 al dividirlo entre φ: d = 2753, porque 17 × 2753 = 46801 = 15 × 3120 + 1. Se calcula en un instante con el algoritmo de Euclides extendido, el mismo de la escuela para el máximo común divisor, pero solo si conoces φ.

La llave pública es el par (n = 3233, e = 17) y la privada, (n = 3233, d = 2753). Los primos 61 y 53 ya no hacen falta y deberían olvidarse; en la práctica se guardan junto con la privada porque aceleran los cálculos, como verás en el último apartado.

Cifrar, descifrar y firmar

En RSA el mensaje es un número menor que n. Para cifrar el 65 con la llave pública:

• Cifrar: c = 6517 mód 3233 = 2790. Esto es lo que viaja.
• Descifrar: m = 27902753 mód 3233 = 65. Solo quien conoce d = 2753 puede hacer esta cuenta.

Para firmar se usan las mismas dos potencias, pero en el orden contrario. Si el documento es el número 123:

• Firmar, con la privada: s = 1232753 mód 3233 = 2746.
• Verificar, con la pública: 274617 mód 3233 = 123. Coincide con el documento: la firma es buena.
• Si alguien altera la firma a 2747, la cuenta da 837, que no es 123: la verificación falla.

En la vida real no se firma el documento entero, que puede pesar megas, sino su hash: una huella de tamaño fijo, como SHA-256, que cambia por completo si cambia una sola letra. Puedes calcular uno con nuestra herramienta de hash.

Para quien quiera saber por qué funciona. Descifrar es calcular (me)d = me·d. Como e·d = 1 + k·φ para algún entero k, queda m · (mφ)k. El teorema de Euler, de 1763, dice que mφ mód n = 1 cuando m no comparte divisores con n, así que todo se reduce a m. Con el teorema chino del residuo se comprueba que también funciona en los casos raros en que sí los comparte.

Pruébalo: el demostrador

Aquí puedes repetir todo lo anterior con tus propios primos. Empieza con el ejemplo de la guía y luego prueba con «Primos al azar», que usa primos de cuatro y cinco cifras y el exponente real, 65537.

Dos cosas que vale la pena probar. En «Una palabra, letra por letra», escribe ALLA: con la llave de la guía sale 2790 · 2726 · 2726 · 2790, y las letras repetidas se notan a simple vista. Y en «Romper la llave» verás que con un n pequeño basta probar divisores para recuperar la llave privada completa. Los dos problemas tienen solución, y la vemos en los apartados que siguen.

Por qué es difícil de romper

Toda la seguridad de RSA descansa en que, viendo solo n, nadie pueda encontrar p y q. Con ellos se calcula φ, y con φ sale d en un instante: el demostrador lo hace en su último paso. Multiplicar dos primos es inmediato; el camino de regreso, factorizar, se vuelve brutalmente caro a medida que crece el número.

Lo medimos en el laboratorio con factor, el programa de Linux que descompone un número en primos. Le dimos números hechos de dos primos del mismo tamaño, como los de RSA, pero chiquitos:

• 64 bits (20 cifras): 0.01 s
• 80 bits (24 cifras): 0.04 s
• 96 bits (29 cifras): 0.36 s
• 112 bits (34 cifras): 2.18 s
• 128 bits (39 cifras): 5.6 minutos

Con 112 bits tardó un par de segundos; con 128, más de cinco minutos, y la curva solo se empina. factor usa métodos sencillos, pensados para números chicos. Una llave real tiene 2048 bits: 617 cifras. Los récords no usan factor, sino la criba general de cuerpos numéricos (GNFS), el mejor método conocido, repartido entre miles de procesadores. Aun con ella, cada bit más pesa: el autor del récord de 2026 calcula que RSA-2048 es unas mil millones de veces más difícil que RSA-1024.

Pero ojo: la dificultad solo protege si las llaves se generan bien. En 2012, un equipo de investigadores revisó las llaves públicas de millones de servidores y encontró que muchas compartían un primo, porque equipos como routers y firewalls las habían creado con un generador de números aleatorios pobre justo al encender. Con el máximo común divisor de dos llaves, una cuenta instantánea, obtuvieron las llaves privadas RSA del 0.50 % de los servidores TLS y del 0.03 % de los SSH. Con otras criptografías pasa lo mismo: en octubre de 2026, las claves de curva elíptica de ocho certificados de eMudhra resultaron ser números menores que 256.

Hasta dónde se ha roto: los récords

RSA Laboratories publicó en 1991 una lista de números de reto, los «números RSA», con premios para quien los factorizara. Son la mejor medida pública de hasta dónde llega el ataque:

• 512 bits, 1999. RSA-155 cayó el 22 de agosto de 1999 con unos 8,000 «MIPS-años» de cómputo. Las llaves de 512 bits, que entonces protegían comercio electrónico, quedaron muertas.
• 768 bits, 2009. RSA-768 cayó el 12 de diciembre de 2009, tras dos años de trabajo: el equivalente a casi 2,000 años de un procesador de un núcleo.
• 829 bits, 2020. RSA-250 cayó en febrero de 2020 con unos 2,700 años-núcleo.
• 862 bits, septiembre de 2026. Eric Lu, de la empresa Cognition, factorizó RSA-260 con unas 4,900 jornadas de GPU, con un agente de IA que programó el software para tarjetas gráficas y operó buena parte del cálculo. Él mismo aclara que no hubo avance en el método.
• 896 bits, 19 de septiembre de 2026. Stephen A. Weis, de Anthropic, factorizó RSA-896 con ayuda de Claude, que adaptó el programa CADO-NFS a GPU: hasta 2,048 GPU durante unos diez días, en tiempo que sobraba entre otros trabajos. Es el número RSA más grande factorizado en público.

Las conclusiones de los dos autores de 2026 son la mejor respuesta al «por qué 1024 bits ya no basta». Weis escribe que su trabajo no afecta a las llaves RSA de 2048 bits, pero que demuestra que las de 1024 son vulnerables para «muchos actores» con flotas de GPU de centro de datos. Lu calcula que un gran proveedor de nube o un laboratorio de IA podría factorizar un número RSA-1024 por un costo del orden de 30 millones de dólares. Y en noviembre, agentes de IA de Google DeepMind encontraron dos debilidades más en el RSA de 1024 bits.

El RSA de libro no es seguro: OAEP y PSS

Lo que hicimos en el apartado 4, elevar el mensaje directo a la potencia, se llama RSA «de libro», y tiene tres defectos graves:

• Es predecible. El mismo mensaje con la misma llave da siempre el mismo cifrado. Viste lo que pasa con «HOLA»: la A cifrada es 2790 siempre (es nuestro 65, el código de la letra), y un espía puede adivinar mensajes cortos probando opciones con la llave pública.
• Se puede manipular. Si alguien multiplica el cifrado 2790 por 217 (mód 3233), obtiene 3017, que se descifra como 130: el doble del mensaje original, sin haber conocido nunca la llave privada.
• Con mensajes pequeños, se resuelve sin la llave. Si el exponente es chico, como 3, y el mensaje también, la potencia nunca «da la vuelta al reloj» y basta sacar una raíz cúbica normal.

Por eso el RSA real nunca se usa así. Antes de la potencia, el mensaje se rellena con datos al azar y una estructura que se revisa al descifrar:

• OAEP para cifrar. Como mete bytes al azar, cifrar dos veces lo mismo da resultados distintos.
• PSS para firmar. También es aleatorio, y su estructura impide fabricar firmas combinando otras.
• El relleno antiguo, PKCS#1 v1.5, sigue muy extendido en firmas, pero para cifrar tiene un historial de ataques: el de Bleichenbacher, de 1998, revivió en 2017 con el nombre de ROBOT en servidores de grandes empresas.

Lo comprobamos con OpenSSL y una llave de 2048 bits. Ciframos dos veces la palabra «hola» con OAEP y comparamos el principio de la huella SHA-256 de cada resultado:

openssl pkeyutl -encrypt -pubin -inkey publica.pem -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256 -in msg.txt -out c1.bin
# (lo mismo otra vez, a c2.bin)
sha256sum c1.bin c2.bin

salidae585d46ae96ace6c
33d840cbeed951c7

Son distintos, y cualquiera de los dos se descifra bien:

openssl pkeyutl -decrypt -inkey llave.pem -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256 -in c2.bin

salidahola

Sin relleno (rsa_padding_mode:none, que obliga a dar un bloque del tamaño exacto de la llave), los dos resultados son idénticos: el defecto del RSA de libro, en una llave de verdad.

openssl pkeyutl -encrypt -pubin -inkey publica.pem -pkeyopt rsa_padding_mode:none -in bloque.bin -out r1.bin
# (lo mismo otra vez, a r2.bin)
sha256sum r1.bin r2.bin

salidad4e4acbefade11ab
d4e4acbefade11ab

Con firmas PSS: la firma mide 256 bytes (los 2048 bits de la llave), se verifica con la pública y falla en cuanto se cambia el documento:

echo "Pago de 1,500 pesos a Ana" > contrato.txt
openssl dgst -sha256 -sign llave.pem -sigopt rsa_padding_mode:pss -out contrato.sig contrato.txt
wc -c < contrato.sig

salida256

openssl dgst -sha256 -verify publica.pem -sigopt rsa_padding_mode:pss -signature contrato.sig contrato.txt

salidaVerified OK

echo "Pago de 9,500 pesos a Ana" > contrato.txt
openssl dgst -sha256 -verify publica.pem -sigopt rsa_padding_mode:pss -signature contrato.sig contrato.txt; echo "código: $?"

salida8097A6BB4A750000:error:02000068:rsa routines:ossl_rsa_verify_PKCS1_PSS_mgf1:bad signature:../crypto/rsa/rsa_pss.c:144:
8097A6BB4A750000:error:1C880004:Provider routines:rsa_verify_directly:RSA lib:../providers/implementations/signature/rsa_sig.c:1097:
Verification failure
código: 1

La moraleja práctica: nunca programes RSA tú mismo. Usa una biblioteca probada (OpenSSL, la de tu lenguaje) con OAEP para cifrar y PSS para firmar, que es lo que hacen por omisión las versiones actuales de casi todas.

Qué tamaño usar hoy

NIST, el instituto de normas de Estados Unidos que fija las reglas que sigue medio mundo, mide la seguridad en «bits de seguridad»: cuántas operaciones tendría que hacer un atacante, como potencia de 2. Una llave RSA de 2048 bits equivale a 112 bits de seguridad; una de 3072, a 128.

• 1024 bits: no. Desde 2014, NIST no permite crear firmas con llaves RSA menores de 2048 bits; las de 1024 a 2047 solo se aceptan para verificar firmas viejas (SP 800-131A). Y los récords de 2026 muestran que ya están al alcance de quien tenga suficientes GPU.
• 2048 bits: el mínimo actual. Es lo que usan casi todos los certificados de sitios web.
• 3072 o 4096 bits: para lo que tenga que durar años, como una CA raíz o documentos que deben seguir siendo verificables mucho tiempo.
• Para algo nuevo, considera no usar RSA. Las curvas elípticas (Ed25519, ECDSA P-256) dan la misma seguridad con llaves y firmas mucho más chicas y rápidas; por eso SSH ya las prefiere. Sobre el origen de las curvas de NIST, contamos cómo Claude encontró de dónde salieron sus semillas.

Subir de tamaño tiene un costo. Medimos cuántas firmas por segundo hace un solo núcleo del laboratorio con cada tamaño (openssl speed):

• 2048 bits: 1,971 firmas por segundo.
• 3072 bits: 703.
• 4096 bits: 311.

Verificar, en cambio, sigue siendo muy rápido en los tres casos, porque el exponente público es pequeño. Por cierto, OpenSSL ni siquiera te deja crear una llave ridículamente pequeña:

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:256 -out chica.pem

salidagenpkey: Error setting rsa_keygen_bits:256 parameter:
80E76536067C0000:error:1C8000AB:Provider routines:rsa_gen_set_params:key size too small:../providers/implementations/keymgmt/rsa_kmgmt.c:509:

La computadora cuántica y el calendario de NIST

En 1994, Peter Shor demostró que una computadora cuántica lo bastante grande podría factorizar números en tiempo razonable: el algoritmo de Shor rompería RSA de cualquier tamaño, y también las curvas elípticas. Esa máquina no existe todavía. En mayo de 2025, Craig Gidney, de Google, calculó que bastaría con menos de un millón de qubits físicos trabajando menos de una semana para romper RSA-2048, veinte veces menos que su estimación de 2019. Las computadoras cuánticas actuales están todavía muy lejos de eso, pero la cifra baja año con año; la contamos en los avances de Google con su chip Willow.

El riesgo no es solo futuro. Un espía puede guardar hoy tráfico cifrado y descifrarlo cuando tenga la máquina («cosechar ahora, descifrar después»). Por eso la migración empezó ya:

• En agosto de 2024, NIST publicó los primeros estándares poscuánticos: ML-KEM (FIPS 203) para acordar llaves y ML-DSA (FIPS 204) para firmar.
• El 27 de octubre de 2026 publicó la versión final de su plan de transición, el NIST IR 8547: RSA y todos los algoritmos vulnerables a las computadoras cuánticas quedan desaconsejados después de 2030 y prohibidos en sus normas después de 2035, sin importar el tamaño de la llave. Ni siquiera RSA de 3072 bits se salva.

OpenSSL 3.5 ya trae los dos. Esta es la lista de mecanismos para acordar llaves del laboratorio, con ML-KEM y los híbridos como el X25519MLKEM768 que ya usan los navegadores:

openssl list -kem-algorithms

salida  { 1.2.840.113549.1.1.1, 2.5.8.1.1, RSA, rsaEncryption } @ default
  { 1.2.840.10045.2.1, EC, id-ecPublicKey } @ default
  { 1.3.101.110, X25519 } @ default
  { 1.3.101.111, X448 } @ default
  { 2.16.840.1.101.3.4.4.1, id-alg-ml-kem-512, ML-KEM-512, MLKEM512 } @ default
  { 2.16.840.1.101.3.4.4.2, id-alg-ml-kem-768, ML-KEM-768, MLKEM768 } @ default
  { 2.16.840.1.101.3.4.4.3, id-alg-ml-kem-1024, ML-KEM-1024, MLKEM1024 } @ default
  X25519MLKEM768 @ default
  X448MLKEM1024 @ default
  SecP256r1MLKEM768 @ default
  SecP384r1MLKEM1024 @ default

El precio es el tamaño. Comparamos una llave pública y una firma de ML-DSA-65 con las de RSA-2048:

openssl genpkey -algorithm ML-DSA-65 -out pq.pem
openssl pkey -in pq.pem -pubout -outform DER | wc -c       # llave pública ML-DSA-65
openssl pkey -in llave.pem -pubout -outform DER | wc -c    # llave pública RSA-2048
openssl pkeyutl -sign -inkey pq.pem -in contrato.txt -rawin -out pq.sig; wc -c < pq.sig
openssl pkeyutl -sign -inkey llave.pem -in contrato.txt -rawin -digest sha256 -out rsa.sig; wc -c < rsa.sig

salida1974
294
3309
256

La llave pública poscuántica es casi siete veces más grande (1,974 bytes contra 294) y la firma, casi 13 veces (3,309 contra 256). Es uno de los retos de la transición: los certificados y los saludos de TLS van a pesar más.

Una llave RSA de verdad, por dentro

Para terminar, una llave de 2048 bits hecha por OpenSSL, para ver que adentro está lo mismo que en el ejemplo de juguete. La generamos en el laboratorio solo para esta guía (y se destruyó con él). Nunca publiques ni pegues en ningún lado la salida de esta orden con una llave tuya: contiene todos los secretos.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out llave.pem

openssl pkey -in llave.pem -text -noout

salidaPrivate-Key: (2048 bit, 2 primes)
modulus:
    00:85:29:f9:f3:6d:41:da:5c:e2:d9:30:13:3a:24:
    …
publicExponent: 65537 (0x10001)
privateExponent:
    01:58:e7:3e:18:75:4a:c6:4a:57:ef:ed:c8:45:7b:
    …
prime1:
    00:bb:7a:70:04:d7:14:08:cf:5d:07:d4:88:38:b6:
    …
prime2:
    00:b5:d5:93:4e:82:73:97:06:b4:4c:a5:67:29:17:
    …
exponent1:
    21:23:fe:a3:4c:65:d5:3c:da:c4:24:94:c3:f9:b7:
    …
exponent2:
    00:94:91:53:91:83:1e:c4:98:12:ba:c9:2e:37:b2:
    …
coefficient:
    16:12:78:91:3a:9c:82:9f:d6:a2:a5:94:cf:1c:b9:
    …

Recortamos cada número a su primer renglón: el módulo completo ocupa 18 renglones. Esto es cada campo:

• modulus es n, en hexadecimal: 2048 bits, que en decimal son 617 cifras.
• publicExponent es e = 65537, el de casi todas las llaves.
• privateExponent es d.
• prime1 y prime2 son p y q, de 1024 bits cada uno.
• exponent1, exponent2 y coefficient son atajos para descifrar y firmar unas cuatro veces más rápido usando el teorema chino del residuo: se hace la potencia con p y con q por separado, con números de la mitad del tamaño, y se juntan los resultados.

La llave pública es solo n y e. Se extrae así, y es lo único que puedes compartir:

openssl pkey -in llave.pem -pubout -out publica.pem
openssl pkey -pubin -in publica.pem -text -noout | head -3

salidaPublic-Key: (2048 bit)
Modulus:
    00:85:29:f9:f3:6d:41:da:5c:e2:d9:30:13:3a:24:

Con un pequeño programa de Python comprobamos que esta llave cumple las mismas reglas del ejemplo: p × q da n, y cifrar «hola» con e y descifrar con d lo devuelve intacto. Hay un detalle que sorprende a quien hizo las cuentas a mano:

salida · comprobación de la llaveimport sys,re,math
t=sys.stdin.read()
def campo(nombre):
    m=re.search(nombre+r\":\\s*\\n((?:\\s+[0-9a-f:]+\\n)+)\",t)
    return int(re.sub(r\"[^0-9a-f]\",\"\",m.group(1)),16)
n,d,p,q=campo(\"modulus\"),campo(\"privateExponent\"),campo(\"prime1\"),campo(\"prime2\")
e=int(re.search(r\"publicExponent: (\\d+)\",t).group(1))
lam=math.lcm(p-1,q-1); phi=(p-1)*(q-1)
print(\"p*q == n:\", p*q==n)
print(\"bits de p y q:\", p.bit_length(), q.bit_length())
print(\"e =\", e)
print(\"e*d mod lambda(n):\", e*d%lam)
print(\"e*d mod phi(n):\", e*d%phi)
m=int.from_bytes(b\"hola\",\"big\"); c=pow(m,e,n)
print(\"descifra hola:\", pow(c,d,n).to_bytes(4,\"big\").decode())
"
p*q == n: True
bits de p y q: 1024 1024
e = 65537
e*d mod lambda(n): 1
e*d mod phi(n): 1120692925355102113487364204409587841801965574807162541457566691992783493200000442369683992355559435564537346416257931371699010197436753596605193694796850047106474491731770840848738155735501980207289129006844378435461703544059917260872502910239679080626395586152508913904491403770007922586526454483516620872824817018810446194485525115579223077456390420801734159161191913947621692203041598309423724617399958748106992917623625421098737378708054739627033700138267125082682324684734060486018112654797930031597451661468334075496201030363959352438760857186935420037640584306396087093408142441568211112565254062783277144421
descifra hola: hola

OpenSSL calcula d con λ, el mínimo común múltiplo de p − 1 y q − 1, en lugar de φ; las dos versiones funcionan igual.

Más órdenes para ver certificados, convertir llaves entre formatos y revisar a qué llave pertenece un certificado están en OpenSSL en la práctica.

Resumen

• RSA usa dos llaves: la pública cifra y verifica; la privada descifra y firma.
• Se basa en que multiplicar dos primos es fácil y factorizar el producto, dificilísimo.
• Las cuentas son potencias en un «reloj» de tamaño n: c = me mód n y m = cd mód n.
• Nunca se usa «de libro»: OAEP para cifrar, PSS para firmar, y siempre con una biblioteca probada.
• 1024 bits ya no basta: en 2026 se factorizaron en público números de 862 y 896 bits, y 1024 está al alcance de quien tenga flotas de GPU. El mínimo es 2048; 3072 o más para lo que deba durar.
• Hoy RSA sirve sobre todo para firmar; para conexiones se usan curvas elípticas y métodos poscuánticos.
• Las computadoras cuánticas lo romperían con el algoritmo de Shor. NIST lo desaconseja después de 2030 y lo prohíbe en sus normas después de 2035; los relevos son ML-KEM y ML-DSA.

Fuentes: NIST IR 8547, versión final del 27 de octubre de 2026; NIST SP 800-131A Rev. 2; NIST SP 800-57 Parte 1 Rev. 5; lista de números RSA; Eric Lu, «Factoring RSA-260» (Cognition); Stephen A. Weis, RSA-896; Craig Gidney, «How to factor 2048 bit RSA integers with less than a million noisy qubits»; RFC 8017 (PKCS #1 v2.2: OAEP y PSS); RFC 8446 (TLS 1.3); Heninger y otros, «Mining Your Ps and Qs» (2012). Laboratorio: Debian 13 con OpenSSL 3.5.7, OpenSSH 10.0p2 y el factor de coreutils, en un contenedor desechable; los números del ejemplo, comprobados con Python 3.13. Órdenes ejecutadas el 11 de noviembre de 2026.