Por que uma chave Blowfish mais longa não corrige um bloco de 64 bits

Um perfil de VPN oferece Blowfish com uma chave de 448 bits, e alguém propõe usar a chave mais longa para manter a cifra. O comprimento da chave é real, mas é o número errado a otimizar. O Blowfish transforma blocos de 64 bits independentemente do comprimento da chave, e é a largura do bloco que limita quanto tráfego uma chave pode proteger com segurança. Execute as verificações abaixo em ordem e pare na primeira que liberar o serviço, porque um passo posterior não pode reparar um anterior.

Verifique o que os pares realmente negociam

Leia a cifra do canal de dados nas duas pontas, não no perfil que você pretendia implantar. Uma configuração de cliente pode listar várias cifras, e a escolhida é o resultado da negociação entre duas implementações e suas versões. Aumente a verbosidade do log em uma conexão de teste e leia a linha do canal de dados, que nomeia a cifra e o tamanho de chave realmente inicializados.

Se a cifra negociada for AES-GCM ou ChaCha20-Poly1305, pare aqui. Essas construções usam um bloco de 128 bits e autenticam o payload, então o argumento de colisão de 64 bits abaixo não se aplica a elas.

Separe o comprimento da chave da largura do bloco

O Blowfish aceita chaves de 32 a 448 bits, e a documentação do autor do algoritmo registra os dois números separadamente. A chave é o segredo; o bloco é a unidade de transformação. Tornar o segredo mais longo dificulta adivinhá-lo e não faz nada à largura do bloco que a cifra processa.

No modo CBC, a cifra é aplicada a blocos de largura fixa, encadeados com o bloco de texto cifrado anterior e preenchidos no final. Para o Blowfish, essa largura é de 64 bits, ou oito bytes. O escalonamento de chaves pode ser tão grande quanto você quiser; a cadeia ainda avança oito bytes por vez.

Por isso aumentar a chave não é uma mitigação. Ele trata da força bruta contra a chave, enquanto o risco de colisão abaixo é uma propriedade da largura do bloco e do modo.

Aplique a aritmética dos aniversários ao tamanho do bloco

Um bloco de 64 bits tem uma escala de aniversário de cerca de 2^32 blocos cifrados sob uma única chave antes que as colisões se tornem prováveis. Cada bloco carrega oito bytes, então a mesma escala é cerca de 2^35 bytes, ou 32 GiB de dados sob uma única chave.

Trate isso como uma escala, não como uma cota. As colisões são probabilísticas, e se uma vaza algo depende do modo, do padrão de tráfego e de o atacante conseguir reconhecer ou influenciar o texto claro ao redor. O primeiro byte além de 32 GiB não é um evento de descriptografia, e os primeiros 32 GiB não são certificados como seguros.

Os pesquisadores do Sweet32 demonstraram em 2016 ataques práticos contra cifras de bloco de 64 bits, incluindo um cenário de OpenVPN, em condições que exigiam observação e geração de tráfego. Seus padrões publicados e versões de software são contexto histórico, não uma descrição da sua implantação.

Decida se a reutilização de CBC importa aqui

No CBC, um bloco de texto cifrado repetido significa que os dois blocos de texto claro diferem por uma relação conhecida, porque o XOR de encadeamento se cancela. Um atacante que consegue observar o texto cifrado e conhece ou pode influenciar um dos textos claros pode recuperar informações sobre o outro. A chave Blowfish nunca é necessária para isso.

Assim, as perguntas relevantes são por quanto tempo uma chave fica em serviço, quanto tráfego passa sob ela e se alguém pode observar e conduzir esse tráfego. A renovação de chaves reduz a contagem de blocos por chave, mas um intervalo de tempo não é um limite de bytes: um túnel movimentado pode mover muito mais dados do que um ocioso na mesma hora. Se você mantém uma cifra legada, derive o limite da construção e do volume real, não de um número redondo.

Se o volume medido por chave permanece muito abaixo da escala de aniversário, a exposição é menor. Ainda assim não é zero e ainda é motivo para planejar uma migração em vez de parar de se preocupar.

Substitua a cifra, não a chave

Mova o serviço para uma cifra AEAD suportada e confirme que os dois pares, suas versões e seus backends criptográficos conseguem negociá-la. Aumentar a chave Blowfish não muda nada que importe, e adivinhar uma nova diretiva em um cliente é como um túnel que funciona se torna quebrado. Teste a mudança em um cliente e um servidor antes de tocar no resto do parque. Mantenha o perfil antigo disponível para reversão até que a nova cifra tenha passado por um ciclo de conexão completo.

Mantenha a verificação de certificados e a autenticação de contas durante a mudança. Elas respondem a perguntas diferentes: um login bem-sucedido não pode alargar um bloco, e uma cifra de dados melhor não desculpa confiar no servidor errado.

Encerre a verificação lendo novamente a cifra negociada em uma nova conexão e confirmando depois que a cifra antiga não é mais aceita. Se um par ainda a oferece, a migração não terminou, diga o que disser o perfil do outro lado.