AES-GCM eller ChaCha20-Poly1305: välja datakryptering för VPN

Båda namnen är AEAD-konstruktioner, båda är standardiserade, och på en aktuell x86-server mättar vilken som helst av dem en gigabitlänk utan synlig ansträngning. Valet slutar vara godtyckligt när du lämnar den servern: billiga routrar, äldre telefoner och virtuella enheter saknar ofta AES-acceleration, och där är skillnaden stor. Jämförelsen handlar alltså inte om vilken kryptering som är snabbast, utan om vilken kryptering som fungerar bra på den här uppsättningen ändpunkter, och om protokollet ens erbjuder ett val.

Samma arbete, olika kärnor

Båda konstruktionerna ger konfidentialitet och integritet i en enda passage och autentiserar associerad data, och därför använder VPN-protokoll dem för datakanalen. Skillnaden sitter inuti: AES-GCM är AES-blockchiffret i räknarläge med en polynomisk autentiserare över GF(2^128), medan ChaCha20-Poly1305 är ett strömchiffer med 256-bitars nyckel och en separat engångsautentiserare.

Det som spelar roll operativt är gemensamt: båda misslyckas katastrofalt vid återanvändning av nonce, båda kräver hantering av nonce-utrymmet per nyckel, och ingen av dem reparerar en motpart som autentiserar fel sak. En profil som säger AES-256-GCM är inte säkrare än en som säger CHACHA20-POLY1305; båda är starka när implementeringen är korrekt.

Där AES-GCM vinner

AES har dedikerade instruktioner på de flesta moderna processorer: AES-NI på x86, kryptotilläggen på ARMv8 och motsvarigheter på nyare POWER- och RISC-V-designer. När de finns kör GCM flera block parallellt per cykelklass, och mjukvaruimplementeringen blir irrelevant. Det är det vanliga fallet för servrar, stationära datorer och dagens telefoner, och därför är rådet att använda AES ett rimligt standardval i ett datacenter.

Problemet är andra ordningens fall. Utan dedikerade instruktioner är AES i mjukvara långsamt, och tabellstyrda mjukvaruimplementeringar är de med en lång historia av cache-tajmingsproblem. En VPN-koncentrator i en virtuell maskin vars värd inte exponerar AES-flaggor för gästen är precis detta fall, och det är lätt att missa eftersom värdens processor har funktionen.

Kontrollera vad processen faktiskt ser, inte vad processorn stöder: grep -o aes /proc/cpuinfo | head -1 på Linux, eller motsvarande funktionsflagga i hypervisorns processormodell.

Där ChaCha20-Poly1305 vinner

ChaCha20 är snabbt i portabel mjukvara eftersom det bara använder addition, rotation och XOR, och implementeringarna undviker genom design hemlighetsberoende tabellsökningar. På en enhet utan AES-acceleration är det en materiell fördel, och det är anledningen till att WireGuard valde det: beskrivningen av WireGuard-protokollet listar ChaCha20-Poly1305 som sitt datachiffer utan alternativ.

Det enda valet säger något användbart: på hårdvara där AES accelereras ger WireGuard upp en del genomströmning jämfört med AES-GCM, och författarna har accepterat det i utbyte mot förutsägbart beteende på telefoner, hemmaroutrar och container-värdar. Om din flotta mest består av små ARM-lådor är den affären till din fördel.

Motfallet är en upptagen x86-koncentrator, där AES-GCM med AES-NI är den snabbare och bättre stödda vägen, och där ChaCha20 kostar mätbar processor per gigabit. Ingen av konstruktionerna är en svaghet; frågan är vilken din hårdvara utför billigt.

Vad ditt protokoll faktiskt låter dig välja

Notera delningen i OpenVPN: kontrollkanalen och datakanalen förhandlas separat, så den svit du ser för TLS säger ingenting om chifferet som skyddar din nyttolast. Sessionssammanfattningen rapporterar båda, och att bara läsa en av de två är en vanlig källa till förvirring.

I OpenVPN kommer datakanalens chiffer från listan data-ciphers i båda ändar. Om serverns lista och klientens lista inte överlappar faller anslutningen antingen tillbaka till det data-ciphers-fallback tillåter, eller så misslyckas den helt, och det felet läggs oftast på fel lager. Sätt samma lista på båda sidor och bekräfta sedan det förhandlade resultatet i loggen i stället för att anta att listans ordning respekterades.

Bestäm utifrån tre fakta om driftsättningen

För det första, har ändpunkterna AES-acceleration? Om varje motpart har det är AES-GCM det billigare valet och standarden i de flesta underhållna konfigurationer. Om en betydande andel är små routrar eller äldre telefoner hindrar ChaCha20-Poly1305 att flottans svans blir kapacitetsgränsen.

För det andra, erbjuder protokollet över huvud taget ett val? Med WireGuard är beslutet redan fattat åt dig, och det nyttiga arbetet är att verifiera att verktygen runt omkring inte i tysthet byter ut något annat. Med OpenVPN och IPsec är svaret en konfigurationsrad och ett förhandlat resultat som ska dokumenteras.

För det tredje, kan båda ändar enas? Ett chiffer som en motpart inte implementerar är inte ett prestandabeslut, det är ett avbrott. Därför betyder motpartslistan mer än något benchmark: en blandad flotta behöver snittet av förmågor, inte den snabbaste maskinens preferens.

Om du mäter, håll enhet, ändpunkt och belastning identiska och ändra en sak. Ett test som jämför två servrar i olika regioner mäter vägen, inte chifferet, och en bärbar dators benchmark säger ingenting om en container-värd vars processorflaggor är maskerade. Jämför och skriv sedan ned vilket chiffer som faktiskt förhandlades: den anteckningen är värd mer än benchmarken.