martes, septiembre 29, 2026

Cómo Falsificar Firmas RSA, sin Factorizar el Módulo, usando 1.380 CPU Core-Years

Después de haber publicado los últimos tres artículos seguidos mirando hacia la Criptografía PostQuántica - "Claude Mythos Preview debilita los algoritmos criptográficos PQC HAWK y AES con nuevos ataques", "El algoritmo que amenazó a la Criptografía Post-Cuántica" y "Cómo se desmontó el algoritmo que amenazaba a la Criptografía Post Cuántica 9 días después" -  hoy toca volver al viejo conocido: RSA. Pero esta vez no hay ordenador cuántico, no hay algoritmo de Shor y, de hecho, ni siquiera hay que factorizar el número que protege la clave.


Este fin de semana leyendo los blogs de referencia, vimos como Tom’s Hardware publicó una noticia con un titular de los que obligan a abrir una pestaña nueva: un ataque contra RSA clásico reducía de forma espectacular eltrabajo necesario en determinadas condiciones y colocaba algunos parámetros bastante máscerca de adversarios con recursos enormes. La noticia nace de un preprint de Laura Shea, Miro Haller, Adam Suhl, Nadia Heninger y Emmanuel Thomé, titulado "Forging 1024-bitRSA signatures in nearly SNFS time", y publicado el 20 de Septiembre de este año.


Y el resultado es de los que merece leer despacio. Los autores han realizado una falsificación real contra una clave RSA de 1024 bits empleando unas 1.380 CPU core-years, con alrededor de 232 consultas a un oráculo RSA y 5 meses de tiempo de calendario. Después de la pre-computación, fabricar una firma elegida por el atacante todavía cuesta unas 180 core-years, pero ya se puede hacer offline, sin volver a consultar al dispositivo que posee la clave.

Suena muchísimo a “RSA roto”. Pero no es eso. De hecho, la parte más interesante de esta historia consiste precisamente en entender qué se ha roto, qué no y por qué la diferencia importa. Y como recomendación previa, el Libro de Cifrado de las comunicaciones digitales: de la cifra clásica a RSA 2ª Edición de 0xWord de Alfonso Muñoz es de lectura obligatoria para entender bien el mundo de la criptografía.

La primera sorpresa: el ataque NO nació en 2026, es de 2007

Aquí llega el primer giro de guión. El algoritmo que hace posible todo esto No es nuevo. Tiene casi veinte años. En el año 2007 los investigadores Antoine Joux, David Naccache y Emmanuel Thomé publicaron un trabajo con un título que hoy parece escrito a propósito para esta noticia: "When e-th Roots Become EasierThan Factoring". Lo que demostraban era que, si un atacante dispone de acceso a un tipo muy concreto de oráculo RSA, calcular nuevas raíces e-ésimas módulo N puede ser sustancialmente más barato que factorizar N con los mejores métodos conocidos.


En lenguaje menos hostil: 

"Hay escenarios en los que falsificar una operación RSA 
puede costar mucho menos que reconstruir la clave privada".

El resultado de 2007 no era una receta para romper cualquier servidor del planeta. Requería acceso a una caja negra capaz de realizar operaciones RSA sobre valores elegidos por el atacante y seguía necesitando una cantidad de cálculo monstruosa. Durante casi dos décadas se quedó, en la práctica, en la zona gris que separa un resultado precioso de teoría de un ataque que alguien ha pagado de verdad.

Eso es exactamente lo que cambia ahora. El equipo de UC San Diego e INRIA ha construido una implementación pública, la ha ejecutado a escala criptográfica real y ha completado la falsificación para RSA-1024. Su propio repositorio en GitHub lo resume de forma bastante clara: es la primera implementación pública y ejecución a gran escala del algoritmo de 2007.


Por eso conviene corregir una pequeña tentación periodística desde el principio. No han inventado un ataque nuevo contra RSA; han demostrado que un viejo atajo matemático funciona de verdad a una escala que ya no cabe en una pizarra. 

RSA en treinta segundos: una cerradura con dos operaciones

La idea central del ataque es que la clave privada puede seguir encerrada y el atacante no necesita factorizar el módulo. Lo que intenta obtener es la capacidad de producir resultados válidos como si tuviera la clave. Y con este trabajo lo han probado. Para entender el truco sólo necesitamos recordar el esqueleto de RSA. 

Elegimos dos primos enormes p y q y publicamos su producto N= pq. La clave pública contiene N y un exponente e. La privada contiene el exponente d, relacionado con la estructura secreta de N. En RSA, de manual, si representamos un mensaje mediante un número m, la operación privada tiene esencialmente esta forma:

s = m^d (mod N ),

y cualquiera puede comprobar el resultado con la clave pública:

s^e ≡ m (mod N ).

Para firmas reales no se firma el mensaje desnudo de esta manera. Antes se aplica una codificación cuidadosamente diseñada, como RSA-PSS o PKCS#1v1.5, precisamente porque el RSA “en crudo” es demasiado algebraico, demasiado maleable y deja abiertas puertas que un esquema de firma serio debe cerrar.

Y aquí entra una palabra que aparece constantemente en el trabajo: Oráculo. No tiene nada de místico. Imaginad un HSM (Hardware Secure Module), un dispositivo diseñado para guardar una clave privada sin que nadie pueda extraerla. La aplicación le envía una entrada, el HSM realiza la operación privada y devuelve la salida. La clave sigue dentro. Desde fuera solo vemos una API. Eso es un Oráculo Criptográfico: una caja negra que responde preguntas sin enseñarnos el secreto con el que las responde.

Figura 6: El HSM puede cumplir perfectamente su misión de no revelar
la clave privada. El problema aparece si la interfaz permite al
atacante pedir justo la operación algebraica que necesita el ataque.

Y esta es una de las ideas más bonitas del trabajo: la caja fuerte puede no abrirse nunca y, aun así, el mostrador de la puerta puede aceptar demasiados encargos.

La propiedad peligrosa de RSA raw: las firmas se multiplican

¿Por qué importa tanto que el oráculo sea “raw”, sin el acolchado criptográfico habitual? Porque RSA desnudo conserva una estructura multiplicativa muy fuerte. Si tenemos

s1 = m1^d (mod N )

y

s2 = m2^d (mod N )

entonces al multiplicarlas obtenemos

s1s2 = (m1m2)^d (mod N )

Las respuestas del oráculo, por tanto, no son piezas aisladas. Se relacionan entre sí mediante la misma aritmética modular que define RSA. Esa maleabilidad es conocida desde hace décadas y es una de las razones por las que los esquemas reales introducen padding y codificaciones antes de aplicar la operación privada.

El algoritmo de Joux, Naccache y Thomé lleva esa idea muchísimo más lejos. En vez de intentar recuperar p, q o d, el atacante pide al oráculo raíces RSA de una colección enorme de valores cuidadosamente elegidos. Después usa maquinaria de Number Field Sieve para construir relaciones algebraicas suficientes como para sintetizar la raíz —o, en el lenguaje de firmas, la firma— de un valor que el oráculo nunca firmó directamente.

Lo importante aquí no es memorizar el detalle del cribado. Es entender el cambio de objetivo: el atacante deja de preguntar “¿cuál es la clave?” y pasa a preguntar “¿puedo aprender suficiente sobre lo que esta clave hace como para imitarla más tarde?”. Y la respuesta del paper de 2026 es que Sí, bajo ese modelo concreto.

La parte inquietante: el acceso puede acabarse antes del ataque final

Para RSA-1024, el equipo hizo alrededor de 232 consultas al oráculo: algo más de cuatro mil millones. Es una barbaridad. Pero una vez recogida esa información, la parte gruesa del trabajo se convierte en una pre-computación ligada principalmente a la clave pública. Cuando termina, el atacante puede fabricar firmas elegidas posteriormente sin volver a tocar el HSM.



Figura 7: El flujo conceptual del ataque. El detalle importante está en la línea
roja: el acceso al oráculo puede terminar antes de la falsificación final.
La fórmula de la última tarjeta representa la condición matemática de
una firma RSA válida; el atacante no ha recuperado el exponente privado d.

Eso cambia la intuición habitual sobre una intrusión temporal. Si un atacante roba una contraseña durante una hora y después la cambiamos, solemos pensar que el acceso ha muerto con la credencial. Aquí la historia puede ser distinta: unas horas, días o meses de acceso a una operación RSA vulnerable pueden convertirse, si se consiguen suficientes consultas, en una capacidad que sobrevive después. La clave privada sigue sin salir de la caja. El módulo sigue sin factorizarse. Pero la frontera de seguridad se ha movido.

Por qué “casi SNFS” es la frase importante del título

Hasta aquí sabemos que el ataque funciona, pero todavía falta entender por qué puede ser tan distinto de factorizar directamente la clave. Vamos a ello.

El mejor algoritmo  clásico conocido para factorizar un entero RSA genérico grande es el General Number Field Sieve, o GNFS. La palabra “general” importa: un módulo RSA bien generado está pensado precisamente para no tener una estructura especial que nos regale un atajo.

El Special Number Field Sieve, o SNFS, vive en un mundo más amable. Cuando el número que queremos atacar tiene una forma algebraica especial, el cribado puede ser considerablemente más rápido. Esa diferencia no convierte un problema gigantesco en algo trivial, pero sí puede recortar muchos bits de seguridad. 

El trabajo de 2007 demostró que, con el Oráculo adecuado, el problema de extraer raíces RSA puede alcanzar una complejidad del mismo tipo que SNFS, sin necesidad de factorizar el módulo. No significa que hayan convertido un módulo RSA normal en un número “especial”. Significa que el oráculo cambia el problema que estamos resolviendo y permite llegar a una ruta algorítmica más favorable.


De ahí el título del nuevo paper: "nearly SNFS time". Y conviene subrayar también el “nearly”. Esto sigue siendo un ataque subexponencial, enormemente caro y muy lejos de cualquier algoritmo polinómico. No es un Shor clásico disfrazado usando Quantum Computing. No es “descargar el código y romper RSA-2048 esta tarde”. Los propios autores son muy explícitos al respecto. Pero una cosa puede ser carísima y, al mismo tiempo, obligarnos a revisar lo que entendíamos por margen de seguridad.

Los números: 1.380 core-years frente a medio millón

Aquí es donde la historia deja de ser una curiosidad asintótica. La estimación que manejan los autores para factorizar directamente un módulo RSA de 1024 bits mediante GNFS está entre 500.000 y 1.000.000 CPU Core-Years. La ejecución real de su ataque consumió unas 1.380 core-years y terminó después de cinco meses de calendario, lo que es mucho menos de lo planteado inicialmente.

Un Core-Year no quiere decir que una persona se sentó a esperar 1.380 años. Es una unidad de trabajo que habla de mantener un núcleo de CPU ocupado durante un año. Con un clúster suficientemente grande, muchos años de CPU se convierten en meses de tiempo real. Aun así, la comparación es brutal. No estamos hablando de ahorrar un 20%, o de una implementación especialmente afinada. Estamos hablando de reducir el trabajo estimado en varios cientos de veces frente al extremo bajo de la factorización.

Figura 9: Orden de magnitud del trabajo para RSA-1024.
El eje es logarítmico: 1.380 core-years sigue siendo muchísimo cómputo,
pero queda muy por debajo de la estimación de una factorización directa.

Además hay dos cifras que evitan que salgamos corriendo a poner “RSA muerto” en el titular. La primera son esas 232 consultas al Oráculo. La segunda es que, incluso después de terminar la pre-computación, la falsificación elegida todavía requiere unas 180 core-years. Es decir, el ataque es real, pero no es cómodo ni totalmente rápido. 

Y, al mismo tiempo, tampoco conviene tratar esos números como una constante de la naturaleza. Los investigadores indican que su implementación no utilizó GPUs y que esperan margen de optimización importante. Eso no nos autoriza a inventarnos cuánto bajará el coste mañana, pero sí nos recuerda una regla clásica del criptoanálisis: la primera ejecución pública rara vez es la última palabra en ingeniería.

De 1024 a 4096 bits: el margen de seguridad también cambia

El experimento completo se hizo para 1024 bits, pero el paper publicado extrapola sus mediciones a tamaños mayores. La noticia de Tom’s Hardware recoge las estimaciones en una forma bastante intuitiva: si expresamos el coste como “bits de trabajo”, las cifras aproximadas pasan de 80, 112, 128 y 144 bits para la referencia basada en factorización a 65, 90, 105 y 119 bits bajo el modelo de ataque con oráculo para RSA-1024, RSA-2048, RSA-3072 y RSA-4096, respectivamente.

La forma correcta de leer el gráfico siguiente no es “RSA-2048 tiene 90 bits de seguridad siempre”. Eso sería falso. La lectura correcta es: si un atacante consigue el tipo de oráculo que exige este ataque, el margen efectivo puede caer mucho respecto a la estimación basada únicamente en factorizar N.

Figura 10: Estimaciones de trabajo recogidas para distintos tamaños de RSA.
El azul corresponde únicamente al escenario con el oráculo requerido
por el ataque; no describe la seguridad de todo uso de RSA.

Para RSA-2048, 290 sigue siendo una cantidad enorme de trabajo. Los propios autores señalan que está aproximadamente tres órdenes de magnitud por encima del coste de referencia de 280 asociado a RSA-1024, y no existe una factorización pública completa de un módulo RSA-1024 genérico. Así que tampoco estamos delante de un ataque que mañana vaya a vaciar Internet.

Pero hay una lección incómoda, ya que subir el tamaño de la clave no arregla por sí solo un cambio de modelo de ataque. Si el problema ya no es factorizar, la tabla mental que usábamos para traducir “2048 bits de RSA” a un margen de seguridad deja de ser toda la historia.

Entonces, ¿está roto RSA? Depende de qué RSA estemos hablando

Llegados aquí, la respuesta corta es NO: este trabajo no rompe las firmas RSA-PSS ni PKCS#1 v1.5 convencionales cuando se usan mediante interfaces normales. Los autores lo dicen expresamente en su FAQ: esos esquemas no exponen el oráculo raw que necesita el ataque. El padding no es decoración; es parte esencial del diseño de seguridadde la firma.


Pero hay sistemas en los que la propia funcionalidad exige algo mucho más parecido a ese oráculo. El ejemplo más claro son las firmas RSA ciegas. En un protocolo de Blind RSA, el cliente oculta matemáticamente el mensaje, el servidor aplica la operación privada sobre el valor cegado y el cliente elimina después el cegado. El RFC 9474 especifica precisamente este tipo de construcción, y la firma final puede verificarse como una firma RSA-PSS.


Ese detalle es importante porque evita una aparente contradicción: una API normal de RSA-PSS no da al atacante un oráculo raw, pero un protocolo de Blind RSA puede necesitar internamente una operación privada sobre valores que el cliente controla. El problema no es la etiqueta “PSS” que aparece al final; es qué inputs puede hacer procesar el atacante por la clave privada durante el protocolo.

Privacy Pass, por ejemplo, estandariza un tipo de token públicamente verificable basado en Blind RSA de 2048 bits. Para ese tamaño, los autores estiman aproximadamente 290 de trabajo y 243 consultas al oráculo. Es una cifra descomunal y probablemente fuera del alcance de casi cualquier atacante real, pero ya no es una afirmación puramente académica sobre una construcción inventada para un paper: hay protocolos modernos cuya forma se parece exactamente al escenario que merece revisar.

Figura 13: Privacy Pass

También entran en esta categoría ciertas APIs de HSM que permiten operaciones RSA de bajo nivel. Y aquí hay que afinar el lenguaje: un HSM no es vulnerable por ser un HSM. De hecho, el HSM puede estar haciendo perfectamente su trabajo de no dejar salir la clave. 

Lo que hay que revisar es si su política permite un volumen enorme de operaciones del tipo que actúa como oráculo. El equipo realizó su demostración usando un HSM como caja negra, precisamente para mostrar que la clave puede No filtrarse ni una sola vez.

La parte que el titular borra: NO basta con capturar tráfico

Aquí es donde algunos titulares pueden llevarnos demasiado lejos. No es correcto imaginar el ataque como “grabo tráfico TLS hoy, hago el cálculo mañana y descifro Internet”. El propio repositorio de los autores recuerda que el intercambio de claves moderno de TLS usa mecanismos como ECDH y está migrando hacia ML-KEM; este ataque no se aplica a esos algoritmos.

Para que exista una falsificación o un descifrado útil tiene que haber una clave RSA concreta expuesta mediante la operación vulnerable, suficiente acceso al oráculo y un protocolo en el que esa capacidad posterior tenga valor. En otras palabras, el ataque es contra una interfaz y un modelo de uso de RSA, no contra la existencia del algoritmo RSA en abstracto.

Esto también explica por qué los miles de millones de consultas son algo más que un detalle de implementación. Contra un servicio público bien monitorizado, pedir cuatro mil millones de operaciones anómalas no es precisamente discreto. Ratelimits, rotación de claves, telemetría y controles de acceso pueden hacer que un ataque matemáticamente posible sea operacionalmente absurdo. Contra una clave muy longeva, una API interna poco vigilada o un dispositivo con políticas demasiado permisivas, la historia puede cambiar.

Y esa es, para mí, una de las mejores lecciones del paper: la seguridad real nunca vive solo en una ecuación. Vive en la ecuación y en la API, y en la política de claves, y en cuántas veces dejamos que alguien pulse el botón, y en cuantas capas de seguridad se construyan para proteger un sistema.

Qué debería cambiar ahora mismo

Para la inmensa mayoría de administradores que usan RSA-2048 o RSA-3072 con firmas estándar y padding correcto, no hay una orden de evacuación. Los propios autores dicen que el ataque no parece viable contra firmas PKCS o PSS usadas de la forma habitual.

Figura 14: La frontera práctica del trabajo. El ataque no convierte cualquier
uso de RSA en vulnerable. La condición decisiva es si el atacante
dispone de la clase de oráculo que necesita la construcción.

Para quien mantenga Blind RSA, servicios de privacidad con firmas ciegas o HSM que expongan operaciones raw, Sí hay trabajo que hacer. Los investigadores sugieren, en el caso de Blind RSA de 2048 bits, medidas de corto plazo como reducir la duración de las claves y aumentar tamaños; a medio plazo, introducir mecanismos que cierren esta clase de oráculo; y a largo plazo, aprovechar la transición Postc-Cuántica para abandonar construcciones RSA heredadas cuando exista una alternativa adecuada.


Fijaos en la ironía. Llevamos años hablando de abandonar RSA porque un Quantum Computer suficientemente grande podrá factorizarlo con Shor. Y justo en mitad de esa transición aparece un recordatorio completamente clásico: aunque la factorización siga siendo durísima, la seguridad de RSA puede degradarse por un camino que no intenta factorizar nada. No invalida la migración Post-Cuántica. La refuerza desde otro ángulo.

Por qué este resultado me parece especialmente interesante

Hay una tendencia muy humana a meter todos los ataques criptográficos en dos cajas: “práctico” o “irrelevante”. Este no cabe bien en ninguna. No es práctico contra la mayoría del RSA desplegado hoy. Necesita una interfaz muy concreta, un número gigantesco de consultas y una barbaridad de cómputo. Pero tampoco es irrelevante, porque hace tres cosas que merece la pena recordar:
  • Primero, convierte una ventaja asintótica publicada en 2007 en una medición real. Hasta que alguien ejecuta el algoritmo a escala, las constantes viven en un limbo. Ahora tenemos una factura: 1.380 Core-Years para el experimento de 1024 bits.
  • Segundo, separa dos ideas que solemos usar como si fueran sinónimas: factorizar RSA y obtener una capacidad equivalente a usar la clave privada. En este modelo, la segunda puede ser muchísimo más barata que la primera.
  • Y tercero, coloca el foco en una zona bastante menos glamourosa que la teoría de números, pero igual de importante: la interfaz. Podemos construir una caja fuerte perfecta y arruinar parte de su seguridad si el botón de la puerta acepta demasiadas operaciones elegidas por quien está fuera.
El algoritmo de 2007 decía que esa posibilidad existía. El trabajo de 2026 ha hecho algo mucho más incómodo: ha ido hasta la caja, ha pulsado el botón miles de millones de veces y ha vuelto con una falsificación.

Conclusión

RSA No ha muerto esta semana. Nadie ha factorizado un módulo RSA-1024 genérico, no ha aparecido un algoritmo clásico polinómico y las firmas RSA-PSS o PKCS#1 v1.5 usadas de forma convencional no han quedado rotas por este resultado.

Lo que sí ha muerto un poco es una simplificación muy cómoda: pensar que la seguridad de RSA se resume siempre en preguntar “¿cuánto cuesta factorizar N?”. Si el atacante consigue acceso temporal al tipo adecuado de operación privada, la pregunta cambia. Y cuando cambia la pregunta, también puede cambiar brutalmente el coste.

Durante décadas hemos imaginado la clave privada como una llave física. Mientras no salga de la caja fuerte, respiramos tranquilos. Este paper recuerda que en criptografía una clave no es solo un objeto secreto: es también una capacidad. Si damos acceso a esa capacidad mediante una API, tenemos que proteger con el mismo cuidado no solo los bits de la clave, sino todas las cosas que permitimos hacer con ellos.


Quizá esa sea la mejor forma de contar esta historia. Los autores no han robado la llave, no han abierto la cerradura y no han encontrado los primos que hay detrás de RSA. Han demostrado que, bajo unas condiciones muy concretas, se puede aprender a fabricar una firma válida sin hacer ninguna de esas tres cosas. Y eso es bastante más interesante que otro titular de “RSA está roto”. Porque la moraleja no sirve solo para RSA: una caja fuerte deja de ser segura mucho antes de abrirse si su ventanilla concede las operaciones equivocadas. Eso sí, no perdamos el foco de migrar a Post-Quantum Cryptography que es lo que debemos hacer cuanto antes.


Otros artículos sobre Quantum Computing publicados:

No hay comentarios:

Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares