AES-GCM eller ChaCha20-Poly1305: hvordan velge datakryptering for VPN

Begge navnene er AEAD-konstruksjoner, begge er standardisert, og på en moderne x86-server vil enhver av dem fylle en gigabitforbindelse uten synlig anstrengelse. Valget er ikke lenger tilfeldig når du forlater den serveren: billige rutere, eldre telefoner og virtuelle enheter mangler ofte AES-akselerasjon, og der er forskjellen stor. Sammenligningen handler derfor ikke om hvilken kryptering som er raskest, men om hvilken kryptering som fungerer godt på dette settet med endepunkter, og om protokollen i det hele tatt gir et valg.

Samme jobb, forskjellige kjerner

Begge konstruksjonene gir konfidensialitet og integritet i én passering og autentiserer tilknyttede data, og derfor bruker VPN-protokoller dem for datakanalen. Forskjellen ligger innvendig: AES-GCM er AES-blokkchifferen i tellermodus med en polynomisk autentisering over GF(2^128), mens ChaCha20-Poly1305 er en strømchiffer med 256-bits nøkkel og en separat engangsautentisering.

Det som betyr noe i drift, er felles: begge svikter katastrofalt ved gjenbruk av nonce, begge krever håndtering av nonce-rommet per nøkkel, og ingen av dem reparerer en motpart som autentiserer feil ting. En profil som sier AES-256-GCM er ikke sikrere enn en som sier CHACHA20-POLY1305; begge er sterke når implementasjonen er riktig.

Der AES-GCM vinner

AES har egne instruksjoner på de fleste moderne prosessorer: AES-NI på x86, kryptoutvidelsene på ARMv8 og tilsvarende på nyere POWER- og RISC-V-design. Når de finnes, kjører GCM flere blokker parallelt per syklusklasse, og programvareimplementasjonen er uten betydning. Dette er det vanlige tilfellet for servere, stasjonære datamaskiner og dagens telefoner, og derfor er rådet om å bruke AES en fornuftig standardverdi i et datasenter.

Problemet er andreordens tilfellet. Uten egne instruksjoner er AES i programvare treg, og tabellstyrte programvareimplementasjoner er de med lang historie med cache-tidsproblemer. En VPN-konsentrator i en virtuell maskin der verten ikke viser AES-flagg til gjesten, er nettopp dette tilfellet, og det er lett å overse fordi vertens prosessor har funksjonen.

Sjekk hva prosessen faktisk ser, ikke hva prosessoren støtter: grep -o aes /proc/cpuinfo | head -1 på Linux, eller det tilsvarende funksjonsflagget i hypervisorens prosessormodell.

Der ChaCha20-Poly1305 vinner

ChaCha20 er rask i flyttbar programvare fordi den bare bruker addisjon, rotasjon og XOR, og implementasjonene unngår ved design hemmelighetsavhengige tabelloppslag. På en enhet uten AES-akselerasjon er det en vesentlig fordel, og det er grunnen til at WireGuard valgte den: beskrivelsen av WireGuard-protokollen oppgir ChaCha20-Poly1305 som sin datakryptering uten alternativ.

Det ene valget sier noe nyttig: på maskinvare der AES er akselerert, gir WireGuard fra seg noe gjennomstrømning sammenlignet med AES-GCM, og forfatterne har godtatt det mot forutsigbar oppførsel på telefoner, hjemmerutere og containerverter. Hvis flåten din stort sett er små ARM-bokser, er den byttehandelen i din favør.

Motsatt tilfelle er en travel x86-konsentrator, der AES-GCM med AES-NI er den raskere og bedre støttede veien, og der ChaCha20 koster målbar prosessorkraft per gigabit. Ingen av konstruksjonene er en svakhet; spørsmålet er hvilken maskinvaren din utfører billig.

Hva protokollen din faktisk lar deg velge

Legg merke til delingen i OpenVPN: kontrollkanalen og datakanalen forhandles separat, så settet du ser for TLS sier ingenting om krypteringen som beskytter nyttelasten din. Sesjonssammendraget rapporterer begge, og å lese bare én av de to er en vanlig kilde til forvirring.

I OpenVPN kommer krypteringen for datakanalen fra data-ciphers-listen i begge ender. Hvis serverens liste og klientens liste ikke overlapper, faller forbindelsen enten tilbake til det data-ciphers-fallback tillater, eller den feiler helt, og den feilen blir vanligvis lagt på feil lag. Sett den samme listen på begge sider, og bekreft deretter det forhandlede resultatet i loggen i stedet for å anta at rekkefølgen i listen ble respektert.

Bestem ut fra tre fakta om utrullingen

For det første, har endepunktene AES-akselerasjon? Hvis hver motpart har det, er AES-GCM det billigere valget og standarden i de fleste vedlikeholdte konfigurasjoner. Hvis en betydelig andel er små rutere eller eldre telefoner, hindrer ChaCha20-Poly1305 at halen av flåten blir kapasitetsgrensen.

For det andre, gir protokollen i det hele tatt et valg? Med WireGuard er beslutningen tatt for deg, og det nyttige arbeidet er å verifisere at verktøyene rundt den ikke i stillhet erstatter noe annet. Med OpenVPN og IPsec er svaret en konfigurasjonslinje og et forhandlet resultat som skal skrives ned.

For det tredje, kan begge ender bli enige? En kryptering som en motpart ikke implementerer, er ikke en ytelsesbeslutning, det er et avbrudd. Derfor betyr motpartlisten mer enn noen referansemåling: en blandet flåte trenger snittet av evner, ikke den raskeste maskinens preferanse.

Hvis du måler, hold enhet, endepunkt og belastning identiske og endre én ting. En test som sammenligner to servere i ulike regioner, måler ruten, ikke krypteringen, og en referansemåling på en bærbar datamaskin sier ingenting om en containervert der prosessorflaggene er maskert. Sammenlign, og skriv deretter ned hvilken kryptering som faktisk ble forhandlet: den registreringen er mer verdt enn referansemålingen.