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

Begge navnene er AEAD-konstruksjoner, begge er standardiserte, og på en nåværende x86-server vil hvilken som helst av dem mette en gigabitlenke uten synlig anstrengelse. Valget slutter å være vilkårlig når du forlater den serveren: billige rutere, eldre telefoner og virtuelle apparater mangler ofte AES-akselerasjon, og der er forskjellen stor. Sammenligningen handler altså ikke om hvilken kryptering som er raskest, men om hvilken kryptering som går bra på dette settet av endepunkter, og om protokollen i det hele tatt tilbyr et valg.

Samme arbeid, forskjellige kjerner

Begge konstruksjonene gir konfidensialitet og integritet i én gjennomgang og autentiserer tilknyttede data, og derfor bruker VPN-protokoller dem for datakanalen. Forskjellen ligger inni: 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 egen engangsautentisering.

Det som betyr noe driftsmessig, er felles: begge feiler katastrofalt ved gjenbruk av nonce, begge trenger styring av nonce-rom 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.

Hvor AES-GCM vinner

AES har dedikerte instruksjoner på de fleste moderne CPU-er: AES-NI på x86, kryptoutvidelsene på ARMv8 og tilsvarende på nyere POWER- og RISC-V-design. Når de er til stede, kjører GCM flere blokker parallelt per syklusklasse, og softwareimplementasjonen er irrelevant. Dette er det vanlige tilfellet for servere, stasjonære maskiner og dagens telefoner, og derfor er rådet om å bruke AES et rimelig standardvalg i et datasenter.

Problemet er andreordens tilfellet. Uten dedikerte instruksjoner er AES i software tregt, og tabelldrevne softwareimplementasjoner er de med en lang historie med cache-timing-problemer. En VPN-konsentrator i en virtuell maskin der verten ikke eksponerer AES-flagg for gjesten, er nettopp dette tilfellet, og det er lett å overse fordi vertens CPU har funksjonen.

Sjekk hva prosessen faktisk ser, ikke hva CPU-en støtter: grep -o aes /proc/cpuinfo | head -1 på Linux, eller det tilsvarende funksjonsflagget i hypervisor-ens CPU-modell.

Hvor ChaCha20-Poly1305 vinner

ChaCha20 er rask i portabel 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 materiell fordel, og det er grunnen til at WireGuard valgte den: WireGuard-protokollbeskrivelsen lister 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 akseptert det mot forutsigbar oppførsel på telefoner, hjemmerutere og container-verter. Hvis flåten din mest er små ARM-bokser, er den handelen i din favør.

Mottilfellet 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 CPU 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å suiten 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 datakanalens kryptering 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, tilbyr 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 det stille erstatter noe annet. Med OpenVPN og IPsec er svaret en konfigurasjonslinje og et forhandlet resultat som skal noteres.

For det tredje, kan begge ender bli enige? En kryptering som en motpart ikke implementerer, er ikke en ytelsesbeslutning, det er et utfall. Derfor betyr motpartlisten mer enn noen benchmark: 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 bærbar-PC-benchmark sier ingenting om en container-vert der CPU-flaggene er maskert. Sammenlign, og skriv deretter ned hvilken kryptering som faktisk ble forhandlet: den registreringen er mer verdt enn benchmarken.