To profiler måles på samme gateway, én med kryptering og én uten, og den krypterte er ikke tregere. Iblant er den raskere, noe som vanligvis utløser en lang diskusjon om testen ble kjørt riktig. Resultatet er plausibelt, fordi kostnaden for en pakke ikke er antall kryptografiske ord i konfigurasjonen. Det er settet med operasjoner som implementasjonen utfører, på maskinvaren den har, over bufferlayoutet den valgte.

Symptomet: det er ikke den krypterte profilen som er treg

Anta at en historisk test sammenligner et AEAD-chiffer med en «ingen kryptering»-modus som fortsatt beregner en egen autentiseringskode per pakke. Den andre profilen skjuler innholdet i nyttelasten, men beholder en hash per pakke, og på en prosessor uten akselerasjon for den hashen kan den koste mer enn den integrerte konstruksjonen den skulle slå.

Etiketten i konfigurasjonen sier «kryptering», og etiketten er alt de fleste sammenligninger ser på. Pakkeveien sier noe annet: én profil utfører en kombinert operasjon som CPU-en har instruksjoner for, og den andre utfører en separat som den ikke har. Å lese konfigurasjonsfilen alene vil aldri avdekke den forskjellen, fordi begge oppføringene ser ut som én linje. Bare den forhandlede modusen og kodeveien bak den forklarer resultatet.

Det er hele forklaringen, og den krever ingen påstand om hvilken primitive som er universelt raskest. Begge kan være raske, begge kan være trege, og rekkefølgen avhenger av maskinen og koden.

Tell operasjoner, ikke etiketter

En AEAD-konstruksjon, som beskrevet i RFC 5116, gir implementasjonen ett enkelt grensesnitt som returnerer chiffertekst og tag sammen. AES-GCM er ett eksempel: tellermodus-kryptering kombinert med en Galois-autentisator. Grensesnittet gjør ikke integritet gratis; det gjør kombinasjonen godt definert, og det er det som lar en implementasjon optimalisere paret som en enhet.

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

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

Dette er skisser av behandlingen, ikke konfigurasjonsråd. Den første har ingen konfidensialitet, men bruker fortsatt CPU på autentisering, og det er nettopp derfor «slå av kryptering» ikke er synonymt med «slå av kryptografisk arbeid».

Den andre kan være billigere fordi prosessorer gir instruksjoner for begge halvdeler: AES-runder og den carry-frie multiplikasjonen Galois-feltet bruker. Biblioteker behandler også uavhengige buffere parallelt, noe som holder instruksjonene opptatt i stedet for å vente på minnet.

Hva den forhandlede modusen faktisk muliggjør

Med Community OpenVPN betyr et AEAD-datachiffer at alternativet auth ikke lenger bidrar med sin egen separate HMAC for datakanalen. Referansen for krypteringsalternativet beskriver dette omfanget, og det er grunnen til at to konfigurasjoner som ser like ut i en tekstfil, kan variere i arbeidet per pakke.

Les den forhandlede modusen i stedet for ønskelisten. En liste over tillatte chiffer og et TLS-suitenavn forteller deg ikke hvilke operasjoner som kjører på nyttelasten, og en gammel cipher-linje beskriver kanskje ikke hva den gjeldende tilkoblingen valgte.

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

Den første kommandoen lister chifferne binæren støtter, som er en kapabilitetsliste og ikke det forhandlede resultatet. Den andre viser hva serveren faktisk ber om. Tilkoblingsloggen er stedet for å bekrefte det endelige valget, fordi en klient kan falle tilbake til noe serveren tillater, men som ingen hadde til hensikt.

Mål arbeidsbelastningen du faktisk kjører

En kryptografisk mikrobørkemåling måler en primitiv under sine egne betingelser. En VPN-overføring kopierer også buffere, planlegger tråder eller avbrudd, sjekker policy og krysser nettverket. Disse delene dominerer ofte, og derfor gir ikke en raskere primitive alltid en raskere tunnel.

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

De to kommandoene gir deg en grov lokal sammenligning av primitivene på maskinen foran deg, og de er ærlige om å være mikrobørkemålinger. De sier ingenting om gjennomstrømningen i tunnelen din, og de bør aldri siteres som det.

Mål deretter arbeidsbelastningen som betyr noe, med alt annet holdt konstant: samme endepunkt, samme pakkestørrelser, samme transport, samme komprimeringspolicy. Hvis profilendringen også endret transporten eller behandlingsstedet, beskriver resultatet den pakken og ikke kryptografien.

Ha også målet i sikte. En datasti med ledig kryptografisk kapasitet kan fortsatt være latensbundet fordi applikasjonen venter på tur-retur-reiser, og gevinster i rå kapasitet fikser ikke en pratsom protokoll. Mål den støttede og policygodkjente konfigurasjonen som helhet, og behandle «færre bokser må være raskere» som den hypotesen det er. Det nyttige spørsmålet er ikke om kryptering koster noe, men om kostnaden vises i målingen du faktisk bryr deg om.

Relaterte artikler