AES-GCM eller ChaCha20-Poly1305: vælg datakryptering til VPN

Begge navne er AEAD-konstruktioner, begge er standardiserede, og på en nuværende x86-server vil enhver af dem mætte et gigabit-link uden synlig anstrengelse. Valget holder op med at være vilkårligt, når du forlader den server: billige routere, ældre telefoner og virtuelle apparater mangler ofte AES-acceleration, og der er forskellen stor. Sammenligningen handler altså ikke om, hvilken kryptering der er hurtigst, men hvilken kryptering der kører godt på dette sæt af endpoints, og om protokollen overhovedet tilbyder et valg.

Samme arbejde, forskellige kerner

Begge konstruktioner giver fortrolighed og integritet i én gennemløb og autentificerer tilknyttede data, og derfor bruger VPN-protokoller dem til datakanalen. Forskellen ligger indeni: AES-GCM er AES-blokkrypteringen i tællemode med en polynomisk autentificering over GF(2^128), mens ChaCha20-Poly1305 er en strømkryptering med 256-bit nøgle og en separat engangsautentificering.

Det, der betyder noget driftsmæssigt, er fælles: begge fejler katastrofalt ved genbrug af nonce, begge kræver styring af nonce-plads per nøgle, og ingen af dem reparerer en modpart, der autentificerer det forkerte. En profil, der siger AES-256-GCM, er ikke sikrere end en, der siger CHACHA20-POLY1305; begge er stærke, når implementeringen er korrekt.

Hvor AES-GCM vinder

AES har dedikerede instruktioner på de fleste moderne CPU'er: AES-NI på x86, kryptoudvidelserne på ARMv8 og tilsvarende på nyere POWER- og RISC-V-designs. Når de er til stede, kører GCM flere blokke parallelt per cyklusklasse, og softwareimplementeringen er irrelevant. Det er det almindelige tilfælde for servere, stationære computere og nuværende telefoner, og derfor er rådet om at bruge AES et rimeligt standardvalg i et datacenter.

Problemet er andenordens tilfældet. Uden dedikerede instruktioner er AES i software langsom, og tabeldrevne softwareimplementeringer er dem med en lang historie af cache-timing-problemer. En VPN-koncentrator i en virtuel maskine, hvis vært ikke eksponerer AES-flag for gæsten, er netop dette tilfælde, og det er let at overse, fordi værtens CPU har funktionen.

Kontroller, hvad processen faktisk ser, og ikke hvad CPU'en understøtter: grep -o aes /proc/cpuinfo | head -1 på Linux, eller det tilsvarende funktionsflag i hypervisor'ens CPU-model.

Hvor ChaCha20-Poly1305 vinder

ChaCha20 er hurtig i portabel software, fordi den kun bruger addition, rotation og XOR, og dens implementeringer undgår efter design hemmelighedsafhængige tabelopslag. På en enhed uden AES-acceleration er det en materiel fordel, og det er grunden til, at WireGuard valgte den: WireGuard-protokolbeskrivelsen angiver ChaCha20-Poly1305 som sin datakryptering uden alternativ.

Det ene valg fortæller noget nyttigt: på hardware, hvor AES er accelereret, giver WireGuard afkald på noget gennemstrømning sammenlignet med AES-GCM, og forfatterne har accepteret det til gengæld for forudsigelig adfærd på telefoner, hjemmeroutere og container-værter. Hvis din flåde mest er små ARM-bokse, er den handel til din fordel.

Modtilfældet er en travl x86-koncentrator, hvor AES-GCM med AES-NI er den hurtigere og bedre understøttede vej, og hvor ChaCha20 koster målbar CPU per gigabit. Ingen af konstruktionerne er en svaghed; spørgsmålet er, hvilken din hardware udfører billigt.

Hvad din protokol faktisk lader dig vælge

Bemærk opdelingen i OpenVPN: kontrolkanalen og datakanalen forhandles separat, så den suite, du ser for TLS, siger intet om den kryptering, der beskytter din last. Sessionsoversigten rapporterer begge, og at læse kun én af de to er en almindelig kilde til forvirring.

I OpenVPN kommer datakanalens kryptering fra data-ciphers-listen i begge ender. Hvis serverens liste og klientens liste ikke overlapper, falder forbindelsen enten tilbage til det, data-ciphers-fallback tillader, eller fejler helt, og den fejl bliver normalt bebrejdet det forkerte lag. Sæt den samme liste i begge sider, og bekræft derefter det forhandlede resultat i loggen i stedet for at antage, at listens rækkefølge blev respekteret.

Beslut ud fra tre fakta om udrulningen

For det første, har endpointene AES-acceleration? Hvis hver modpart har det, er AES-GCM det billigere valg og standarden i de fleste vedligeholdte konfigurationer. Hvis en betydelig andel er små routere eller ældre telefoner, forhindrer ChaCha20-Poly1305, at flådens hale bliver kapacitetsgrænsen.

For det andet, tilbyder protokollen overhovedet et valg? Med WireGuard er beslutningen taget for dig, og det nyttige arbejde er at verificere, at værktøjerne omkring den ikke i det stille erstatter noget andet. Med OpenVPN og IPsec er svaret en konfigurationslinje og et forhandlet resultat, der skal noteres.

For det tredje, kan begge ender blive enige? En kryptering, som en modpart ikke implementerer, er ikke en ydeevnebeslutning, det er et udfald. Derfor betyder modpartlisten mere end nogen benchmark: en blandet flåde har brug for snitfladen af evner, ikke den hurtigste maskines præference.

Hvis du måler, så hold enhed, endpoint og belastning identiske og ændr én ting. En test, der sammenligner to servere i forskellige regioner, måler ruten, ikke krypteringen, og en bærbar benchmark siger intet om en container-vært, hvis CPU-flag er maskeret. Sammenlign, og skriv derefter ned, hvilken kryptering der faktisk blev forhandlet: den registrering er mere værd end benchmarken.