AES-GCM of ChaCha20-Poly1305: de datasifers fan in VPN kieze
AES-GCM is de foar de hân lizzende kar op servers mei hardwarefersnelling, en ChaCha20-Poly1305 is dy’t sûnder goed docht. Miskien beslút dyn protokol foar dy.
Beide nammen binne AEAD-konstruksjes, beide binne standerdisearre, en op in hjoeddeiske x86-server sil elk fan beide in gigabitferbining fol meitsje sûnder sichtbere ynspanning. De kar hâldt op willekeurich te wêzen as jo dy server ferlitte: guodkeape routers, âldere tillefoans en firtuele apparaten hawwe faak gjin AES-fersnelling, en dêr is it ferskil grut. De ferliking giet dus net oer hokker sifer flugger is, mar oer hokker sifer op dizze set einpunten goed rint en oft it protokol oeral in kar biedt.
Itselde wurk, oare kearnen
Beide konstruksjes jouwe fertroulikheid en yntegriteit yn ien gong en autentisearje byhearrende gegevens, dêrom brûke VPN-protokollen se foar it gegevenskanaal. It ferskil sit fan binnen: AES-GCM is de AES-bloksifer yn tellermodus mei in polynomiale autentisearring oer GF(2^128), wylst ChaCha20-Poly1305 in streamfersifering is mei in 256-bit kaai en in aparte ienmalige autentisearring.
Wat operasjoneel wichtich is, is mienskiplik: beide mislearje katastrofaal by wergebrûk fan nonce, beide hawwe behear fan nonce-romte per kaai nedich, en gjinien reparearret in partner dy’t ferkearde autentisearret. In profyl dat AES-256-GCM sei, is net feiliger as ien dat CHACHA20-POLY1305 sei; beide binne sterk as de ymplemintaasje korrekt is.
Wêr’t AES-GCM wint
AES hat tawijde ynstruksjes op de measte moderne CPU s: AES-NI op x86, de kryptografyske útwreidings op ARMv8 en ekwivalinten op resinte POWER- en RISC-V-ûntwerpen. As dy der binne, rint GCM ferskate blokken parallel per syklusklasse en is de software-ymplemintaasje net mear fan belang. Dat is it gewoane gefal foar servers, buroblêden en hjoeddeiske tillefoans, en dêrom is it advys om AES te brûken in ridlike standertwearde yn in datacenter.
It probleem is it gefal fan de twadde oarder. Sûnder tawijde ynstruksjes is AES yn software traach, en tabelstjoerde software-ymplemintaasjes binne dy mei in lange skiednis fan cache-tiidproblemen. In VPN-konsintrator yn in firtuele masine waans host gjin AES-flaggen oan de gast toant is krekt dit gefal, en it wurdt maklik mist om’t de host-CPU de funksje hat.
Kontrolearje wat it proses echt sjocht, net wat de CPU stipet: grep -o aes /proc/cpuinfo | head -1 op Linux, of de ekwivalinte funksjeflag yn it CPU-model fan de hypervisor.
Wêr’t ChaCha20-Poly1305 wint
ChaCha20 is fluch yn draachbere software om’t it allinnich optelling, rotaasje en XOR brûkt, en syn ymplemintaasjes mije by ûntwerp geheimôfhinklike tabelsykjen. Op in apparaat sûnder AES-fersnelling is dat in materieel foardiel, en dêrom hat WireGuard it keazen: de beskriuwing fan it WireGuard-protokol neamt ChaCha20-Poly1305 as syn datasifer sûnder alternatyf.
Dy iene kar sei wat nuttichs: op hardware wêr’t AES fersnelle wurdt, jout WireGuard wat trochfiert fermindere yn ferliking mei AES-GCM, en de auteurs hawwe dat akseptearre yn ruil foar foarsisber gedrach op tillefoans, thúsrouters en kontenerhosts. As dyn float benammen lytse ARM-kasten binne, is dy ruil yn dyn foardiel.
It tsjinoerstelde gefal is in drokke x86-konsintrator, wêr’t AES-GCM mei AES-NI it fluggere en better stipene paad is, en wêr’t ChaCha20 mjitbere CPU per gigabit kostet. Gjin fan beide konstruksjes is in swakheid; de fraach is hokker dyn hardware goedkeap útfiert.
Wat dyn protokol dy echt kieze lit
| 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 |
Merk de splitsing yn OpenVPN op: it kontrôlekanaal en it gegevenskanaal wurde apart ûnderhannele, dus de suite dy’t foar TLS sjochst sei neat oer it sifer dat dyn lading beskermet. De sesjegearfetting meldt beide, en fan de twa mar ien lêze is in gewoane boarne fan betizing.
Yn OpenVPN komt it sifer fan it gegevenskanaal fan de list data-ciphers oan beide kanten. As de list fan de server en dy fan de klant inoar net treffe, falt de ferbining werom op wat data-ciphers-fallback tasteat of mislearret folslein, en dy mislearring wurdt meastentiids de ferkearde laach beskulde. Set deselde list oan beide kanten, en befêstigje dan it ûnderhannele resultaat yn it loch ynstee fan oan te nimmen dat de oarder fan de list respektearre is.
Beslis op grûn fan trije feiten oer de útrissing
Earst, hawwe de einpunten AES-fersnelling? As elke partner it hat, is AES-GCM de goedkeapere kar en de standertwearde yn de measte ûnderholden konfiguraasjes. As in betsjuttend part lytse routers of âldere tillefoans binne, hâldt ChaCha20-Poly1305 de sturt fan de float tsjin om de kapasiteitsgrins te wurden.
Twadde, biedt it protokol oeral in kar? By WireGuard is de beslissing foar dy nommen, en it nuttige wurk is kontrolearje dat it ark deromhinne net stilwei wat oars ferfangt. By OpenVPN en IPsec is it antwurd in konfiguraasjeline en in ûnderhannele resultaat om fêst te lizzen.
Tredde, kinne beide kanten it iens wurde? In sifer dat in partner net ymplemintearret is gjin prestaasjebeslissing, it is in steuring. Dêrom is de partnerlist wichtiger as hokker benchmark ek: in mingde float hat de krusing fan kapasiteiten nedich, net de foarkar fan de fluchste masine.
As jo mjitte, hâld dan it apparaat, it einpunt en de lading itselde en feroarje ien ding. In test dy’t twa servers yn ferskate regio s ferliket mjit de rûte, net it sifer, en in benchmark op in laptop sei neat oer in kontenerhost waans CPU-flaggen maskearre binne. Ferlykje, en skriuw dan op hokker sifer echt ûnderhannele is: dy fêstlizzing is mear wurdich as de benchmark.