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

Begge namna er AEAD-konstruksjonar, begge er standardiserte, og på ein vanleg x86-tenar vil kvar av dei mette ei gigabitlinje utan synleg strev. Valet sluttar å vere vilkårleg når du forlèt tenaren: rimelege rutarar, eldre telefonar og virtuelle apparat manglar ofte AES-akselerasjon, og der er skilnaden stor. Samanlikninga handlar altså ikkje om kva kryptering som er snøggast, men om kva kryptering som går bra på dette settet av endepunkt, og om protokollen i det heile gjev eit val.

Same arbeid, ulike kjernar

Begge konstruksjonane gjev konfidensialitet og integritet i ein gjennomgang og autentiserer tilknytte data, og difor nyttar VPN-protokollar dei for datakanalen. Skilnaden ligg inni: AES-GCM er AES-blokkkrypteringa i teljemodus med ein polynomisk autentisator over GF(2^128), medan ChaCha20-Poly1305 er ei straumkryptering med 256-bits nøkkel og ein eigen eingongsautentisator.

Det som tel driftsmessig, er felles: begge feilar katastrofalt ved gjenbruk av nonce, begge treng styring av nonce-romet per nøkkel, og ingen av dei reparerer ein motpart som autentiserer feil ting. Ein profil som seier AES-256-GCM er ikkje tryggare enn ein som seier CHACHA20-POLY1305; begge er sterke når implementasjonen er rett.

Kvar AES-GCM vinn

AES har serskilde instruksjonar på dei fleste moderne CPU-ar: AES-NI på x86, kryptoutvidingane på ARMv8 og tilsvarande på nyare POWER- og RISC-V-design. Når dei er til stades, køyrer GCM fleire blokker parallelt per syklusklasse, og programvareimplementasjonen er utan tyding. Dette er det vanlege tilfellet for tenarar, stasjonære maskinar og dagens telefonar, og difor er rådet om å bruke AES eit rimeleg standardval i eit datasenter.

Problemet er andreordens tilfellet. Utan serskilde instruksjonar er AES i programvare treg, og tabelldrivne programvareimplementasjonar er dei med lang historie med cache-timing-problem. Ein VPN-konsentrator i ein virtuell maskin der verten ikkje syner AES-flagg til gjesten, er nett dette tilfellet, og det er lett å oversjå fordi CPU-en til verten har funksjonen.

Sjekk kva prosessen faktisk ser, ikkje kva CPU-en støttar: grep -o aes /proc/cpuinfo | head -1 på Linux, eller det tilsvarande funksjonsflagget i CPU-modellen til hypervisoren.

Kvar ChaCha20-Poly1305 vinn

ChaCha20 er snøgg i flyttbar programvare fordi han berre nyttar addisjon, rotasjon og XOR, og implementasjonane unngår ved design hemmelegheitsavhengige tabelloppslag. På ein eining utan AES-akselerasjon er det ein monaleg føremon, og det er grunnen til at WireGuard valde han: skildringa av WireGuard-protokollen listar ChaCha20-Poly1305 som datakrypteringa si utan alternativ.

Det eine valet seier noko nyttig: på maskinvare der AES er akselerert, gjev WireGuard frå seg noko gjennomstrøyming samanlikna med AES-GCM, og forfattarane har godteke det mot føreseieleg åtferd på telefonar, heimerutarar og containervertar. Om flåten din mest er små ARM-boksar, er den handelen i din favør.

Motstykket er ein travel x86-konsentrator, der AES-GCM med AES-NI er den snøggare og betre støtta vegen, og der ChaCha20 kostar målbar CPU per gigabit. Ingen av konstruksjonane er ei veikskap; spørsmålet er kva maskinvaren din utfører billeg.

Kva protokollen din faktisk lèt deg velje

Legg merke til delinga i OpenVPN: kontrollkanalen og datakanalen vert forhandla kvar for seg, så suiten du ser for TLS seier ingenting om krypteringa som vernar nyttelasta di. Sesjonssamandraget melder om båe, og å lese berre ein av dei to er ei vanleg kjelde til forvirring.

I OpenVPN kjem krypteringa av datakanalen frå data-ciphers-lista i båe endar. Om lista til tenaren og lista til klienten ikkje overlappar, fell sambandet anten tilbake til det data-ciphers-fallback lèt til, eller det feilar heilt, og den feilen vert vanlegvis lagd på feil lag. Set same lista på båe sider, og stadfest deretter det forhandla resultatet i loggen i staden for å gå ut frå at rekkjefylgja i lista vart respektert.

Avgjer ut frå tre faktum om utrullinga

Fyrst, har endepunkta AES-akselerasjon? Om kvar motpart har det, er AES-GCM det billegare valet og standarden i dei fleste vedlikehaldne konfigurasjonane. Om ein monaleg del er små rutarar eller eldre telefonar, hindrar ChaCha20-Poly1305 at halen av flåten vert kapasitetsgrensa.

For det andre, gjev protokollen i det heile eit val? Med WireGuard er avgjerda teken for deg, og det nyttige arbeidet er å stadfeste at verktya rundt ikkje i det stille byter ut noko anna. Med OpenVPN og IPsec er svaret ei konfigurasjonslinje og eit forhandla resultat som skal skrivast ned.

For det tredje, kan båe endar bli samde? Ei kryptering som ein motpart ikkje implementerer, er ikkje ei avgjerd om yting, det er eit brot. Difor tel motpartlista meir enn nokon benchmark: ein blanda flåte treng snittet av evner, ikkje preferansen til den snøggaste maskina.

Om du måler, hald eining, endepunkt og last identiske og endre éin ting. Ein test som samanliknar to tenarar i ulike regionar, måler ruta, ikkje krypteringa, og ein benchmark på ein berbar PC seier ingenting om ein containervert der CPU-flaggja er maskerte. Samanlikn, og skriv deretter ned kva kryptering som faktisk vart forhandla: den registreringa er meir verd enn benchmarken.