Hoy los Gobiernos fijan calendarios para que todos adoptemos criptografía más robusta, la postcuántica. Hace treinta años ocurría justo lo contrario: Estados Unidos consideraba la criptografía fuerte un arma y prohibía exportarla. Aquella etapa, conocida como las «guerras criptográficas» (crypto wars), dejó historias memorables, como la de un código fuente que viajó por el mundo impreso en un libro, y una herencia de algoritmos debilitados que tardó quince años en desaparecer. Merece la pena recordarla, porque es la mejor demostración práctica de por qué necesitamos criptoagilidad.
La criptografía como material militar
Durante décadas, Estados Unidos incluyó la criptografía en su lista de material de defensa, sometida a las normas sobre comercio de armas (ITAR). Desde 1996 pasó a regularse como bien de doble uso por el Departamento de Comercio (EAR), pero el efecto práctico fue el mismo durante años: exportar software con cifrado fuerte requería una licencia que, en general, no se concedía.
La consecuencia más visible afectó a la naciente web segura. Las versiones «internacionales» de Netscape Navigator e Internet Explorer solo podían negociar cifrado simétrico de 40 bits (RC4 o RC2) y un intercambio de claves RSA limitado a 512 bits. Fuera de Estados Unidos y Canadá, las conexiones HTTPS de bancos, tiendas y administraciones se protegían con una criptografía que, ya entonces, podía romperse en días con recursos modestos. La limitación no estaba en el certificado del sitio web, sino en el software del navegador.
Los certificados SGC: criptografía fuerte con permiso
Para los usos que el Gobierno estadounidense consideraba aceptables, sobre todo la banca, se ideó una excepción. Microsoft la llamó Server-Gated Cryptography (SGC) y Netscape, International Step-Up. Funcionaba así: si el servidor presentaba un certificado especial, el navegador de exportación «subía» la conexión a 128 bits. Esos certificados solo podían emitirlos unas pocas autoridades de certificación autorizadas, principalmente VeriSign y Thawte, y solo a entidades aprobadas: bancos y organizaciones con necesidades justificadas de criptografía fuerte.
Era, en el fondo, un sistema de licencias de exportación encarnado en una extensión de certificado: la robustez de la criptografía dependía de quién eras, no de lo que necesitabas proteger.
PGP y el código fuente que viajó en un libro
En 1991, Phil Zimmermann publicó PGP (Pretty Good Privacy), un programa de cifrado de correo electrónico con criptografía fuerte. PGP se difundió rápidamente fuera de Estados Unidos a través de Internet, y Zimmermann fue objeto de una investigación penal por presunta exportación ilegal de armas, que el Gobierno cerró en 1996 sin presentar cargos.
Mientras tanto, a Zimmermann se le ocurrió una idea brillante. Las normas de exportación se aplicaban al software, pero un libro está protegido por la Primera Enmienda de la Constitución estadounidense, que garantiza la libertad de expresión. Así que en 1995 la editorial del MIT publicó PGP: Source Code and Internals, con el código fuente completo de PGP impreso en sus páginas. Como el propio Zimmermann explicaba en el prefacio, el libro estaba pensado para que pudiera escanearse con un programa de reconocimiento óptico de caracteres (OCR) y reconstruir el código. Un libro es mucho más difícil de prohibir que un programa.
La idea funcionó. Las versiones posteriores de PGP se exportaron también impresas y, en Europa, voluntarios del proyecto internacional de PGP las escanearon y compilaron, lo que dio lugar a las versiones «i» (internacionales) que se distribuían legalmente fuera de Estados Unidos.
La EFF: el código es expresión
La Electronic Frontier Foundation (EFF) llevó la batalla a los tribunales y a los laboratorios.
En los tribunales, respaldó a Daniel J. Bernstein, entonces estudiante de doctorado en Berkeley, que quería publicar su algoritmo de cifrado Snuffle, un artículo que lo explicaba y el código fuente que lo implementaba. En el caso Bernstein contra el Departamento de Justicia de Estados Unidos, iniciado en 1995, los tribunales declararon inconstitucionales partes de la normativa de exportación, y en mayo de 1999 el Tribunal de Apelaciones del Noveno Circuito confirmó que publicar código fuente de cifrado es una forma de expresión protegida. En enero de 2000, Estados Unidos relajó sustancialmente sus controles de exportación de criptografía.
En el laboratorio, la EFF quiso demostrar que el algoritmo estándar de la época, DES, con claves de 56 bits, era inseguro, algo que algunos responsables públicos negaban. Construyó por menos de 250.000 dólares una máquina específica, Deep Crack, que en julio de 1998 recuperó una clave DES en 56 horas. Y publicó todos los detalles en el libro Cracking DES (O’Reilly, 1998), incluido el código de los chips y del software, impreso en papel y preparado para leerse con OCR. De nuevo, por la misma razón: el papel podía exportarse; el disco, no.
La herencia envenenada: FREAK y Logjam
Con la liberalización del año 2000, la criptografía «de exportación» dejó de tener sentido y los certificados SGC perdieron su razón de ser. Pero los algoritmos debilitados no desaparecieron: siguieron escondidos en las bibliotecas criptográficas y en la configuración de muchos servidores, por compatibilidad.
En 2015 dos ataques demostraron el precio de ese olvido:
- FREAK permitía a un atacante en posición intermedia forzar a clientes y servidores a negociar el RSA «de exportación» de 512 bits y factorizar la clave en horas.
- Logjam hacía lo mismo con el intercambio Diffie-Hellman de 512 bits. Según sus descubridores, el 8,4 % de los principales sitios web del mundo era vulnerable cuando se dio a conocer.
Quince años después de que dejaran de ser obligatorios, los 512 bits de exportación seguían ahí.
Las lecciones para la transición postcuántica
La historia ofrece cuatro enseñanzas que hoy son de plena actualidad:
- Los algoritmos debilitados no mueren solos. Si no se retiran activamente, permanecen durante años en bibliotecas, configuraciones y protocolos, esperando a que alguien los explote. La migración a la criptografía postcuántica exige un inventario criptográfico (CBOM) y la eliminación deliberada de lo obsoleto, no solo la incorporación de lo nuevo.
- La negociación de algoritmos es una superficie de ataque. FREAK y Logjam no rompieron la criptografía fuerte: engañaron a los sistemas para que eligieran la débil. Los esquemas híbridos y los mecanismos de transición deben diseñarse para resistir ataques de degradación.
- La criptoagilidad es una propiedad de diseño. Los sistemas que en 2000 pudieron pasar de 40 a 128 bits con una simple actualización de navegador sobrevivieron; los que tenían los algoritmos «cableados» arrastraron el problema durante años. Lo mismo ocurrirá con el paso a ML-KEM, ML-DSA y sus sucesores.
- Desplegar TLS 1.3 y retirar todo lo anterior. Al poner en marcha un sistema, la buena práctica es usar TLS 1.3 y desactivar SSL 2.0 y 3.0, prohibidos desde 2011 y 2015, y también TLS 1.0 y 1.1, que el IETF declaró obsoletos en 2021 (RFC 8996). TLS 1.2 solo debería mantenerse donde siga siendo necesario por compatibilidad, y con una configuración restringida. TLS 1.3 aprendió de aquellos errores: eliminó los cifrados de exportación, el intercambio de claves RSA y los grupos Diffie-Hellman débiles, firma toda la negociación e incorpora un mecanismo específico contra la degradación de versión, para impedir ataques como FREAK y Logjam. Y es la versión en la que se están desplegando los intercambios de claves híbridos postcuánticos, como X25519MLKEM768, normalizado este verano en el RFC 10024 y negociado por defecto desde 2024 por Chrome y Firefox. Mantener versiones antiguas «por si acaso» es repetir el error de los 512 bits.
Hay, además, una lección de fondo. Las guerras criptográficas enfrentaron la seguridad de todos con el interés de algunos Gobiernos en poder descifrar comunicaciones, y aquel debate no ha terminado: reaparece cada vez que se proponen accesos excepcionales o puertas traseras. La experiencia de los 40 bits demuestra que debilitar la criptografía «solo para algunos» acaba debilitándola para todos.
Lo contaba recientemente en «Camino a la criptoagilidad: qué tener en el radar en la transición postcuántica a finales de 2026»: el calendario ya está fijado, y la historia nos dice que conviene empezar por saber qué criptografía tenemos.
Referencias
- Philip Zimmermann: prefacio de PGP: Source Code and Internals (MIT Press, 1995)
- EFF: Bernstein v. US Department of Justice y sentencia del Noveno Circuito (6 de mayo de 1999)
- EFF: Cracking DES: Secrets of Encryption Research, Wiretap Politics & Chip Design (1998) y EFF DES cracker (Wikipedia)
- IETF: RFC 9846, The Transport Layer Security (TLS) Protocol Version 1.3 (julio de 2026, sustituye al RFC 8446 de 2018), RFC 6176, Prohibiting SSL 2.0 (2011), RFC 7568, Deprecating SSL 3.0 (2015), RFC 10024, hybrid ML-KEM key agreement for TLS 1.3 (agosto de 2026) y RFC 8996, Deprecating TLS 1.0 and TLS 1.1 (2021)
- Weak Diffie-Hellman and the Logjam Attack (2015)
- David Adrian et al.: A Retrospective on the Use of Export Cryptography (Black Hat USA 2016)
