Por qué una clave Blowfish más larga no arregla un bloque de 64 bits

Un perfil de VPN ofrece Blowfish con una clave de 448 bits, y alguien propone usar la clave más larga para conservar el cifrado. La longitud de la clave es real, pero es el número equivocado que optimizar. Blowfish transforma bloques de 64 bits sin importar la longitud de la clave, y la anchura del bloque es lo que limita cuánto tráfico puede proteger una clave con seguridad. Ejecute las comprobaciones siguientes en orden y deténgase en la primera que despeje el servicio, porque un paso posterior no puede reparar uno anterior.

Compruebe qué negocian realmente los pares

Lea el cifrado del canal de datos en ambos extremos, no del perfil que pensaba desplegar. Una configuración de cliente puede enumerar varios cifrados, y el elegido es el resultado de la negociación entre dos implementaciones y sus versiones. Aumente la verbosidad del registro en una conexión de prueba y lea la línea del canal de datos, que nombra el cifrado y el tamaño de clave que se inicializaron realmente.

Si el cifrado negociado es AES-GCM o ChaCha20-Poly1305, deténgase aquí. Esas construcciones usan un bloque de 128 bits y autentican la carga útil, así que el argumento de colisión de 64 bits que sigue no se les aplica.

Separe la longitud de clave de la anchura de bloque

Blowfish acepta claves de 32 a 448 bits, y la documentación del autor del algoritmo recoge ambos números por separado. La clave es el secreto; el bloque es la unidad de transformación. Alargar el secreto dificulta adivinarlo y no hace nada a la anchura del bloque que procesa el cifrado.

En modo CBC, el cifrado se aplica a bloques de anchura fija, encadenados con el bloque de texto cifrado anterior y rellenados al final. Para Blowfish esa anchura es de 64 bits, u ocho bytes. El calendario de claves puede ser tan grande como quiera; la cadena sigue avanzando ocho bytes a la vez.

Por eso alargar la clave no es una mitigación. Atiende a la fuerza bruta contra la clave, mientras que el riesgo de colisión de abajo es una propiedad de la anchura de bloque y del modo.

Aplique la aritmética de cumpleaños al tamaño del bloque

Un bloque de 64 bits tiene una escala de cumpleaños de unos 2^32 bloques cifrados bajo una sola clave antes de que las colisiones sean probables. Cada bloque lleva ocho bytes, así que la misma escala son unos 2^35 bytes, o 32 GiB de datos bajo una sola clave.

Trátelo como una escala, no como una cuota. Las colisiones son probabilísticas, y que una filtre algo depende del modo, del patrón de tráfico y de si el atacante puede reconocer o influir en el texto plano circundante. El primer byte más allá de 32 GiB no es un evento de descifrado, y los primeros 32 GiB no están certificados como seguros.

Los investigadores de Sweet32 demostraron en 2016 ataques prácticos contra cifrados de bloque de 64 bits, incluido un escenario de OpenVPN, en condiciones que exigían observación y generación de tráfico. Sus valores predeterminados y versiones de software publicados son contexto histórico, no una descripción de su despliegue.

Decida si la reutilización de CBC importa aquí

En CBC, un bloque de texto cifrado repetido significa que los dos bloques de texto plano difieren en una relación conocida, porque el XOR de encadenamiento se cancela. Un atacante que pueda observar el texto cifrado y conozca o pueda influir en uno de los textos planos puede recuperar información sobre el otro. La clave Blowfish nunca es necesaria para eso.

Así que las preguntas pertinentes son cuánto tiempo permanece una clave en servicio, cuánto tráfico pasa bajo ella y si alguien puede observar y dirigir ese tráfico. La renovación de claves reduce el número de bloques por clave, pero un intervalo de tiempo no es un límite de bytes: un túnel ocupado puede mover muchos más datos que uno inactivo en la misma hora. Si conserva un cifrado heredado, derive el límite de la construcción y del volumen real, no de un número redondo.

Si el volumen medido por clave se mantiene muy por debajo de la escala de cumpleaños, la exposición es menor. Sigue sin ser cero y sigue siendo motivo para planificar una migración en lugar de dejar de preocuparse.

Sustituya el cifrado, no la clave

Mueva el servicio a un cifrado AEAD compatible y confirme que ambos pares, sus versiones y sus backends criptográficos pueden negociarlo. Alargar la clave Blowfish no cambia nada que importe, y adivinar una nueva directiva en un cliente es como un túnel que funciona se convierte en uno roto. Pruebe el cambio en un cliente y un servidor antes de tocar el resto del parque. Mantenga el perfil antiguo disponible para revertir hasta que el nuevo cifrado haya superado un ciclo de conexión completo.

Mantenga la verificación de certificados y la autenticación de cuentas durante el cambio. Responden a preguntas distintas: un inicio de sesión correcto no puede ensanchar un bloque, y un mejor cifrado de datos no excusa confiar en el servidor equivocado.

Cierre la comprobación leyendo de nuevo el cifrado negociado en una conexión nueva y confirmando después que el cifrado antiguo ya no se acepta. Si un par todavía lo ofrece, la migración no ha terminado, diga lo que diga el perfil del otro lado.