Wêrom’t in fersifere VPN-pakket minder kostje kin as jo tinke
Noch ien kryptografysk label is net noch ien wurkeenheid. Ferlykje it hiele paad: AEAD-bou, CPU-stipe, buffering en de ûnderhannele datamodus.
Twa profilen wurde metten op deselde gateway, ien mei fersifering en ien sûnder, en de fersifere is net stadiger. Somtiden is it flugger, wat meastentiids in lange diskusje útlokket oer de fraach oft de test wol goed útfierd is. It resultaat is leauweardich, want de kosten fan in pakket is net it oantal kryptografyske wurden yn de konfiguraasje. It is de set operaasjes dy’t de ymplemintaasje útfiert, op de hardware dy’t er hat, oer de buffer-yndieling dy’t er keazen hat.
It symptoom: de fersifere is net de stadige
Stel dat in histoaryske test in AEAD-sifer ferlike mei in „gjin fersifering“-modus dy’t noch altyd in aparte ferifikaasjekoade per pakket berekkent. It twadde profyl ferberget de ynhâld fan ’e lading mar hâldt in hash per pakket, en op in prosessor sûnder fersnelling foar dy hash kin it mear kostje as de yntegrearre konstruksje dy’t it ferslaan moast.
It label yn ’e konfiguraasje seit „fersifering“, en it label is alles dêr’t de measte ferlikingen nei sjogge. It pakketpaad seit wat oars: ien profyl docht in kombinearre operaasje dêr’t de CPU ynstruksjes foar hat, en it oare docht in aparte dêr’t er dy net foar hat. Allinnich it konfiguraasjebestân lêze sil dat ferskil nea sjen litte, want beide ynfieringen lykje op ien rigel. Allinnich de ûnderhannele modus en it koadepaad dêrefter ferklearje it resultaat.
Dat is de hiele ferklearring, en it freget gjin bewearing oer hokker primitive universeel flugger is. Beide kinne fluch wêze, beide kinne stadich wêze, en de oarder hinget fan ’e masine en de koade ôf.
Tel operaasjes, gjin labels
In AEAD-konstruksje, lykas beskreaun yn RFC 5116, jout de ymplemintaasje ien ynterface dy’t de sifertekst en it label tegearre weromjout. AES-GCM is ien foarbyld: fersifering yn tellermodus kombinearre mei in Galois-ferifiearder. De ynterface makket yntegriteit net fergees; it makket de kombinaasje goed definiearre, en dat is wat in ymplemintaasje tastiet it pear as ien ienheid te optimalisearjen.
Separate authentication path: payload -> independent HMAC -> framed packet AEAD path: payload -> authenticated encryption with tag -> framed packet
Dat binne ferwurkingssketsen, gjin konfiguraasje-advys. It earste hat gjin fertroulikheid mar útjout noch altyd CPU oan ferifikaasje, en dêrom is „sifer út“ gjin synonym foar „kryptografysk wurk út“.
It twadde kin goedkeaper wêze om’t prosessors ynstruksjes leverje foar beide helten: AES-rûnen en de carry-leaze fermannichfâldiging dy’t it Galois-fjild brûkt. Bibleteken ferwurkje ek ûnôfhinklike buffers parallel, wat dy ynstruksjes beset hâldt ynstee fan op ûnthâld te wachtsjen.
Wat de ûnderhannele modus eins mooglik makket
By Community OpenVPN betsjut in AEAD-datasifer dat de opsje auth net mear syn eigen aparte HMAC fan it datakanaal leveret. De referinsje foar de fersiferingsopsje beskriuwt dy omfang, en dêrom kinne twa konfiguraasjes dy’t yn in tekstbestân op inoar lykje, ferskille yn wurk per pakket.
Lês de ûnderhannele modus ynstee fan ’e winsklist. In list mei tastiene sifers en in TLS-suitnamme fertelle jo net hokker operaasjes op ’e lading rinne, en in âlde cipher-rigel beskriuwt miskien net wat de hjoeddeiske ferbining keazen hat.
openvpn --show-ciphers | head -20 sudo grep -E 'cipher|auth' /etc/openvpn/server.conf
It earste kommando listet de sifers op dy’t it binêre bestân stipet, wat in kapasiteitslist is en net it ûnderhannele resultaat. It twadde lit sjen wat de tsjinner eins freget. It ferbiningsoersjoch is it plak om de definitive kar te befêstigjen, want in klant kin weromfalle op eat dat de tsjinner tastiet mar dat nimmen bedoelde.
Mjit de wurklast dy’t jo eins draaie
In kryptografyske mikromjitting mjit in primitive ûnder syn eigen betingsten. In VPN-oerdracht kopiearret ek buffers, plent triedden of ûnderbrekkingen, kontrolearret belied en giet troch it netwurk. Dy dielen oerhearskje faak, en dêrom jout in fluggere primitive net altyd in fluggere tunnel.
openssl speed -evp aes-256-gcm openssl speed -evp sha1
Dy twa kommando’s jouwe jo in rûge pleatslike ferliking fan ’e primitiven op ’e masine foar jo, en se binne earlik dat it mikromjittingen binne. Se sizze neat oer de trochset fan jo tunnel, en se moatte nea as sadanich oanhelle wurde.
Mjit dan de wurklast dy’t ta docht, mei al it oare konstant: itselde einpunt, deselde pakketgruttes, itselde ferfier, itselde kompresjebelied. As de profylwiziging ek it ferfier of it ferwurkingsplak feroare hat, beskriuwt it resultaat dat bondel en net de kryptografy.
Hâld ek it doel yn ’t each. In datapaad mei frije kryptografyske kapasiteit kin noch hieltyd latinsje-bûn wêze om’t de applikaasje op rûnreizen wachtet, en winst yn bulkkapasiteit reparearret in praterich protokol net. Mjit de stipe en troch belied goedkarde konfiguraasje as gehiel, en behannelje „minder kasten moat flugger wêze“ as de hypoteze dy’t it is. De nijsgjirrige fraach is net oft fersifering wat kostet, mar oft de kosten te sjen binne yn ’e mjitting dêr’t jo echt om jouwe.