Un investigador reconstruyó en su propio escritorio la clave privada RSA de 512 bits de una autoridad certificadora real: una que Netscape 4.51 marcó como confiable para SSL en marzo de 1999. El hallazgo no pone en riesgo a nadie hoy, porque esa raíz expiró en 2003 y fue retirada de los navegadores en 2002.
Pero el experimento pone números concretos sobre la mesa: cuántas horas de cómputo hacen falta hoy para romper lo que hace 25 años se consideraba seguro. La respuesta, en este caso, cabe en un fin de semana largo con un solo procesador de escritorio.
TL;DR
- Matthew McPherrin factorizó dos claves RSA de 512 bits de la CA canadiense E-Certify, confiable en Netscape 4.51 desde marzo de 1999.- Usó CADO-NFS en un Ryzen 9 5950X: 32 horas para la clave "Gold Server" (SSL) y 29 horas para "Gold Client" (S/MIME).- La RSA-155, también de 512 bits, ya había sido factorizada en 1999, el mismo año en que Netscape emitió estas raíces.- Netscape retiró las raíces de E-Certify en 2002; el certificado expiró el 16 de octubre de 2003.- Internet Explorer nunca distribuyó raíces SSL de 512 bits, así que el experimento queda limitado a esa ventana de Netscape.- McPherrin publicó las claves privadas, los certificados y el código en GitHub, en mcpherrinm/ancientroots.- Para verificarlo montó un servidor TLS a medida en Go, publicado en e-certify.fly.dev, compatible solo con Netscape 4.51.- Las raíces se hallaron extrayendo certificados de instaladores históricos archivados, con ayuda de Claude Code.
Qué pasó
El 7 de septiembre de 2026, el desarrollador Matthew McPherrin publicó en su blog personal el relato completo de cómo factorizó las claves RSA de una autoridad certificadora real de los años noventa. Todo empezó con una pregunta simple: ¿existe algún certificado raíz lo bastante débil como para romperlo con una computadora de escritorio actual?
Para responderla, descargó los instaladores históricos de Netscape e Internet Explorer alojados en el Internet Archive y usó Claude Code para extraer de forma automática todas las raíces incluidas en cada versión, publicando el resultado en una página web filtrable. Buscando por tamaño de clave encontró el objetivo: en marzo de 1999, Netscape 4.51 distribuyó dos certificados raíz de 512 bits de la desaparecida autoridad canadiense E-Certify, uno habilitado para SSL ("Gold Server") y otro para S/MIME ("Gold Client").
Internet Explorer, en cambio, nunca llegó a incluir raíces de 512 bits para SSL, así que la ventana de este experimento quedó acotada a una etapa muy específica de Netscape entre 1999 y 2002.
El siguiente diagrama resume el proceso completo, desde la extracción de las raíces archivadas hasta la carga de una página firmada por la clave reconstruida en el navegador original de 1999:
flowchart TD
A["Instaladores archivados de Netscape e IE"] --> B["Extraccion de raices con Claude Code"]
B --> C["Filtro: certificados RSA de 512 bits"]
C --> D["CADO-NFS factoriza el modulo"]
D --> E["Reconstruccion de la clave privada"]
E --> F["Emision de un certificado firmado"]
F --> G[("Servidor TLS a medida en Go")]
G --> H["Netscape 4.51 carga la pagina"]
Contexto e historia
La seguridad de RSA depende de que factorizar un número semiprimo grande sea computacionalmente costoso, pero qué tan grande debe ser esa clave cambia con el tiempo. En 1999, el mismo año en que Netscape emitía las raíces de E-Certify, un equipo internacional ya había factorizado RSA-155, un semiprimo de 512 bits del RSA Factoring Challenge. Es decir: la clave que Netscape marcó como confiable para cifrar tráfico ya era, en teoría, insegura desde su nacimiento.
El límite sigue subiendo con el tiempo. Hace apenas unos días, alguien completó la factorización de RSA-260, un semiprimo de 862 bits y la mayor factorización pública conocida hasta ahora. El Web PKI, el sistema de confianza que usan los navegadores, dejó de aceptar claves RSA de 1024 bits hace más de una década. Hoy el estándar mínimo son 2048 bits, aunque ese tamaño también tiene fecha de vencimiento ante la eventual llegada de computadoras cuánticas capaces de correr el algoritmo de Shor.
Ese contexto histórico importa para entender por qué existía siquiera una raíz de 512 bits en 1999: Netscape lanzó soporte para SSL en 1994, en plena era de restricciones de exportación de criptografía impuestas por Estados Unidos, cuando la industria todavía no tenía estándares mínimos de tamaño de clave para autoridades certificadoras.
En 1999, 512 bits ya no alcanzaba: RSA-155 cayó ese mismo año.
Detalles técnicos: cómo se factorizó la RSA de 512 bits
Para reconstruir la clave privada a partir de la pública, McPherrin corrió CADO-NFS, una implementación open source de la criba general del cuerpo de números (GNFS), el algoritmo clásico para factorizar semiprimos grandes. El proceso consta de varias fases: selección de polinomio, criba, filtrado de relaciones, álgebra lineal y raíz cuadrada final. Para un módulo de 512 bits, la fase de criba es la que más tiempo consume en hardware de escritorio.
El trabajo corrió en un Ryzen 9 5950X de escritorio, sin clúster ni GPU: 32 horas para factorizar la clave "E-Certify RSA 512 Gold Server" y 29 horas para "E-Certify RSA 512 Gold Client". La siguiente tabla ubica ese resultado dentro de la escala histórica de factorizaciones RSA conocidas:
ClaveTamañoEstadoTiempo o hitoRSA-155512 bitsFactorizada en 1999Esfuerzo distribuido internacionalE-Certify Gold Server512 bitsFactorizada en 202632 horas en un Ryzen 9 5950XE-Certify Gold Client512 bitsFactorizada en 202629 horas en un Ryzen 9 5950XRSA-260862 bitsFactorizada recientementeMayor factorización pública conocidaRSA de 1024 bits1024 bitsDeprecada por el Web PKISin factorización pública confirmadaRSA de 2048 bits2048 bitsEstándar mínimo actualVigente en certificados TLS modernos
Un ejemplo simplificado de cómo se invoca CADO-NFS sobre un número compuesto (un semiprimo de juguete para ilustrar la sintaxis, no la clave real):
./cado-nfs.py 2087213345157128459857544877488990849241708931948717
# la herramienta corre las fases de criba, filtrado y algebra lineal,
# y al final imprime los dos factores primos encontrados
Con el módulo público del certificado real el comando es el mismo, pero el número tiene 512 bits: la diferencia está en el tiempo de cómputo, no en el algoritmo. Para confirmar que una clave privada reconstruida corresponde de verdad al certificado público, se compara el módulo de ambos:
openssl x509 -noout -modulus -in e-certify-gold-server.pem | openssl md5
openssl rsa -noout -modulus -in e-certify-gold-server-key.pem | openssl md5
# si los dos hashes coinciden, la clave privada es valida para ese certificado
Cómo probarlo
McPherrin publicó las claves privadas, los certificados originales y las herramientas usadas en el repositorio github.com/mcpherrinm/ancientroots. Cualquiera con Netscape 4.51 corriendo en una máquina virtual con el reloj atrasado a antes de octubre de 2003 puede usarlas para emitir certificados y probarlos contra e-certify.fly.dev, un servidor TLS a medida escrito en Go que McPherrin tuvo que construir porque ningún stack TLS moderno comparte cifrados con ese navegador de 1999.
Para instalar CADO-NFS y reproducir la parte de factorización en tu propia máquina, usando un número más chico salvo que tengas varios días libres de CPU:
# Linux (Debian/Ubuntu)
sudo apt install build-essential cmake libgmp-dev
git clone https://gitlab.inria.fr/cado-nfs/cado-nfs.git
cd cado-nfs && make
# macOS (Homebrew)
brew install cmake gmp
git clone https://gitlab.inria.fr/cado-nfs/cado-nfs.git
cd cado-nfs && make
# Windows (via WSL2; CADO-NFS no tiene build nativo para Windows)
wsl --install -d Ubuntu
wsl
sudo apt install build-essential cmake libgmp-dev
git clone https://gitlab.inria.fr/cado-nfs/cado-nfs.git
cd cado-nfs && make
Impacto y análisis
El resultado no reabre ningún riesgo real: la raíz de E-Certify fue eliminada de Netscape en 2002 y el certificado expiró en 2003, así que ningún tráfico moderno depende de esa cadena de confianza. El valor del experimento está en otro lado: muestra, con horas y hardware concretos, la brecha entre lo que se consideraba seguro en 1999 y lo que exige hoy el Web PKI.
💭 Clave: el mismo año en que Netscape emitía una raíz de 512 bits, RSA-155, también de 512 bits, ya había caído. La debilidad no era un secreto técnico oculto: era pública desde el primer día.
El caso también ilustra cómo cambió la disponibilidad de herramientas de cómputo. En 1999, factorizar RSA-155 exigió un esfuerzo internacional distribuido entre varios grupos de investigación durante meses. En 2026, un desktop con un solo procesador Ryzen hizo el mismo trabajo, para una clave del mismo tamaño, en menos de un día y medio.
Un Ryzen 9 5950X de escritorio bastó: sin clústeres ni GPU dedicada.
⚠️ Ojo: replicar pruebas con stacks TLS antiguos, como el servidor a medida para Netscape 4.51, debe hacerse siempre en entornos aislados, nunca contra tráfico de producción o usuarios reales.
Para las autoridades certificadoras actuales, el mensaje de fondo es el mismo que exige hoy el CA/Browser Forum: el tamaño mínimo de clave no es una preferencia estética, es una fecha de vencimiento calculada según el poder de cómputo disponible en cada época.
Qué sigue
Según el propio McPherrin, el margen para repetir este experimento es angosto: Internet Explorer nunca distribuyó raíces SSL de 512 bits, así que la ventana queda limitada a esa etapa muy específica de Netscape entre 1999 y 2002. El catálogo de raíces antiguas que generó con Claude Code queda disponible igualmente, para que otros investigadores sigan buscando casos similares en instaladores de esa época.
En paralelo, la migración hacia criptografía poscuántica avanza por el mismo motivo que hizo caer a estas raíces de 512 bits: el poder de cómputo disponible solo crece. El NIST ya estandarizó ML-KEM (FIPS 203) como reemplazo de los esquemas de intercambio de claves basados en factorización y logaritmo discreto, anticipando el día en que una computadora cuántica suficientemente grande haga con RSA de 2048 bits lo que un Ryzen de escritorio ya hace hoy con 512 bits.
📖 Resumen en Telegram: Ver resumen
Probalo vos: cloná mcpherrinm/ancientroots y corré openssl x509 -noout -modulus sobre certificados viejos que tengas a mano para ver de qué tamaño de clave dependía tu propia navegación hace 25 años.
Preguntas frecuentes
¿Este hallazgo pone en riesgo la navegación actual?
No. La raíz de E-Certify fue retirada de Netscape en 2002 y el certificado expiró el 16 de octubre de 2003, así que ningún navegador moderno confía en ella.
¿Cuánto tardó la factorización?
32 horas para la clave "Gold Server" y 29 horas para "Gold Client", ambas de 512 bits, corriendo CADO-NFS en un Ryzen 9 5950X de escritorio.
¿Qué es CADO-NFS?
Es una implementación open source de la criba general del cuerpo de números (GNFS), el algoritmo estándar para factorizar semiprimos grandes como los módulos RSA.
¿Por qué una clave de 512 bits ya era débil en 1999?
Porque ese mismo año un equipo internacional factorizó RSA-155, otro semiprimo de 512 bits del RSA Factoring Challenge, demostrando en público que ese tamaño no alcanzaba.
¿Se puede reproducir el experimento?
Sí. Las claves privadas, los certificados originales y las herramientas están publicados en el repositorio de GitHub de McPherrin, junto con el servidor TLS a medida para probarlos con Netscape 4.51.
¿Qué tamaño de clave RSA se considera seguro hoy?
El mínimo aceptado por el Web PKI es de 2048 bits, aunque la migración hacia esquemas poscuánticos como ML-KEM ya está en marcha de cara al riesgo de las computadoras cuánticas.
Referencias
- mcpherrin.ca: publicación original de Matthew McPherrin con el detalle completo del proceso de factorización.- github.com/mcpherrinm/ancientroots: repositorio con las claves privadas, certificados y herramientas usadas.- cado-nfs.gitlabpages.inria.fr: página oficial del proyecto CADO-NFS, la herramienta de factorización usada.- en.wikipedia.org/wiki/RSA_Factoring_Challenge: historial del RSA Factoring Challenge, incluyendo RSA-155.- csrc.nist.gov: estándar FIPS 203 (ML-KEM) del NIST para criptografía poscuántica.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)