AES-GCM ou ChaCha20-Poly1305: escoller o cifrado de datos dunha VPN

Ambos nomes son construcións AEAD, ambos están normalizados, e nun servidor x86 actual calquera dos dous saturará unha ligazón de gigabit sen esforzo visible. A elección deixa de ser arbitraria cando saes dese servidor: os routers baratos, os teléfonos vellos e os dispositivos virtuais a miúdo carecen de aceleración AES, e alí a diferenza é grande. Así que a comparación non é cal cifrado é máis rápido, senón cal cifrado funciona ben neste conxunto de extremos e se o protocolo ofrece sequera unha elección.

O mesmo traballo, núcleos distintos

Ambas construcións dan confidencialidade e integridade nunha soa pasada e autentican os datos asociados, e por iso os protocolos VPN as usan para a canle de datos. A diferenza está dentro: AES-GCM é o cifrado de bloques AES en modo contador cun autenticador polinómico sobre GF(2^128), mentres que ChaCha20-Poly1305 é un cifrado de fluxo con clave de 256 bits e un autenticador dun só uso separado.

O que importa en operación é común: ambos fallan de xeito catastrófico ao reutilizar o nonce, ambos precisan xestionar o espazo de nonce por clave, e ningún arranxa un par que autentica o incorrecto. Un perfil que di AES-256-GCM non é máis seguro que un que di CHACHA20-POLY1305; ambos son fortes cando a implementación é correcta.

Onde gaña AES-GCM

AES ten instrucións dedicadas na maioría das CPU modernas: AES-NI en x86, as extensións criptográficas en ARMv8 e equivalentes nos deseños recentes de POWER e RISC-V. Cando están presentes, GCM executa varios bloques en paralelo por clase de ciclo e a implementación de software resulta irrelevante. É o caso habitual en servidores, ordenadores de sobremesa e teléfonos actuais, e por iso o consello de usar AES é un valor por defecto razoable nun centro de datos.

O problema é o caso de segunda orde. Sen instrucións dedicadas, AES en software é lento, e as implementacións de software baseadas en táboas son as que teñen un longo historial de problemas de tempo de caché. Un concentrador VPN nunha máquina virtual cuxo anfitrión non expón as bandeiras AES ao convidado é exactamente este caso, e é fácil pasalo por alto porque a CPU do anfitrión si ten a función.

Comproba o que o proceso ve realmente, non o que a CPU admite: grep -o aes /proc/cpuinfo | head -1 en Linux, ou a bandeira de función equivalente no modelo de CPU do hipervisor.

Onde gaña ChaCha20-Poly1305

ChaCha20 é rápido en software portátil porque só usa suma, rotación e XOR, e as súas implementacións evitan por deseño as buscas en táboas dependentes do segredo. Nun dispositivo sen aceleración AES iso é unha vantaxe material, e é a razón pola que WireGuard o elixiu: a descrición do protocolo WireGuard enumera ChaCha20-Poly1305 como o seu cifrado de datos sen alternativa.

Esa única decisión di algo útil: en hardware onde AES está acelerado, WireGuard cede algo de rendemento fronte a AES-GCM, e os seus autores aceptárono a cambio dun comportamento previsible en teléfonos, routers domésticos e anfitrións de contedores. Se a túa frota é sobre todo caixas ARM pequenas, ese intercambio xoga ao teu favor.

O caso contrario é un concentrador x86 ocupado, onde AES-GCM con AES-NI é a ruta máis rápida e mellor soportada, e onde ChaCha20 custa CPU medible por gigabit. Ningunha das dúas construcións é unha debilidade; a cuestión é cal executa barata o teu hardware.

Que che deixa elixir realmente o teu protocolo

Fíxate na separación en OpenVPN: a canle de control e a canle de datos négocianse por separado, así que o conxunto que ves para TLS non di nada sobre o cifrado que protexe a túa carga. O resumo da sesión informa de ambos, e ler só un dos dous é unha fonte habitual de confusión.

En OpenVPN o cifrado da canle de datos vén da lista data-ciphers nos dous extremos. Se a lista do servidor e a do cliente non se cruzan, a conexión ou recorre ao que permite data-ciphers-fallback ou falla por completo, e ese fallo adoita atribuírse á capa equivocada. Pon a mesma lista nos dous lados e despois confirma o resultado negociado no rexistro en lugar de supoñer que se respectou a orde da lista.

Decide a partir de tres feitos sobre o despregamento

Primeiro, os extremos teñen aceleración AES? Se a ten cada par, AES-GCM é a opción máis barata e o valor por defecto na maioría das configuracións mantidas. Se unha parte significativa son routers pequenos ou teléfonos vellos, ChaCha20-Poly1305 evita que a cola da frota se converta no límite de capacidade.

Segundo, ofrece o protocolo algunha elección? Con WireGuard a decisión xa está tomada por ti, e o traballo útil é verificar que as ferramentas que o rodean non substitúen algo máis en silencio. Con OpenVPN e IPsec, a resposta é unha liña de configuración e un resultado negociado que rexistrar.

Terceiro, poden poñerse de acordo os dous extremos? Un cifrado que un par non implementa non é unha decisión de rendemento, é unha caída. Por iso a lista de pares importa máis que calquera referencia: unha frota mixta necesita a intersección de capacidades, non a preferencia da máquina máis rápida.

Se mides, mantén idénticos o dispositivo, o extremo e a carga e cambia unha soa cousa. Unha proba que compara dous servidores en rexións distintas mide a ruta, non o cifrado, e unha referencia nun portátil non di nada sobre un anfitrión de contedores cuxas bandeiras de CPU están enmascaradas. Compara, e despois anota que cifrado se negociou realmente: ese rexistro vale máis que a referencia.