AES-GCM ali ChaCha20-Poly1305: izbira šifre podatkov za VPN
AES-GCM je očitna izbira na strežnikih s strojno pospešitvijo, ChaCha20-Poly1305 pa deluje dobro tudi brez nje. Morda bo vaš protokol odločil namesto vas.
Obe imeni sta zgradbi AEAD, obe sta standardizirani, in na sodobnem strežniku x86 bo vsaka od njiju napolnila gigabitno povezavo brez vidnega napora. Izbira preneha biti samovoljna, ko zapustite ta strežnik: poceni usmerjevalniki, starejši telefoni in navidezna naprava pogosto nimajo pospešitve AES, in tam je razlika velika. Primerjava torej ni, katera šifra je hitrejša, ampak katera šifra deluje dobro na tem naboru končnih točk in ali protokol sploh ponuja izbiro.
Isto delo, druga jedra
Obe zgradbi dajeta zaupnost in celovitost v enem prehodu ter overjata povezane podatke, zato ju protokoli VPN uporabljajo za podatkovni kanal. Razlika je znotraj: AES-GCM je bločna šifra AES v načinu števca s polinomskim overiteljem nad GF(2^128), medtem ko je ChaCha20-Poly1305 pretočna šifra s 256-bitnim ključem in ločenim enkratnim overiteljem.
Kar je operativno pomembno, je skupno: obe katastrofalno odpovedo pri ponovni uporabi nonce, obe potrebujeta upravljanje prostora nonce za vsak ključ in nobena ne popravi partnerja, ki overja napačno stvar. Profil, ki pravi AES-256-GCM, ni varnejši od tistega, ki pravi CHACHA20-POLY1305; oba sta močna, ko je izvedba pravilna.
Kjer zmaga AES-GCM
AES ima namenske ukaze na večini sodobnih procesorjev: AES-NI na x86, kriptografske razširitve na ARMv8 in ustreznike na novejših zasnovah POWER in RISC-V. Ko so prisotni, GCM izvaja več blokov vzporedno na razred cikla in programska izvedba postane nepomembna. To je običajen primer za strežnike, namizne računalnike in sedanje telefone, zato je nasvet, naj se uporablja AES, razumna privzeta vrednost v podatkovnem središču.
Težava je primer drugega reda. Brez namenskih ukazov je AES v programski opremi počasen, programske izvedbe, ki jih vodijo tabele, pa imajo dolgo zgodovino težav s časom dostopa do predpomnilnika. Koncentrator VPN v navidezni napravi, katere gostitelj gostu ne izpostavi zastavic AES, je natanko ta primer, in ga je lahko spregledati, ker ima procesor gostitelja to funkcijo.
Preverite, kaj proces dejansko vidi, ne kaj procesor podpira: grep -o aes /proc/cpuinfo | head -1 v Linuxu ali ustrezno zastavico funkcije v modelu procesorja hipervizorja.
Kjer zmaga ChaCha20-Poly1305
ChaCha20 je hiter v prenosni programski opremi, ker uporablja le seštevanje, vrtenje in XOR, njegove izvedbe pa se po zasnovi izogibajo iskanju po tabelah, odvisnemu od skrivnosti. Na napravi brez pospešitve AES je to bistvena prednost, in zato ga je WireGuard izbral: opis protokola WireGuard navaja ChaCha20-Poly1305 kot svojo podatkovno šifro brez alternative.
Ta ena izbira pove nekaj koristnega: na strojni opremi, kjer je AES pospešen, WireGuard odstopi del prepustnosti v primerjavi z AES-GCM, avtorji pa so to sprejeli v zameno za predvidljivo vedenje na telefonih, domačih usmerjevalnikih in gostiteljih vsebnikov. Če je vaša flota večinoma majhne škatle ARM, je ta menjava v vašo korist.
Nasprotni primer je zaseden koncentrator x86, kjer je AES-GCM z AES-NI hitrejša in bolje podprta pot, ChaCha20 pa stane merljiv procesor na gigabit. Nobena zgradba ni slabost; vprašanje je, katero vaša strojna oprema izvaja poceni.
Kaj vam protokol dejansko dovoli izbrati
| Protocol | What you get |
|---|---|
| WireGuard | ChaCha20-Poly1305 only; no negotiation |
| OpenVPN 2.5 and later | Data channel negotiated from data-ciphers: AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 |
| IPsec / IKEv2 | AES-GCM as a combined-mode transform, or ChaCha20-Poly1305 where both peers implement it |
| OpenVPN control channel | TLS decides; TLS 1.3 offers AES-GCM and ChaCha20-Poly1305 suites |
Bodite pozorni na delitev v OpenVPN: krmilni kanal in podatkovni kanal se pogajata ločeno, zato nabor, ki ga vidite za TLS, ne pove ničesar o šifri, ki ščiti vaš tovor. Povzetek seje poroča o obeh, branje le enega od dveh pa je pogost vir zmede.
V OpenVPN šifra podatkovnega kanala prihaja s seznama data-ciphers na obeh straneh. Če se seznam strežnika in seznam odjemalca ne sekata, se povezava bodisi vrne na tisto, kar dovoljuje data-ciphers-fallback, bodisi popolnoma odpove, in ta neuspeh se običajno pripiše napačnemu sloju. Nastavite isti seznam na obeh straneh in nato potrdite pogajani izid v dnevniku, namesto da bi predpostavljali, da je bil vrstni red seznama upoštevan.
Odločite se na podlagi treh dejstev o uvedbi
Prvič, ali imajo končne točke pospešitev AES? Če jo ima vsak partner, je AES-GCM cenejša izbira in privzeta v večini vzdrževanih konfiguracij. Če je pomemben delež majhnih usmerjevalnikov ali starejših telefonov, ChaCha20-Poly1305 prepreči, da bi rep flote postal meja zmogljivosti.
Drugič, ali protokol sploh ponuja izbiro? Pri WireGuardu je odločitev sprejeta namesto vas, koristno delo pa je preveriti, da orodja okoli njega tiho ne nadomeščajo nečesa drugega. Pri OpenVPN in IPsec je odgovor vrstica konfiguracije in pogajani izid, ki ga je treba zabeležiti.
Tretjič, ali se lahko obe strani dogovorita? Šifra, ki je en partner ne izvaja, ni odločitev o zmogljivosti, ampak prekinitev. Zato je seznam partnerjev pomembnejši od vsakega merila: mešana flota potrebuje presek zmožnosti, ne prednost najhitrejšega stroja.
Če merite, ohranite napravo, končno točko in obremenitev enake ter spremenite eno stvar. Preizkus, ki primerja dva strežnika v različnih regijah, meri pot, ne šifre, meritev na prenosniku pa ne pove ničesar o gostitelju vsebnikov, katerega procesorske zastavice so prikrite. Primerjajte in nato zapišite, katera šifra je bila dejansko pogajana: ta zapis je vreden več kot meritev.