AES-256 versus OFB: escolha uma construção de cifra VPN completa

AES-256 e OFB respondem a perguntas diferentes, e é aqui que as revisões de cifra erram quando os tratam como opções concorrentes. Um nomeia uma cifra de bloco com um tamanho de chave; o outro descreve como uma cifra de bloco se transforma num fluxo para uma mensagem mais longa. Um manual para escolher proteção tem de olhar para a construção inteira, incluindo como o recetor deteta um pacote alterado.

Nomeie as quatro partes da construção

Cada revisão reduz-se a quatro perguntas: que primitiva e tamanho de chave, como as mensagens são processadas com ela, como o recetor rejeita uma alteração não autorizada e como o protocolo gere entradas, chaves e o seu tempo de vida. Uma lista de nomes familiares responde apenas à primeira. A segunda e a terceira são onde vivem as diferenças reais, e a quarta é onde as implementações divergem em silêncio. Faça-as nessa ordem e escreva as respostas.

OFB aparece entre os modos de confidencialidade na publicação do NIST sobre modos de cifra de bloco, e a confidencialidade é tudo o que oferece. Um protocolo que emparelha um modo de cifragem com um MAC separado tem de os compor corretamente, e o nome de um algoritmo não prova essa composição. Por isso o nome do modo, sozinho, não pode resolver uma decisão de implementação.

A quarta pergunta é a que um operador pode realmente verificar no sistema em funcionamento.

Prefira uma construção autenticada

A cifragem autenticada fornece confidencialidade e integridade em conjunto, e as construções AEAD também protegem os dados associados de alterações sem os cifrar. É uma propriedade da proteção de pacotes e não tem relação com o facto de alguém ter iniciado sessão com sucesso.

A Orientação da Netgate para as definições criptográficas do OpenVPN aponta para opções AEAD, entre elas AES-GCM, para o canal de dados, e esse é o tipo de política suportada que se deve seguir. Use as escolhas suportadas pela versão instalada e pelos clientes pares, em vez de copiar uma classificação histórica de modos para uma nova implementação. A compatibilidade legada, os backends criptográficos e o suporte de offload limitam o que está realmente disponível.

Uma construção suportada vence uma composição engenhosa todas as vezes.

Leia o resultado negociado, não a oferta

Uma cifra que aparece numa lista aceite não diz nada sobre a sessão atual. Leia a proteção negociada do canal de dados no cliente ou no gateway e compare-a com a política que queria aplicar. Uma configuração que ainda lista uma opção legada para um par antigo é uma decisão de compatibilidade, não uma afirmação sobre a sessão à sua frente.

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

Num gateway a saída equivalente é a associação de segurança ou o detalhe criptográfico da ligação, conforme a plataforma. Em ambos os casos a oferta e o resultado são factos diferentes. Uma lista que inclui uma opção legada para um par antigo não significa que todas as sessões a usem, e a sessão que a usa é o que precisava de saber.

Registe ambos os factos em conjunto, com a data e a versão do cliente.

Meça apenas o que pode comparar

O débito depende do hardware dos extremos, da implementação, da aceleração, dos tamanhos de pacote e da configuração escolhida. Nem o comprimento da chave nem a palavra OFB lhe dizem qual implementação será mais rápida. Por isso um benchmark de outro site é, no melhor caso, uma pista sobre hardware que outra pessoa possui. Os seus próprios números começam nos seus próprios extremos.

Para uma comparação autorizada, mantenha constantes os extremos, a carga de trabalho e a política exigida, e registe a proteção negociada e as versões de implementação. Depois julgue o resultado por ter terminado ou não a aplicação, quanto perdeu e o que os extremos estavam a fazer, em vez de inferir o custo criptográfico de um único teste de velocidade. Um número produzido noutras condições é uma história, não uma medição.

Se um par antigo não conseguir cumprir a política, é uma decisão de compatibilidade do seu proprietário.

Mantenha a integridade fora do negócio

Desativar as verificações de integridade ou aceitar um servidor não verificado não é uma otimização de desempenho nem uma correção de compatibilidade. Altera a propriedade de segurança para a qual a construção foi escolhida. O mesmo se aplica a alargar a lista de cifras aceites até um par antigo se ligar: a ligação tem sucesso e a política deixa de existir.

Escreva a construção aceite e o seu proprietário no manual, para que a próxima alteração comece por uma decisão e não por uma preferência.

O que quer é uma política que ambos os extremos possam aplicar. Discutir qual nome é o mais forte é outra conversa, e normalmente termina sem decisão.