AES-GCM sau ChaCha20-Poly1305: alegerea cifrului de date pentru un VPN

Ambele nume sunt construcții AEAD, ambele sunt standardizate, iar pe un server x86 actual oricare dintre ele va satura un link gigabit fără efort vizibil. Alegerea încetează să mai fie arbitrară când părăsești acel server: routerele ieftine, telefoanele vechi și aparatele virtuale nu au adesea accelerare AES, iar acolo diferența este mare. Deci comparația nu este care cifru este mai rapid, ci care cifru funcționează bine pe acest set de puncte terminale și dacă protocolul oferă măcar o alegere.

Aceeași muncă, nuclee diferite

Ambele construcții oferă confidențialitate și integritate într-o singură trecere și autentifică datele asociate, de aceea protocoalele VPN le folosesc pentru canalul de date. Diferența este în interior: AES-GCM este cifrul de blocuri AES în modul contor cu un autentificator polinomial peste GF(2^128), în timp ce ChaCha20-Poly1305 este un cifru de flux cu cheie de 256 de biți și un autentificator de unică folosință separat.

Ceea ce contează operațional este comun: ambele eșuează catastrofal la reutilizarea nonce-ului, ambele au nevoie de gestionarea spațiului nonce pentru fiecare cheie și niciunul nu repară un partener care autentifică lucrul greșit. Un profil care spune AES-256-GCM nu este mai sigur decât unul care spune CHACHA20-POLY1305; ambele sunt puternice când implementarea este corectă.

Unde câștigă AES-GCM

AES are instrucțiuni dedicate pe majoritatea procesoarelor moderne: AES-NI pe x86, extensiile criptografice pe ARMv8 și echivalente pe modelele recente POWER și RISC-V. Când acestea există, GCM rulează mai multe blocuri în paralel pe clasă de ciclu, iar implementarea software devine irelevantă. Acesta este cazul obișnuit pentru servere, desktopuri și telefoanele actuale și de aceea sfatul de a folosi AES este o valoare implicită rezonabilă într-un centru de date.

Problema este cazul de ordinul al doilea. Fără instrucțiuni dedicate, AES în software este lent, iar implementările software bazate pe tabele sunt cele cu o istorie lungă de probleme de timp de cache. Un concentrator VPN într-o mașină virtuală al cărei gazdă nu expune steagurile AES invitatului este exact acest caz și este ușor de ratat pentru că procesorul gazdei are funcția.

Verifică ce vede de fapt procesul, nu ce suportă procesorul: grep -o aes /proc/cpuinfo | head -1 pe Linux, sau steagul de funcție echivalent din modelul de procesor al hipervizorului.

Unde câștigă ChaCha20-Poly1305

ChaCha20 este rapid în software portabil pentru că folosește doar adunare, rotație și XOR, iar implementările sale evită prin proiectare căutările în tabele dependente de secret. Pe un dispozitiv fără accelerare AES acesta este un avantaj material și este motivul pentru care WireGuard l-a ales: descrierea protocolului WireGuard listează ChaCha20-Poly1305 ca cifru de date fără alternativă.

Acea singură alegere spune ceva util: pe hardware unde AES este accelerat, WireGuard cedează ceva debit față de AES-GCM, iar autorii au acceptat asta în schimbul unui comportament previzibil pe telefoane, routere de acasă și gazde de containere. Dacă flota ta este în mare parte cutii ARM mici, acel schimb este în favoarea ta.

Cazul opus este un concentrator x86 aglomerat, unde AES-GCM cu AES-NI este calea mai rapidă și mai bine susținută, iar ChaCha20 costă procesor măsurabil pe gigabit. Niciuna dintre construcții nu este o slăbiciune; întrebarea este pe care o execută ieftin hardware-ul tău.

Ce te lasă protocolul tău să alegi de fapt

Observă separarea din OpenVPN: canalul de control și canalul de date sunt negociate separat, așa că suita pe care o vezi pentru TLS nu spune nimic despre cifrul care îți protejează datele. Rezumatul sesiunii le raportează pe ambele, iar citirea doar a unuia dintre cele două este o sursă obișnuită de confuzie.

În OpenVPN cifrul canalului de date vine din lista data-ciphers la ambele capete. Dacă lista serverului și lista clientului nu se intersectează, conexiunea fie revine la ce permite data-ciphers-fallback, fie eșuează complet, iar acel eșec este de obicei pus pe seama stratului greșit. Pune aceeași listă pe ambele părți, apoi confirmă rezultatul negociat în jurnal în loc să presupui că ordinea listei a fost respectată.

Decide pe baza a trei fapte despre implementare

În primul rând, punctele terminale au accelerare AES? Dacă fiecare partener are, AES-GCM este alegerea mai ieftină și valoarea implicită în majoritatea configurațiilor întreținute. Dacă o parte semnificativă sunt routere mici sau telefoane vechi, ChaCha20-Poly1305 împiedică coada flotei să devină limita de capacitate.

În al doilea rând, protocolul oferă măcar o alegere? Cu WireGuard decizia este deja luată pentru tine, iar munca utilă este să verifici că uneltele din jur nu înlocuiesc în tăcere altceva. Cu OpenVPN și IPsec răspunsul este o linie de configurare și un rezultat negociat de consemnat.

În al treilea rând, se pot înțelege ambele capete? Un cifru pe care un partener nu îl implementează nu este o decizie de performanță, este o întrerupere. De aceea lista de parteneri contează mai mult decât orice benchmark: o flotă mixtă are nevoie de intersecția capacităților, nu de preferința celei mai rapide mașini.

Dacă măsori, păstrează identice dispozitivul, punctul terminal și sarcina și schimbă un singur lucru. Un test care compară două servere din regiuni diferite măsoară ruta, nu cifrul, iar o măsurătoare pe laptop nu spune nimic despre o gazdă de containere ale cărei steaguri de procesor sunt mascate. Compară, apoi notează ce cifru a fost negociat efectiv: acea consemnare valorează mai mult decât benchmark-ul.