Por que unha chave Blowfish máis longa non arranxa un bloque de 64 bits

Un perfil de VPN ofrece Blowfish cunha chave de 448 bits, e alguén propón usar a chave máis longa para conservar o cifrado. A lonxitude da chave é real, pero é o número equivocado que optimizar. Blowfish transforma bloques de 64 bits independentemente da lonxitude da chave, e é a largura do bloque a que limita canto tráfico pode protexer unha chave con seguridade. Executa as comprobacións seguintes en orde e detente na primeira que libre o servizo, porque un paso posterior non pode reparar un anterior.

Comproba que negocian realmente os pares

Le o cifrado do canal de datos nos dous extremos, non do perfil que pensabas despregar. Unha configuración de cliente pode listar varios cifrados, e o escollido é o resultado da negociación entre dúas implementacións e as súas versións. Aumenta a verbosidade do rexistro nunha conexión de proba e le a liña do canal de datos, que nomea o cifrado e o tamaño de chave que realmente se inicializaron.

Se o cifrado negociado é AES-GCM ou ChaCha20-Poly1305, detente aquí. Esas construcións usan un bloque de 128 bits e autentican a carga útil, así que o argumento de colisión de 64 bits de abaixo non se lles aplica.

Separa a lonxitude de chave da largura de bloque

Blowfish acepta chaves de 32 a 448 bits, e a documentación do autor do algoritmo recolle os dous números por separado. A chave é o segredo; o bloque é a unidade de transformación. Alongar o segredo fai máis difícil adiviñalo e non cambia nada na largura do bloque que procesa o cifrado.

En modo CBC o cifrado aplícase a bloques de largura fixa, encadeados co bloque de texto cifrado anterior e enchidos ao final. Para Blowfish esa largura é de 64 bits, ou oito bytes. A programación de chaves pode ser tan grande como queiras; a cadea avanza igualmente oito bytes á vez.

Por iso alongar a chave non é unha mitigación. Aborda a forza bruta contra a chave, mentres que o risco de colisión de abaixo é unha propiedade da largura de bloque e do modo.

Aplica a aritmética dos aniversarios ao tamaño do bloque

Un bloque de 64 bits ten unha escala de aniversario de aproximadamente 2^32 bloques cifrados baixo unha soa chave antes de que as colisións sexan probables. Cada bloque leva oito bytes, así que a mesma escala son uns 2^35 bytes, ou 32 GiB de datos baixo unha única chave.

Trátao como unha escala, non como unha cota. As colisións son probabilísticas, e se unha filtra algo depende do modo, do patrón de tráfico e de se o atacante pode recoñecer ou influír no texto claro circundante. O primeiro byte máis aló de 32 GiB non é un evento de descifrado, e os primeiros 32 GiB non están certificados como seguros.

Os investigadores de Sweet32 demostraron en 2016 ataques prácticos contra cifrados de bloque de 64 bits, incluído un escenario de OpenVPN, en condicións que requirían observación e xeración de tráfico. Os seus valores por defecto e versións de software publicados son contexto histórico, non unha descrición do teu despregamento.

Decide se a reutilización de CBC importa aquí

En CBC, un bloque de texto cifrado repetido significa que os dous bloques de texto claro difiren nunha relación coñecida, porque o XOR de encadeamento se cancela. Un atacante que pode observar o texto cifrado e coñece ou pode influír nun dos textos claros pode recuperar información sobre o outro. A chave Blowfish nunca é necesaria para iso.

Así, as preguntas relevantes son canto tempo permanece unha chave en servizo, canto tráfico pasa baixo ela e se alguén pode observar e dirixir ese tráfico. A renovación de chaves reduce o número de bloques por chave, pero un intervalo de tempo non é un límite de bytes: un túnel ocupado pode mover moitos máis datos que un inactivo na mesma hora. Se conservas un cifrado herdado, deriva o límite da construción e do volume real, non dun número redondo.

Se o volume medido por chave se mantén moi por baixo da escala de aniversario, a exposición é menor. Aínda non é cero e aínda é un motivo para planificar unha migración en vez de deixar de preocuparse.

Substitúe o cifrado, non a chave

Move o servizo a un cifrado AEAD compatible e confirma que os dous pares, as súas versións e os seus backends criptográficos poden negocialo. Alongar a chave Blowfish non cambia nada que importe, e adiviñar unha nova directiva nun cliente é como un túnel que funciona se converte nun roto. Proba o cambio nun cliente e un servidor antes de tocar o resto do parque. Mantén o perfil antigo dispoñible para reverter ata que o novo cifrado supere un ciclo de conexión completo.

Mantén a verificación de certificados e a autenticación de contas durante o cambio. Responden a preguntas distintas: un inicio de sesión correcto non pode ensanchar un bloque, e un mellor cifrado de datos non escusa confiar no servidor equivocado.

Pecha a comprobación relendo o cifrado negociado nunha conexión nova e confirmando despois que o cifrado antigo xa non se acepta. Se un par aínda o ofrece, a migración non rematou, diga o que diga o perfil da outra banda.