AES-GCM vagy ChaCha20-Poly1305: VPN adattitkosítás választása

Mindkét név AEAD-konstrukció, mindkettő szabványosított, és egy mai x86-os szerveren bármelyikük látható erőfeszítés nélkül telíti a gigabites kapcsolatot. A választás akkor válik önkényessé, amikor elhagyja ezt a szervert: az olcsó routerekből, a régebbi telefonokból és a virtuális berendezésekből gyakran hiányzik az AES-gyorsítás, és ott nagy a különbség. A összehasonlítás tehát nem arról szól, melyik titkosítás gyorsabb, hanem hogy melyik fut jól ezen a végpontkészleten, és kínál-e egyáltalán választást a protokoll.

Ugyanaz a munka, más magok

Mindkét konstrukció egy menetben ad bizalmasságot és sértetlenséget, és hitelesíti a kapcsolt adatokat, ezért használják a VPN-protokollok az adatcsatornához. A különbség belül van: az AES-GCM az AES blokk-titkosítás számláló módban, polinomiális hitelesítővel GF(2^128) felett, míg a ChaCha20-Poly1305 256 bites kulcsú folyamtitkosítás külön egyszeri hitelesítővel.

Ami üzemeltetésileg számít, az közös: mindkettő katasztrofálisan meghibásodik a nonce újrafelhasználásakor, mindkettőhöz kulcsonként kezelni kell a nonce teret, és egyik sem javítja azt a partnert, amely a rossz dolgot hitelesíti. Az a profil, amely AES-256-GCM mond, nem biztonságosabb annál, amely CHACHA20-POLY1305 mond; mindkettő erős, ha a megvalósítás helyes.

Ahol az AES-GCM nyer

Az AES-nek a legtöbb modern CPU-n dedikált utasításai vannak: AES-NI x86-on, a kriptográfiai kiterjesztések ARMv8-on és megfelelőik az újabb POWER és RISC-V terveken. Ha ezek jelen vannak, a GCM több blokkot futtat párhuzamosan ciklusosztályonként, és a szoftveres megvalósítás lényegtelenné válik. Ez a szokásos eset a szervereknél, asztali gépeknél és a mai telefonoknál, és ezért ésszerű alapértelmezés az adatközpontban az a tanács, hogy használjunk AES-t.

A probléma a másodrendű eset. Dedikált utasítások nélkül az AES szoftverben lassú, és a táblavezérelt szoftveres megvalósítások azok, amelyeknek hosszú története van a cache-időzítési problémáknak. Az a VPN-koncentrátor, amely olyan virtuális gépben fut, amelynek hosztja nem mutat AES-jelzőket a vendégnek, pontosan ez az eset, és könnyű kihagyni, mert a hoszt CPU-ján megvan a funkció.

Ellenőrizze, mit lát valójában a folyamat, és ne azt, amit a CPU támogat: grep -o aes /proc/cpuinfo | head -1 Linuxon, vagy a megfelelő funkciójelző a hipervizor CPU-modelljében.

Ahol a ChaCha20-Poly1305 nyer

A ChaCha20 gyors hordozható szoftverben, mert csak összeadást, forgatást és XOR-t használ, és megvalósításai tervezésüknél fogva kerülik a titoktól függő táblakeresést. Az AES-gyorsítás nélküli eszközön ez anyagi előny, és ezért választotta a WireGuard: a WireGuard protokoll leírása a ChaCha20-Poly1305-öt adattitkosításaként sorolja fel, alternatíva nélkül.

Ez az egyetlen döntés valami hasznosat mond: olyan hardveren, ahol az AES gyorsított, a WireGuard valamennyi átviteli teljesítményt felad az AES-GCM-hez képest, és szerzői ezt elfogadták a telefonokon, otthoni routereken és konténerhosztokon mutatott kiszámítható viselkedésért cserébe. Ha a flottája főleg kis ARM-dobozokból áll, ez a csere az Ön javára szól.

Az ellenkező eset egy forgalmas x86-os koncentrátor, ahol az AES-NI-vel futó AES-GCM a gyorsabb és jobban támogatott út, és ahol a ChaCha20 mérhető CPU-t költ minden gigabitre. Egyik konstrukció sem gyengeség; a kérdés az, melyiket futtatja olcsón a hardver.

Amit a protokoll valójában választani enged

Figyelje meg az OpenVPN felosztását: a vezérlőcsatorna és az adatcsatorna külön tárgyalódik, tehát a TLS-hez látott csomag semmit sem mond arról a titkosításról, amely a hasznos terhelést védi. A munkamenet-összegzés mindkettőt jelenti, és a kettő közül csak az egyiket olvasni gyakori zavarforrás.

Az OpenVPN-ben az adatcsatorna titkosítása a data-ciphers listából származik mindkét oldalon. Ha a szerver listája és a kliens listája nem metszi egymást, a kapcsolat vagy visszaesik arra, amit a data-ciphers-fallback enged, vagy teljesen meghiúsul, és ezt a hibát általában a rossz rétegen keresik. Állítsa be ugyanazt a listát mindkét oldalon, majd erősítse meg a tárgyalt eredményt a naplóban, ahelyett hogy feltételezné, hogy a lista sorrendjét betartották.

Döntsön a telepítés három ténye alapján

Először, van-e AES-gyorsítás a végpontokon? Ha minden partnernek van, az AES-GCM az olcsóbb választás és az alapértelmezés a legtöbb karbantartott konfigurációban. Ha jelentős részük kis router vagy régebbi telefon, a ChaCha20-Poly1305 megakadályozza, hogy a flotta farka legyen a kapacitáskorlát.

Másodszor, kínál-e egyáltalán választást a protokoll? A WireGuardnál a döntés már megszületett Ön helyett, és a hasznos munka annak ellenőrzése, hogy a körülötte lévő eszközök nem helyettesítenek-e csendben valami mást. Az OpenVPN-nél és az IPsec-nél a válasz egy konfigurációs sor és egy rögzítendő tárgyalt eredmény.

Harmadszor, meg tud-e egyezni a két fél? Az a titkosítás, amelyet az egyik partner nem valósít meg, nem teljesítménydöntés, hanem kiesés. Ezért a partnerek listája fontosabb minden mérésnél: a vegyes flottának a képességek metszetére van szüksége, nem a leggyorsabb gép preferenciájára.

Ha mér, tartsa azonoson az eszközt, a végpontot és a terhelést, és csak egy dolgot változtasson. Az a teszt, amely két különböző régióban lévő szervert hasonlít össze, az útvonalat méri, nem a titkosítást, és egy laptopos mérés semmit sem mond arról a konténerhosztról, amelynek CPU-jelzői maszkoltak. Hasonlítson össze, majd írja le, melyik titkosítást tárgyalták valójában: ez a feljegyzés többet ér a mérésnél.