He factorizado las claves RSA de una Autoridad de Certificación de los 90

Artículo original ↗ Discusión en Hacker News ↗

Factorizar una clave RSA de 512 bits de una autoridad certificadora de los años 90 en hardware de consumo moderno pone de relieve lo débil que se ha vuelto la criptografía heredada de tipo “export‑grade” y plantea preguntas sobre la confidencialidad a largo plazo del tráfico cifrado histórico. Los comentaristas contrastan el coste de romper claves RSA de 512, 1024 y 2048 bits, explican cómo los avances en algoritmos de factorización y GPU hacen que RSA de 1024 bits pueda estar al alcance de actores con muchos recursos, y señalan que los algoritmos simétricos siguen siendo mucho más resistentes. El hilo también aborda la historia de la criptografía débil impuesta por gobiernos, la transición hacia TLS más fuerte y postcuántico, y las preocupaciones sobre depender de código generado por IA e implementaciones TLS personalizadas en trabajos sensibles a la seguridad.

Fortaleza de las claves RSA y viabilidad de la factorización

  • Varios comentarios analizan cómo escala la factorización:
    • Las claves simétricas duplican efectivamente el trabajo por cada bit adicional; RSA es más débil por bit debido a la factorización subexponencial (por ejemplo, General Number Field Sieve).
    • Estimaciones citadas: ~2000 años de GPU para factorizar RSA de 1024 bits; se proyecta que RSA de 2048 bits requeriría cientos de miles a millones de años con las técnicas actuales.
    • A menudo se equipara RSA de 2048 bits con ~112 bits de seguridad simétrica; RSA de 3072 bits, con ~128 bits.
  • Factorizar una clave de 512 bits en ~2 días en hardware de consumo se considera coherente con proyecciones históricas.
  • Algunos señalan que la memoria y los pasos de matrices, y no solo el cómputo bruto, son cuellos de botella importantes.

Computación cuántica y riesgo futuro

  • Se menciona el algoritmo de Shor como el final teórico para RSA, pero se considera que el hardware cuántico práctico con suficientes qubits estables está todavía lejos.
  • Algunos sugieren observar las tendencias de “qubits estables” frente al coste de RSA; la intersección no está clara.

TLS, navegadores antiguos y criptografía personalizada

  • Las bibliotecas modernas de TLS eliminaron SSLv3, los client hellos de SSLv2 y los cifrados export; el autor del artículo implementó una pila mínima de SSLv3 (RC4, DES/3DES, MD5, SHA‑1) para comunicarse con Netscape 4.x.
  • Otros describen esfuerzos similares para dar soporte a servicios de “retro internet”, a menudo requiriendo compilaciones personalizadas de OpenSSL.

Criptografía de exportación y política histórica

  • La RSA de exportación de 512 bits y los cifrados simétricos de 40 bits eran intencionalmente débiles para que las agencias pudieran descifrarlos.
  • Las ranuras para certificados raíz en los navegadores de los años 90 se monetizaban, y había presión de los incumbentes para limitar la competencia.
  • Algunos recuerdan reglas nacionales (por ejemplo, escrow obligatorio de claves, topes de longitud de bits).

Herramientas de IA (“slop machine”) en el flujo de trabajo

  • Debate sobre el uso de LLMs:
    • A los críticos no les gusta externalizar las partes “interesantes” y advierten sobre resultados plausibles pero no verificables.
    • Los defensores sostienen que la IA está bien para pasos intermedios, no críticos para la seguridad, siempre que los resultados finales se comprueben de forma independiente.
    • Aparecen actitudes fuertemente negativas y fuertemente positivas hacia la IA.

RNGs, escribir tu propia criptografía y diseño de sistemas

  • La sabiduría convencional: no escribas tu propia criptografía; usa RNGs del kernel (getrandom, /dev/urandom).
  • Contrapunto: se afirma que un RNG hecho a mano en un proyecto de larga duración no ha tenido vulnerabilidades, mientras que bibliotecas ampliamente usadas sí han tenido muchas; el argumento es que el contexto y un diseño cuidadoso importan.
  • La discusión aborda restricciones POSIX, entornos chroot y el equilibrio entre rendimiento y seguridad en el diseño de RNGs.

PKI, DNS y alternativas

  • Algunos abogan por publicar claves públicas en DNS (estilo ACME/DNS-01) y cuestionan la necesidad de las CAs tradicionales.
  • Otros señalan que eso traslada la confianza a DNS y DNSSEC, y que un MITM en la capa DNS sigue siendo una preocupación.

Vigilancia, forward secrecy y tráfico almacenado

  • Preocupa que los gobiernos hayan grabado tráfico cifrado histórico para descifrarlo más tarde, a medida que mejoren la factorización o la computación cuántica.
  • Se enfatiza la forward secrecy y la robustez de la criptografía simétrica; se citan estadísticas alentadoras sobre el despliegue de TLS postcuántico.
  • Una defensa adicional propuesta: negociar una PSK sobre una conexión “limpia” y usarla para endurecer sesiones futuras, asumiendo que el adversario no puede vigilarlo todo.