AES-GCM ou ChaCha20-Poly1305: escolher a cifra de dados de uma VPN

Ambos os nomes são construções AEAD, ambos estão normalizados, e num servidor x86 atual qualquer um deles satura um link gigabit sem esforço visível. A escolha deixa de ser arbitrária quando sais desse servidor: routers baratos, telemóveis antigos e aparelhos virtuais muitas vezes não têm aceleração AES, e aí a diferença é grande. Portanto, a comparação não é qual cifra é mais rápida, mas qual cifra funciona bem neste conjunto de extremos e se o protocolo sequer oferece uma escolha.

O mesmo trabalho, núcleos diferentes

Ambas as construções dão confidencialidade e integridade numa só passagem e autenticam os dados associados, e é por isso que os protocolos VPN as usam para o canal de dados. A diferença está dentro: AES-GCM é a cifra de blocos AES em modo contador com um autenticador polinomial sobre GF(2^128), enquanto ChaCha20-Poly1305 é uma cifra de fluxo com chave de 256 bits e um autenticador de uso único separado.

O que importa em operação é comum: ambas falham catastroficamente com a reutilização do nonce, ambas precisam de gestão do espaço de nonce por chave, e nenhuma corrige um par que autentica a coisa errada. Um perfil que diz AES-256-GCM não é mais seguro do que um que diz CHACHA20-POLY1305; ambos são fortes quando a implementação está correta.

Onde o AES-GCM ganha

O AES tem instruções dedicadas na maioria das CPU modernas: AES-NI em x86, as extensões criptográficas em ARMv8 e equivalentes nos desenhos recentes POWER e RISC-V. Quando existem, o GCM executa vários blocos em paralelo por classe de ciclo e a implementação em software torna-se irrelevante. É o caso comum em servidores, computadores de secretária e telemóveis atuais, e é por isso que o conselho de usar AES é um valor por omissão razoável num centro de dados.

O problema é o caso de segunda ordem. Sem instruções dedicadas, o AES em software é lento, e as implementações de software baseadas em tabelas são as que têm um longo historial de problemas de tempo de cache. Um concentrador VPN numa máquina virtual cujo anfitrião não expõe as flags AES ao convidado é exatamente este caso, e é fácil de perder porque a CPU do anfitrião tem a funcionalidade.

Verifica o que o processo vê realmente, não o que a CPU suporta: grep -o aes /proc/cpuinfo | head -1 no Linux, ou a flag de funcionalidade equivalente no modelo de CPU do hipervisor.

Onde o ChaCha20-Poly1305 ganha

O ChaCha20 é rápido em software portátil porque usa apenas adição, rotação e XOR, e as suas implementações evitam por desenho as pesquisas em tabelas dependentes do segredo. Num dispositivo sem aceleração AES isso é uma vantagem material, e é a razão pela qual o WireGuard o escolheu: a descrição do protocolo WireGuard lista o ChaCha20-Poly1305 como a sua cifra de dados sem alternativa.

Essa única escolha diz algo útil: em hardware onde o AES é acelerado, o WireGuard abdica de algum débito em comparação com o AES-GCM, e os autores aceitaram isso em troca de um comportamento previsível em telemóveis, routers domésticos e anfitriões de contentores. Se a tua frota é sobretudo caixas ARM pequenas, essa troca é a teu favor.

O caso contrário é um concentrador x86 ocupado, onde o AES-GCM com AES-NI é o caminho mais rápido e melhor suportado, e onde o ChaCha20 custa CPU mensurável por gigabit. Nenhuma das construções é uma fraqueza; a questão é qual delas o teu hardware executa barato.

O que o teu protocolo te deixa realmente escolher

Repara na separação no OpenVPN: o canal de controlo e o canal de dados são negociados em separado, pelo que o conjunto que vês para TLS não diz nada sobre a cifra que protege a tua carga. O resumo da sessão reporta ambos, e ler apenas um dos dois é uma fonte comum de confusão.

No OpenVPN a cifra do canal de dados vem da lista data-ciphers em ambas as pontas. Se a lista do servidor e a do cliente não se cruzarem, a ligação ou recua para o que o data-ciphers-fallback permite ou falha por completo, e essa falha é normalmente atribuída à camada errada. Coloca a mesma lista dos dois lados e depois confirma o resultado negociado no registo em vez de assumir que a ordem da lista foi respeitada.

Decide a partir de três factos sobre a implementação

Primeiro, os extremos têm aceleração AES? Se cada par tiver, o AES-GCM é a escolha mais barata e o valor por omissão na maioria das configurações mantidas. Se uma parte significativa for de routers pequenos ou telemóveis antigos, o ChaCha20-Poly1305 impede que a cauda da frota se torne o limite de capacidade.

Segundo, o protocolo oferece sequer uma escolha? Com o WireGuard a decisão já está tomada por ti, e o trabalho útil é verificar que as ferramentas à volta não substituem outra coisa em silêncio. Com o OpenVPN e o IPsec, a resposta é uma linha de configuração e um resultado negociado a registar.

Terceiro, as duas pontas conseguem chegar a acordo? Uma cifra que um par não implementa não é uma decisão de desempenho, é uma paragem. Por isso a lista de pares importa mais do que qualquer referência: uma frota mista precisa da interseção de capacidades, não da preferência da máquina mais rápida.

Se medires, mantém idênticos o dispositivo, o extremo e a carga e muda uma só coisa. Um teste que compara dois servidores em regiões diferentes mede a rota, não a cifra, e uma referência num portátil não diz nada sobre um anfitrião de contentores cujas flags de CPU estão mascaradas. Compara e depois anota qual cifra foi realmente negociada: esse registo vale mais do que a referência.