Waarom ’n geënkripteerde VPN-pakket goedkoper kan wees as wat jy dink

Twee profiele word op dieselfde netwerkpoort getoets, een met enkripsie en een sonder, en die geënkripteerde een is nie stadiger nie. Somtyds is dit vinniger, wat gewoonlik ’n lang argument ontketen oor of die toets korrek uitgevoer is. Die resultaat is aanneemlik, want die koste van ’n pakket is nie die aantal kriptografiese woorde in die konfigurasie nie. Dit is die stel bewerkings wat die implementering uitvoer, op die hardeware wat dit het, oor die bufferuitleg wat dit gekies het.

Die simptoom: die geënkripteerde profiel is nie die stadige een nie

Veronderstel ’n historiese toets vergelyk ’n AEAD-syfer met ’n “geen enkripsie”-modus wat steeds ’n aparte verifikasiekode per pakket bereken. Die tweede profiel verberg die inhoud van die vrag maar hou ’n per-pakket-hash, en op ’n verwerker sonder versnelling vir daardie hash kan dit meer kos as die geïntegreerde konstruksie wat dit veronderstel was om te klop.

Die etiket in die konfigurasie sê “enkripsie”, en die etiket is al waarna die meeste vergelykings kyk. Die pakketpad sê iets anders: een profiel voer ’n gekombineerde bewerking uit waarvoor die SVE instruksies het, en die ander een voer ’n aparte bewerking uit waarvoor dit nie het nie. Om net die konfigurasielêer te lees sal nooit daardie verskil openbaar nie, want albei inskrywings lyk soos een reël. Slegs die onderhandelde modus en die kodepad daaronder verduidelik die resultaat.

Dit is die hele verduideliking, en dit vereis geen bewering oor watter primitief universeel vinniger is nie. Albei kan vinnig wees, albei kan stadig wees, en die volgorde hang van die masjien en die kode af.

Tel bewerkings, nie etikette nie

’n AEAD-konstruksie, soos in RFC 5116 beskryf, gee die implementering ’n enkele koppelvlak wat die syferteks en ’n etiket saam teruggee. AES-GCM is een voorbeeld: tellermodus-enkripsie gekombineer met ’n Galois-verifieerder. Die koppelvlak maak integriteit nie gratis nie; dit maak die kombinasie welgedefinieerd, en dit is wat ’n implementering in staat stel om die paar as ’n eenheid te optimaliseer.

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

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

Dit is verwerkingsketse eerder as konfigurasieraad. Die eerste het geen vertroulikheid nie maar spandeer steeds SVE aan verifikasie, en dit is presies waarom “skakel enkripsie af” nie ’n sinoniem vir “skakel kriptografiese werk af” is nie.

Die tweede kan goedkoper wees omdat verwerkers instruksies vir albei helftes verskaf: AES-rondtes en die dra-lose vermenigvuldiging wat die Galois-veld gebruik. Biblioteke verwerk ook onafhanklike buffers parallel, wat daardie instruksies besig hou in plaas daarvan om op geheue te wag.

Wat die onderhandelde modus werklik moontlik maak

Met Community OpenVPN beteken ’n AEAD-datasyfer dat die auth-opsie nie meer ’n eie aparte datakanaal-HMAC bydra nie. Die naslaanblad vir die enkripsie-opsie beskryf daardie omvang, en dit is die rede waarom twee konfigurasies wat in ’n tekslêer eenders lyk, in werk per pakket kan verskil.

Lees die onderhandelde modus eerder as die wenslys. ’n Lys toegelate syfers en ’n TLS-suite-naam sê nie vir jou watter bewerkings op die vrag uitgevoer word nie, en ’n ou cipher-reël beskryf dalk nie wat die huidige verbinding gekies het nie.

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

Die eerste opdrag lys die syfers wat die program ondersteun, wat ’n vermoëlys eerder as die onderhandelde resultaat is. Die tweede wys wat die bediener werklik vra. Die verbindingslog is die plek om die finale keuse te bevestig, want ’n kliënt kan terugval op iets wat die bediener toelaat maar wat niemand bedoel het nie.

Meet die werklading wat jy werklik uitvoer

’n Kriptografiese mikro-maatstaf meet ’n primitief onder sy eie toestande. ’n VPN-oordrag kopieer ook buffers, skeduleer drade of onderbrekings, kontroleer beleid en steek die netwerk oor. Daardie dele oorheers dikwels, en dit is waarom ’n vinniger primitief nie altyd ’n vinniger tonnel lewer nie.

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

Daardie twee opdragte gee jou ’n rowwe plaaslike vergelyking van die primitiewes op die masjien voor jou, en hulle is eerlik daaroor dat hulle mikro-maatstawwe is. Hulle sê niks oor jou tonnel se deurset nie, en hulle moet nooit as sodanig aangehaal word nie.

Meet dan die werklading wat saak maak, met alles anders konstant: dieselfde eindpunt, dieselfde pakketgroottes, dieselfde vervoer, dieselfde kompressiebeleid. As die profielverandering ook die vervoer of die verwerkingsligging verander het, beskryf die resultaat daardie bondel eerder as kriptografie.

Hou ook die doel voor oë. ’n Datapad met oorblywende kriptografiese kapasiteit kan steeds latensie-gebonde wees omdat die toepassing op retoereise wag, en grootmaat-kapasiteitswinste maak nie ’n spraaksame protokol reg nie. Meet die ondersteunde, beleidsgoedgekeurde konfigurasie as ’n geheel, en behandel “minder blokkies moet vinniger wees” as die hipotese wat dit is. Die nuttige vraag is nie of enkripsie iets kos nie, maar of die koste in die meting verskyn waaraan jy werklik omgee.