AES-GCM o ChaCha20-Poly1305: triar el xifratge de dades d'una VPN

Tots dos noms són construccions AEAD, tots dos estan normalitzats, i en un servidor x86 actual qualsevol dels dos omplirà un enllaç de gigabit sense un esforç visible. L'elecció deixa de ser arbitrària quan surts d'aquell servidor: els encaminadors barats, els telèfons antics i els aparells virtuals sovint no tenen acceleració AES, i allà la diferència és gran. Per tant, la comparació no és quin xifratge és més ràpid, sinó quin xifratge funciona bé en aquest conjunt de punts finals i si el protocol ofereix alguna opció.

La mateixa feina, nuclis diferents

Totes dues construccions donen confidencialitat i integritat en una sola passada i autentiquen les dades associades, i per això els protocols VPN les fan servir per al canal de dades. La diferència és a dins: AES-GCM és el xifratge de blocs AES en mode comptador amb un autenticador polinòmic sobre GF(2^128), mentre que ChaCha20-Poly1305 és un xifratge de flux amb clau de 256 bits i un autenticador d'un sol ús separat.

El que importa operativament és comú: tots dos fallen catastròficament si es reutilitza el nonce, tots dos necessiten gestionar l'espai de nonce per clau, i cap dels dos arregla un company que autentica la cosa equivocada. Un perfil que diu AES-256-GCM no és més segur que un que diu CHACHA20-POLY1305; tots dos són forts quan la implementació és correcta.

On guanya AES-GCM

AES té instruccions dedicades a la majoria de CPU modernes: AES-NI a x86, les extensions criptogràfiques a ARMv8 i equivalents als dissenys recents de POWER i RISC-V. Quan hi són, GCM executa diversos blocs en paral·lel per classe de cicle i la implementació de programari és irrellevant. És el cas habitual en servidors, ordinadors d'escriptori i telèfons actuals, i per això el consell d'usar AES és un bon valor per defecte en un centre de dades.

El problema és el cas de segon ordre. Sense instruccions dedicades, AES en programari és lent, i les implementacions de programari basades en taules són les que tenen un historial llarg de problemes de temps de memòria cau. Un concentrador VPN en una màquina virtual l'amfitrió de la qual no exposa les banderes AES al convidat és exactament aquest cas, i és fàcil de passar per alt perquè la CPU de l'amfitrió sí que té la funció.

Comprova què veu realment el procés, no què admet la CPU: grep -o aes /proc/cpuinfo | head -1 a Linux, o la bandera de funció equivalent al model de CPU de l'hipervisor.

On guanya ChaCha20-Poly1305

ChaCha20 és ràpid en programari portable perquè només fa servir suma, rotació i XOR, i les seves implementacions eviten per disseny les cerques a taules dependents del secret. En un dispositiu sense acceleració AES això és un avantatge material, i és la raó per la qual WireGuard el va triar: la descripció del protocol WireGuard llista ChaCha20-Poly1305 com el seu xifratge de dades sense alternativa.

Aquesta única decisió diu una cosa útil: en maquinari on AES està accelerat, WireGuard cedeix una mica de rendiment respecte a AES-GCM, i els seus autors ho van acceptar a canvi d'un comportament previsible en telèfons, encaminadors domèstics i amfitrions de contenidors. Si la teva flota és sobretot caixes ARM petites, aquest intercanvi et afavoreix.

El cas contrari és un concentrador x86 ocupat, on AES-GCM amb AES-NI és el camí més ràpid i millor suportat, i on ChaCha20 costa CPU mesurable per gigabit. Cap de les dues construccions no és una feblesa; la qüestió és quina executa barata el teu maquinari.

Què et deixa triar realment el teu protocol

Fixa't en la separació a OpenVPN: el canal de control i el canal de dades es negocien per separat, així que el conjunt que veus per a TLS no diu res sobre el xifratge que protegeix la teva càrrega. El resum de la sessió informa dels dos, i llegir només un dels dos és una font habitual de confusió.

A OpenVPN, el xifratge del canal de dades ve de la llista data-ciphers als dos extrems. Si la llista del servidor i la del client no s'intersequen, la connexió o recorre al que permet data-ciphers-fallback o falla del tot, i aquesta fallada s'atribueix normalment a la capa equivocada. Posa la mateixa llista als dos costats, i després confirma el resultat negociat al registre en lloc de suposar que s'ha respectat l'ordre de la llista.

Decideix a partir de tres fets sobre el desplegament

Primer, els punts finals tenen acceleració AES? Si tots els companys en tenen, AES-GCM és l'opció més barata i el valor per defecte en la majoria de configuracions mantingudes. Si una part significativa són encaminadors petits o telèfons antics, ChaCha20-Poly1305 evita que la cua de la flota es converteixi en el límit de capacitat.

Segon, el protocol ofereix alguna opció? Amb WireGuard la decisió ja està presa per tu, i la feina útil és verificar que les eines del voltant no hi substitueixin res en silenci. Amb OpenVPN i IPsec, la resposta és una línia de configuració i un resultat negociat per enregistrar.

Tercer, es poden posar d'acord els dos extrems? Un xifratge que un company no implementa no és una decisió de rendiment, és una caiguda. Per això la llista de companys importa més que qualsevol referència: una flota mixta necessita la intersecció de capacitats, no la preferència de la màquina més ràpida.

Si mesures, mantén idèntics el dispositiu, el punt final i la càrrega i canvia una sola cosa. Una prova que compara dos servidors en regions diferents mesura la ruta, no el xifratge, i una referència en un portàtil no diu res sobre un amfitrió de contenidors amb les banderes de CPU emmascarades. Compara, i després anota quin xifratge s'ha negociat realment: aquest registre val més que la referència.