Varför ett krypterat VPN-paket kan kosta mindre än du tror

Två profiler mäts på samma gateway, en med kryptering och en utan, och den krypterade är inte långsammare. Ibland är den snabbare, vilket oftast leder till en lång diskussion om huruvida testet utfördes korrekt. Resultatet är rimligt, eftersom kostnaden för ett paket inte är antalet kryptografiska ord i konfigurationen. Det är mängden operationer som implementationen utför, på den hårdvara den har, över den buffertlayout den valde.

Symtomet: det är inte den krypterade profilen som är långsam

Anta att ett historiskt test jämför ett AEAD-chiffer med ett läge „utan kryptering“ som fortfarande beräknar en separat autentiseringskod per paket. Den andra profilen döljer nyttolastens innehåll men behåller en hash per paket, och på en processor utan acceleration för den hashen kan den kosta mer än den integrerade konstruktion den skulle slå.

Etiketten i konfigurationen säger „kryptering“, och etiketten är allt som de flesta jämförelser tittar på. Paketvägen säger något annat: en profil utför en kombinerad operation som processorn har instruktioner för, och den andra utför en separat som den inte har. Att bara läsa konfigurationsfilen kommer aldrig att avslöja den skillnaden, eftersom båda posterna ser ut som en enda rad. Bara det förhandlade läget och kodvägen bakom det förklarar resultatet.

Det är hela förklaringen, och den kräver inget påstående om vilken primitiv som är universellt snabbast. Båda kan vara snabba, båda kan vara långsamma, och ordningen beror på maskinen och koden.

Räkna operationer, inte etiketter

En AEAD-konstruktion, som beskrivs i RFC 5116, ger implementationen ett enda gränssnitt som returnerar chiffertext och tagg tillsammans. AES-GCM är ett exempel: räknarlägeskryptering kombinerad med en Galois-autentiserare. Gränssnittet gör inte integritet gratis; det gör kombinationen väldefinierad, och det är vad som låter en implementation optimera paret som en enhet.

Separate authentication path:
  payload -> independent HMAC -> framed packet

AEAD path:
  payload -> authenticated encryption with tag -> framed packet

Det här är skisser av behandlingen, inte konfigurationsråd. Den första har ingen konfidentialitet men använder ändå CPU för autentisering, och det är just därför „stäng av kryptering“ inte är synonymt med „stäng av kryptografiskt arbete“.

Den andra kan vara billigare eftersom processorer ger instruktioner för båda halvorna: AES-rundor och den carry-fria multiplikation som Galois-fältet använder. Bibliotek behandlar också oberoende buffertar parallellt, vilket håller de instruktionerna upptagna i stället för att vänta på minnet.

Vad det förhandlade läget faktiskt möjliggör

Med Community OpenVPN innebär ett AEAD-datachiffer att alternativet auth inte längre bidrar med sin egen separata HMAC för datakanalen. Referensen för krypteringsalternativet beskriver den omfattningen, och det är anledningen till att två konfigurationer som ser likadana ut i en textfil kan skilja sig i arbetet per paket.

Läs det förhandlade läget i stället för önskelistan. En lista över tillåtna chiffer och ett TLS-svitnamn säger inte vilka operationer som körs på nyttolasten, och en gammal cipher-rad beskriver kanske inte vad den aktuella anslutningen valde.

openvpn --show-ciphers | head -20
sudo grep -E 'cipher|auth' /etc/openvpn/server.conf

Det första kommandot listar de chiffer som binären stöder, vilket är en kapabilitetslista och inte det förhandlade resultatet. Det andra visar vad servern faktiskt begär. Anslutningsloggen är platsen för att bekräfta det slutliga valet, eftersom en klient kan falla tillbaka på något som servern tillåter men som ingen avsåg.

Mät den arbetsbelastning du faktiskt kör

Ett kryptografiskt mikrobänkmärke mäter en primitiv under dess egna förhållanden. En VPN-överföring kopierar också buffertar, schemalägger trådar eller avbrott, kontrollerar policy och korsar nätverket. Dessa delar dominerar ofta, och därför ger en snabbare primitiv inte alltid en snabbare tunnel.

openssl speed -evp aes-256-gcm
openssl speed -evp sha1

De två kommandona ger dig en grov lokal jämförelse av primitiverna på maskinen framför dig, och de är ärliga med att vara mikrobänkmärken. De säger ingenting om genomströmningen i din tunnel, och de bör aldrig citeras som sådan.

Mät sedan den arbetsbelastning som spelar roll, med allt annat konstant: samma slutpunkt, samma paketstorlekar, samma transport, samma komprimeringspolicy. Om profiländringen också ändrade transporten eller bearbetningsplatsen, beskriver resultatet det paketet och inte kryptografin.

Håll också målet i sikte. En dataväg med ledig kryptografisk kapacitet kan fortfarande vara latensbunden eftersom applikationen väntar på tur- och returresor, och vinster i rå kapacitet löser inte ett pratsamt protokoll. Mät den stödda och policygodkända konfigurationen som helhet, och behandla „färre lådor måste vara snabbare“ som den hypotes den är. Den användbara frågan är inte om kryptering kostar något, utan om kostnaden syns i den mätning du faktiskt bryr dig om.