Kvifor ein kryptert VPN-pakke kan koste mindre enn du trur

To profilar vert målte på same gateway, ein med kryptering og ein utan, og den krypterte er ikkje tregare. Av og til er han snøggare, noko som vanlegvis utløyser ein lang diskusjon om testen vart køyrd rett. Resultatet er truverdig, fordi kostnaden for ein pakke ikkje er talet på kryptografiske ord i konfigurasjonen. Det er settet av operasjonar som implementasjonen utfører, på maskinvara han har, over bufferlayoutet han valde.

Symptomet: det er ikkje den krypterte profilen som er treg

Anta at ein historisk test samanliknar eit AEAD-chiffer med ein «ingen kryptering»-modus som framleis reknar ut ein eigen autentiseringskode per pakke. Den andre profilen skjuler innhaldet i nyttelasta, men held på ein hash per pakke, og på ein prosessor utan akselerasjon for den hashen kan han koste meir enn den integrerte konstruksjonen han skulle slå.

Etiketten i konfigurasjonen seier «kryptering», og etiketten er alt dei fleste samanlikningar ser på. Pakkevegen seier noko anna: éin profil utfører ein kombinert operasjon som CPU-en har instruksjonar for, og den andre utfører ein separat som han ikkje har. Å lese konfigurasjonsfila åleine vil aldri avdekkje den skilnaden, fordi begge oppføringane ser ut som éi linje. Berre den framhandla modusen og kodevegen bak han forklarer resultatet.

Det er heile forklaringa, og ho krev ingen påstand om kva primitiv som er universelt snøggast. Begge kan vere snøgge, begge kan vere trege, og rekkjefølgja avheng av maskina og koden.

Tel operasjonar, ikkje etikettar

Ein AEAD-konstruksjon, som skildra i RFC 5116, gjev implementasjonen eitt enkelt grensesnitt som returnerer chiffertekst og tag saman. AES-GCM er eitt døme: teljemodus-kryptering kombinert med ein Galois-autentikator. Grensesnittet gjer ikkje integritet gratis; det gjer kombinasjonen godt definert, og det er det som lèt ein implementasjon optimalisere paret som ei eining.

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

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

Dette er skisser av handsaminga, ikkje konfigurasjonsråd. Den fyrste har inga konfidensialitet, men brukar likevel CPU på autentisering, og det er nett difor «slå av kryptering» ikkje er synonymt med «slå av kryptografisk arbeid».

Den andre kan vere billegare fordi prosessorar gjev instruksjonar for båe halvdelar: AES-runder og den carry-frie multiplikasjonen Galois-feltet brukar. Bibliotek handsamar òg uavhengige buffer parallelt, noko som held instruksjonane opptekne i staden for å vente på minnet.

Kva den framhandla modusen faktisk gjer mogleg

Med Community OpenVPN tyder eit AEAD-datachiffer at alternativet auth ikkje lenger bidreg med sin eigen separate HMAC for datakanalen. Referansen for krypteringsalternativet skildrar dette omfanget, og det er grunnen til at to konfigurasjonar som ser like ut i ei tekstfil, kan variere i arbeidet per pakke.

Les den framhandla modusen i staden for ynskjelista. Ei liste over tillatne chiffer og eit TLS-suitenamn fortel deg ikkje kva operasjonar som køyrer på nyttelasta, og ei gammal cipher-linje skildrar kanskje ikkje kva den gjeldande tilkoplinga valde.

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

Den fyrste kommandoen listar chiffera binærfila støttar, som er ei kapasitetsliste og ikkje det framhandla resultatet. Den andre viser kva tenaren faktisk ber om. Tilkoplingsloggen er staden for å stadfeste det endelege valet, fordi ein klient kan falle tilbake til noko tenaren tillèt, men som ingen hadde til hensikt.

Mål arbeidslasta du faktisk køyrer

Ei kryptografisk mikrobørkemåling målar ein primitiv under sine eigne vilkår. Ei VPN-overføring kopierer òg buffer, planlegg trådar eller avbrot, sjekkar policy og kryssar netverket. Desse delane dominerer ofte, og difor gjev ikkje ein snøggare primitiv alltid ein snøggare tunnel.

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

Dei to kommandoane gjev deg ei grov lokal samanlikning av primitivane på maskina framfor deg, og dei er ærlege om å vere mikrobørkemålingar. Dei seier ingenting om gjennomstrøyminga i tunnelen din, og dei bør aldri siterast som det.

Mål deretter arbeidslasta som betyr noko, med alt anna halde konstant: same endepunkt, same pakkestorleikar, same transport, same komprimeringspolicy. Viss profilendringa òg endra transporten eller handsamingsstaden, skildrar resultatet den pakken og ikkje kryptografien.

Hald òg målet i sikte. Ein datasti med ledig kryptografisk kapasitet kan framleis vere latensbunden fordi applikasjonen ventar på tur-retur-reiser, og vinstar i rå kapasitet fiksar ikkje ein pratsam protokoll. Mål den støtta og policygodkjende konfigurasjonen som heilskap, og handsam «færre boksar må vere snøggare» som den hypotesen det er. Det nyttige spørsmålet er ikkje om kryptering kostar noko, men om kostnaden syner seg i målinga du faktisk bryr deg om.