AES-GCM of ChaCha20-Poly1305: de datacodering van een VPN kiezen

Beide namen zijn AEAD-constructies, beide zijn gestandaardiseerd, en op een huidige x86-server zal elk van beide een gigabitverbinding verzadigen zonder zichtbare inspanning. De keuze wordt pas willekeurig als je die server verlaat: goedkope routers, oudere telefoons en virtuele apparaten hebben vaak geen AES-versnelling, en daar is het verschil groot. De vergelijking gaat dus niet over welke codering sneller is, maar over welke codering goed draait op deze set eindpunten, en of het protocol überhaupt een keuze biedt.

Hetzelfde werk, andere kernen

Beide constructies geven vertrouwelijkheid en integriteit in één doorgang en authenticeren bijbehorende gegevens, daarom gebruiken VPN-protocollen ze voor het datakanaal. Het verschil zit binnenin: AES-GCM is de AES-blokcodering in tellermodus met een polynomische authenticator over GF(2^128), terwijl ChaCha20-Poly1305 een stroomcodering is met een sleutel van 256 bit en een aparte eenmalige authenticator.

Wat operationeel belangrijk is, is gemeenschappelijk: beide falen catastrofaal bij hergebruik van nonce, beide hebben beheer van de nonce-ruimte per sleutel nodig, en geen van beide repareert een peer die het verkeerde authenticeert. Een profiel dat AES-256-GCM zegt is niet veiliger dan een dat CHACHA20-POLY1305 zegt; beide zijn sterk wanneer de implementatie correct is.

Waar AES-GCM wint

AES heeft speciale instructies op de meeste moderne CPU s: AES-NI op x86, de crypto-uitbreidingen op ARMv8 en equivalenten op recente POWER- en RISC-V-ontwerpen. Als die aanwezig zijn, draait GCM meerdere blokken parallel per cyclusklasse en is de software-implementatie irrelevant. Dat is het gebruikelijke geval voor servers, desktops en huidige telefoons, en daarom is het advies om AES te gebruiken een redelijke standaardwaarde in een datacenter.

Het probleem is het geval van de tweede orde. Zonder speciale instructies is AES in software traag, en tabelgestuurde software-implementaties zijn degene met een lange geschiedenis van cache-timingproblemen. Een VPN-concentrator in een virtuele machine waarvan de host geen AES-vlaggen aan de gast toont is precies dit geval, en het is makkelijk te missen omdat de CPU van de host de functie heeft.

Controleer wat het proces werkelijk ziet, niet wat de CPU ondersteunt: grep -o aes /proc/cpuinfo | head -1 op Linux, of de equivalente functievlag in het CPU-model van de hypervisor.

Waar ChaCha20-Poly1305 wint

ChaCha20 is snel in draagbare software omdat het alleen optelling, rotatie en XOR gebruikt, en de implementaties vermijden door ontwerp geheimafhankelijke tabelopzoekingen. Op een apparaat zonder AES-versnelling is dat een materieel voordeel, en dat is de reden dat WireGuard het koos: de beschrijving van het WireGuard-protocol noemt ChaCha20-Poly1305 als zijn datacodering zonder alternatief.

Die ene keuze zegt iets nuttigs: op hardware waar AES versneld is, levert WireGuard wat doorvoer in ten opzichte van AES-GCM, en de auteurs hebben dat geaccepteerd in ruil voor voorspelbaar gedrag op telefoons, thuisrouters en containerhosts. Als je vloot vooral kleine ARM-dozen is, valt die ruil in je voordeel uit.

Het tegengeval is een drukke x86-concentrator, waar AES-GCM met AES-NI de snellere en beter ondersteunde route is, en waar ChaCha20 meetbare CPU per gigabit kost. Geen van beide constructies is een zwakte; de vraag is welke jouw hardware goedkoop uitvoert.

Wat je protocol je echt laat kiezen

Let op de splitsing in OpenVPN: het controle- en het datakanaal worden apart onderhandeld, dus de suite die je voor TLS ziet zegt niets over de codering die je payload beschermt. De sessiesamenvatting meldt beide, en slechts één van de twee lezen is een veelvoorkomende bron van verwarring.

In OpenVPN komt de codering van het datakanaal uit de lijst data-ciphers aan beide kanten. Als de lijst van de server en die van de client elkaar niet overlappen, valt de verbinding terug op wat data-ciphers-fallback toestaat of mislukt ze helemaal, en die fout wordt meestal aan de verkeerde laag verweten. Zet dezelfde lijst aan beide kanten, en bevestig daarna het onderhandelde resultaat in het log in plaats van aan te nemen dat de volgorde van de lijst is gerespecteerd.

Beslis op basis van drie feiten over de uitrol

Ten eerste, hebben de eindpunten AES-versnelling? Als elke peer die heeft, is AES-GCM de goedkopere keuze en de standaard in de meeste onderhouden configuraties. Als een betekenisvol deel kleine routers of oudere telefoons is, houdt ChaCha20-Poly1305 de staart van de vloot tegen om de capaciteitslimiet te worden.

Ten tweede, biedt het protocol überhaupt een keuze? Bij WireGuard is de beslissing voor je genomen, en het nuttige werk is verifiëren dat de gereedschappen eromheen niet stil iets anders vervangen. Bij OpenVPN en IPsec is het antwoord een configuratieregel en een vast te leggen onderhandeld resultaat.

Ten derde, kunnen beide kanten het eens worden? Een codering die een peer niet implementeert is geen prestatiebeslissing, het is een storing. Daarom is de peerlijst belangrijker dan welke benchmark dan ook: een gemengde vloot heeft de doorsnede van mogelijkheden nodig, niet de voorkeur van de snelste machine.

Als je meet, houd dan het apparaat, het eindpunt en de belasting identiek en verander één ding. Een test die twee servers in verschillende regio s vergelijkt meet de route, niet de codering, en een benchmark op een laptop zegt niets over een containerhost waarvan de CPU-vlaggen zijn gemaskeerd. Vergelijk, en schrijf daarna op welke codering werkelijk is onderhandeld: die registratie is meer waard dan de benchmark.