AES-GCM alebo ChaCha20-Poly1305: voľba šifry dát pre VPN
AES-GCM je zrejmá voľba na serveroch s hardvérovým zrýchlením a ChaCha20-Poly1305 funguje dobre aj bez neho. Možno rozhodne váš protokol.
Oba názvy sú konštrukcie AEAD, oba sú štandardizované, a na súčasnom serveri x86 každá z nich nasýti gigabitové spojenie bez viditeľnej námahy. Voľba prestáva byť ľubovoľná, keď ten server opustíte: lacné routery, staršie telefóny a virtuálne zariadenia často nemajú hardvérové zrýchlenie AES a tam je rozdiel veľký. Porovnanie teda nie je o tom, ktorá šifra je rýchlejšia, ale o tom, ktorá šifra funguje dobre na tomto súbore koncových bodov a či protokol vôbec ponúka voľbu.
Rovnaká práca, iné jadrá
Obe konštrukcie poskytujú dôvernosť a integritu v jednom prechode a autentizujú pridružené údaje, preto ich protokoly VPN používajú pre dátový kanál. Rozdiel je vnútri: AES-GCM je bloková šifra AES v režime počítadla s polynomickým autentizátorom nad GF(2^128), zatiaľ čo ChaCha20-Poly1305 je prúdová šifra s 256-bitovým kľúčom a samostatným jednorazovým autentizátorom.
To, čo je prevádzkovo dôležité, je spoločné: obe katastrofálne zlyhávajú pri opakovanom použití nonce, obe potrebujú správu priestoru nonce pre každý kľúč a ani jedna neopraví partnera, ktorý autentizuje nesprávnu vec. Profil, ktorý hovorí AES-256-GCM, nie je bezpečnejší ako ten, ktorý hovorí CHACHA20-POLY1305; oba sú silné, keď je implementácia správna.
Kde vyhráva AES-GCM
AES má vyhradené inštrukcie na väčšine moderných procesorov: AES-NI na x86, kryptografické rozšírenia na ARMv8 a ekvivalenty na novších návrhoch POWER a RISC-V. Keď sú prítomné, GCM spracúva niekoľko blokov paralelne na triedu cyklu a softvérová implementácia prestáva byť podstatná. To je bežný prípad serverov, stolných počítačov a súčasných telefónov, a preto je rada používať AES rozumným predvoleným nastavením v dátovom centre.
Problém je prípad druhého rádu. Bez vyhradených inštrukcií je AES v softvéri pomalé a softvérové implementácie riadené tabuľkami majú dlhú históriu problémov s časovaním prístupu do cache. Koncentrátor VPN vo virtuálnom stroji, ktorého hostiteľ neposkytuje hosťovi príznaky AES, je presne tento prípad a ľahko sa prehliadne, pretože procesor hostiteľa tú funkciu má.
Overte, čo proces skutočne vidí, nie čo procesor podporuje: grep -o aes /proc/cpuinfo | head -1 v Linuxe alebo zodpovedajúci príznak funkcie v modeli procesora hypervizora.
Kde vyhráva ChaCha20-Poly1305
ChaCha20 je rýchly v prenosnom softvéri, pretože používa len sčítanie, rotáciu a XOR a jeho implementácie sa zámerne vyhýbajú vyhľadávaniu v tabuľkách závislému od tajomstva. Na zariadení bez zrýchlenia AES je to podstatná výhoda, a preto si ho WireGuard vybral: opis protokolu WireGuard uvádza ChaCha20-Poly1305 ako svoju dátovú šifru bez alternatívy.
Táto jediná voľba hovorí niečo užitočné: na hardvéri, kde je AES zrýchlené, WireGuard oproti AES-GCM časť priepustnosti odovzdá, a jeho autori to prijali výmenou za predvídateľné správanie na telefónoch, domácich routeroch a hostiteľoch kontajnerov. Ak je vaša flotila prevažne malé zariadenia ARM, táto výmena hrá vo váš prospech.
Opačný prípad je vyťažený koncentrátor x86, kde je AES-GCM s AES-NI rýchlejšia a lepšie podporovaná cesta a kde ChaCha20 stojí merateľný procesorový čas na každý gigabit. Ani jedna konštrukcia nie je slabina; otázkou je, ktorú váš hardvér vykonáva lacno.
Čo vám protokol skutočne dovoľuje vybrať
| Protocol | What you get |
|---|---|
| WireGuard | ChaCha20-Poly1305 only; no negotiation |
| OpenVPN 2.5 and later | Data channel negotiated from data-ciphers: AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 |
| IPsec / IKEv2 | AES-GCM as a combined-mode transform, or ChaCha20-Poly1305 where both peers implement it |
| OpenVPN control channel | TLS decides; TLS 1.3 offers AES-GCM and ChaCha20-Poly1305 suites |
Všimnite si rozdelenie v OpenVPN: riadiaci kanál a dátový kanál sa vyjednávajú oddelene, takže zostava, ktorú vidíte pre TLS, nehovorí nič o šifre chrániacej váš obsah. Súhrn relácie hlási oboje a čítanie iba jedného z tých dvoch je častý zdroj zmätku.
V OpenVPN pochádza šifra dátového kanála zo zoznamu data-ciphers na oboch stranách. Ak sa zoznam servera a zoznam klienta nepretínajú, spojenie sa buď vráti k tomu, čo dovoľuje data-ciphers-fallback, alebo úplne zlyhá, a toto zlyhanie sa zvyčajne pripisuje nesprávnej vrstve. Nastavte rovnaký zoznam na oboch stranách a potom potvrďte vyjednaný výsledok v logu, namiesto toho aby ste predpokladali, že poradie zoznamu bolo dodržané.
Rozhodnite podľa troch faktov o nasadení
Po prvé, majú koncové body zrýchlenie AES? Ak ho má každý partner, AES-GCM je lacnejšia voľba a predvolené nastavenie vo väčšine udržiavaných konfigurácií. Ak významný podiel tvoria malé routery alebo staršie telefóny, ChaCha20-Poly1305 bráni tomu, aby sa koniec flotily stal kapacitným limitom.
Po druhé, ponúka protokol vôbec voľbu? Pri WireGuarde je rozhodnutie urobené za vás a užitočná práca je overiť, že nástroje okolo potichu nenahrádzajú niečo iné. Pri OpenVPN a IPsec je odpoveďou riadok konfigurácie a vyjednaný výsledok, ktorý treba zaznamenať.
Po tretie, môžu sa obe strany dohodnúť? Šifra, ktorú jeden partner neimplementuje, nie je rozhodnutie o výkone, je to výpadok. Preto je zoznam partnerov dôležitejší ako akýkoľvek benchmark: zmiešaná flotila potrebuje prienik schopností, nie preferenciu najrýchlejšieho stroja.
Ak meriate, držte zariadenie, koncový bod a záťaž rovnaké a zmeňte jednu vec. Test, ktorý porovnáva dva servery v rôznych regiónoch, meria trasu, nie šifru, a meranie na notebooku nehovorí nič o hostiteľovi kontajnerov, ktorého procesorové príznaky sú maskované. Porovnajte a potom si zapíšte, ktorá šifra bola skutočne vyjednaná: tento záznam má väčšiu cenu ako benchmark.