Por que o AES-256 não descreve uma suíte de criptografia VPN

Pergunte qual criptografia uma VPN usa e a resposta costuma vir em uma palavra: AES-256, ou ChaCha20, ou talvez WireGuard. Essa resposta nomeia um componente de uma camada, enquanto o que realmente protege a conexão é um conjunto de algoritmos que cumprem quatro papéis diferentes. Confundir o componente com a disposição é o erro mais comum nessas conversas e produz comparações que não se podem resolver.

Quatro trabalhos dentro de uma conexão

A criptografia em massa converte texto claro em texto cifrado para o canal de dados, e sua chave é derivada em vez de transmitida. A proteção de integridade detecta alteração, o que é um trabalho separado mesmo quando uma única construção faz as duas coisas. O estabelecimento de chaves produz o material compartilhado de tráfego, e a autenticação do par decide quem está do outro lado. Se faltar qualquer um deles, a conexão não é segura, por mais forte que seja a peça restante.

Alguns projetos fundem dois papéis em um. AES-GCM e ChaCha20-Poly1305 são construções de criptografia autenticada, então confidencialidade e integridade vêm juntas; AES-CBC não, e exige um código de autenticação de mensagem separado com a própria chave. Por isso ler uma proposta como um saco de números independentes lê mal as que foram projetadas como pares.

Os papéis também ficam em camadas diferentes, e por isso a mesma palavra pode significar coisas distintas em dois produtos. Uma cifra de bloco dentro do ESP e uma cifra de bloco dentro do TLS são a mesma primitiva em negociações diferentes com requisitos diferentes. Por isso citar uma primitiva sem o modo e a camada pode ser pior do que não citar nada.

Por que o nome de uma cifra quase não diz nada

Leve a frase AES-256 a sério por um momento: ela identifica uma cifra de bloco e um tamanho de chave. Não diz nada sobre o modo de operação, se a integridade é fornecida, nem sobre como as chaves foram estabelecidas ou como o par foi autenticado. Dois produtos podem anunciar ambos AES-256 e diferir em todo o resto, inclusive um que o associa a um modo não autenticado e outro que usa um modo AEAD com troca de chaves moderna.

O TLS 1.3 levou essa separação para o padrão, o que é uma correção útil para quem aprendeu o vocabulário mais antigo. Suas suítes de cifra nomeiam apenas o AEAD e o hash, enquanto grupos de troca de chaves e algoritmos de assinatura são negociados como parâmetros separados. Por isso um nome de suíte TLS 1.3 não é comparável a um nome de suíte TLS 1.2 em igualdade de condições, embora os dois apareçam no mesmo campo de um arquivo de configuração. Um auditor que compara as duas cadeias diretamente tira uma conclusão que o protocolo não sustenta. Leia também o grupo negociado e os parâmetros de assinatura, ou a comparação fica incompleta.

O WireGuard escolhe o caminho oposto e remove a negociação quase por completo: o protocolo fixa um conjunto de algoritmos, então duas implementações interoperam ou não. É uma escolha de projeto legítima, e também significa que a pergunta sobre qual suíte o WireGuard negocia não tem resposta que mereça comparação. Se você o audita, leia a especificação uma vez e depois audite a gestão de chaves em volta dela em vez da negociação.

A camada decide o vocabulário

Uma implantação de IPsec negocia duas vezes: uma proposta IKE para o canal de controle e uma transformação ESP para os dados, e as duas podem diferir legitimamente. Ler a primeira e supor que descreve a segunda é uma fonte comum de confusão durante uma auditoria, porque o arquivo de configuração menciona as duas e a interessante é a segunda.

Um nome disponível em uma biblioteca não é implementado automaticamente para outro caminho de dados. Por isso a afirmação de que nosso produto suporta AES-256 é mais fraca do que soa, e por isso um problema de interoperabilidade costuma ser resolvido encontrando a interseção mantida em vez de habilitar todos os algoritmos antigos dos dois lados.

A especificação do TLS 1.3 é o exemplo publicado mais claro da separação, porque define a suíte como um par e move o resto para a própria negociação. Uma vez que essa forma é familiar, a proposta IPsec e o único conjunto fixo do WireGuard leem-se como variantes da mesma ideia.

Leia o resultado negociado e então pare

Uma proposta configurada não é prova do que dois pares escolheram. A sessão viva carrega a resposta, e qualquer implementação comum pode relatá-la sem capturar pacotes.

openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show

Na saída, leia os algoritmos selecionados em vez da lista oferecida. Se a resposta for mais fraca do que a política pretendia, a correção pertence à configuração da proposta de um dos lados, e uma divergência em implementações modernas costuma aparecer como negociação falhada e não como rebaixamento silencioso.

Depois lembre-se do que a suíte não cobre. Rotas, permissões de aplicações, registro e retenção são decisões separadas com a própria revisão, e uma disposição criptográfica compatível não diz nada sobre elas. A discussão sobre a cifra vale a pena, mas responde a uma pergunta mais estreita do que a que a maioria das pessoas realmente faz.

Mantenha o vocabulário preciso e o argumento encurta. Uma suíte é um conjunto de papéis em uma camada, uma cifra é um componente, e o resultado negociado é a única coisa que descreve a conexão que você realmente tem. Todo o resto na comparação é decoração.