Resumen

  • Para el ataque de texto conocido que planteaba la RFC 2405, acortar la vida de una clave no era suficiente: los datagramas IP suelen empezar con texto previsible o fácil de adivinar.
  • DES-CBC aportaba confidencialidad, no autenticación. El IV, la búsqueda de claves, la integridad y la gestión de asociaciones de seguridad resolvían problemas distintos.

Una vida útil sin cronómetro universal

Publicada en noviembre de 1998, la RFC 2405 especificó DES en modo CBC como mecanismo de confidencialidad de ESP. No estableció una duración fija ni un límite general de datos por clave. Dejó esa decisión en función del valor de la información protegida y de los recursos que se atribuyeran a un atacante. Es un juicio de riesgo, no la promesa de que renovar una clave vuelva resistente al algoritmo.

El documento explica la tensión: citó el diseño de una máquina de un millón de dólares que, según una estimación de 1993, podía recuperar una clave DES en tres horas y media. También señaló que los datagramas IP suelen comenzar con encabezados conocidos o adivinables. Su conclusión se refería al modelo de ataque descrito: cambiar las claves con frecuencia no lo impediría. Son afirmaciones históricas recogidas en 1998, no una cotización, benchmark ni prueba actual. La RFC añadió una salvedad propia de su época: DES-CBC todavía ofrecía más privacidad que enviar el datagrama en claro.

Tres protecciones, tres funciones

Cada datagrama ESP llevaba un vector de inicialización explícito de ocho octetos. La RFC exigía que fuera aleatorio y prohibía un contador u otra fuente con baja distancia de Hamming entre valores sucesivos. Así, el receptor podía iniciar el descifrado aunque otro datagrama se hubiera perdido o reordenado. La independencia del paquete no autenticaba el texto cifrado ni aumentaba el coste de buscar una clave DES.

La RFC dice expresamente que DES-CBC no autentica. Desaconseja con firmeza usarlo sin un mecanismo de autenticación correspondiente y describe el riesgo de recortar y pegar bloques CBC. La autenticación podía atender ese problema de integridad; rotar la clave no la sustituía. La confianza del sistema dependía también de la implementación, la gestión de asociaciones de seguridad y todos los nodos participantes.

De soporte obligatorio a «MUST NOT»

Las reglas posteriores de algoritmos ESP cambiaron por etapas. RFC 4305 pasó DES-CBC a «SHOULD NOT» después de requisitos que exigían implementarlo. RFC 4835 mantuvo ese nivel; RFC 7321 lo cambió a «MUST NOT»; RFC 8221 lo conserva. La secuencia describe requisitos de interoperabilidad fechados, no prueba cuándo todos los equipos dejaron de usar DES.

Una norma puede reducir la presión de compatibilidad futura sin borrar sistemas instalados. Especificación, configuración local, transform negociado, procesamiento autenticado y uso medido son evidencias distintas. Ninguna se deduce de un párrafo sobre la vida de una clave.

Fuentes