AES-GCM of ChaCha20-Poly1305: kies die dataversleuteling vir jou VPN

Albei name is AEAD-konstruksies, albei is gestandaardiseer, en op n huidige x86-bediener sal enigeen van hulle n gigabit-lyn versadig sonder sigbare inspanning. Die keuse word eers willekeurig wanneer jy daardie bediener verlaat: goedkoop routers, ouer telefone en virtuele toestelle het dikwels geen AES-versnelling nie, en daar is die verskil groot. Die vergelyking is dus nie watter syfer vinniger is nie, maar watter syfer hierdie eindpuntstel goed laat loop, en of die protokol selfs n keuse bied.

Dieselfde werk, ander kerne

Albei konstruksies gee vertroulikheid en integriteit in een pas en authentiseer geassosieerde data, daarom gebruik VPN-protokolle hulle vir die datakanaal. Die verskil le binne: AES-GCM is die AES-bloksyfer in n tellermodus met n polinoomauthentiseerder oor GF(2^128), terwyl ChaCha20-Poly1305 n stroomsyfer met n 256-bis-sleutel en n aparte eenmalige authentiseerder is.

Wat operasioneel saak maak, is gemeenskaplik: albei misluk katastrofies by hergebruik van nonce, albei het nonce-ruimte per sleutel nodig, en nie een herstel n portuur wat die verkeerde ding authentiseer nie. n Profiel wat AES-256-GCM se, is nie veiliger as een wat CHACHA20-POLY1305 se nie; albei is sterk wanneer die implementering korrek is.

Waar AES-GCM wen

AES het toegewyde instruksies op die meeste moderne CPU's: AES-NI op x86, die kripto-uitbreidings op ARMv8 en ekwivalente op onlangse POWER- en RISC-V-ontwerpe. Wanneer dit teenwoordig is, loop GCM verskeie blokke parallel per siklusklas en is die sagteware-implementering irrelevant. Dit is die algemene geval vir bedieners, rekenaars en huidige telefone, en dit is waarom gebruik AES n redelike verstekraad in n datasentrum is.

Die probleem is die tweede-orde geval. Sonder toegewyde instruksies is AES in sagteware stadig, en tabelgedrewe sagteware-implementerings is diegene met n lang geskiedenis van kas-tydsprobleme. n VPN-konsentrator in n virtuele masjien waarvan die gasheer geen AES-vlae aan die gas blootstel nie, is presies hierdie geval, en dit word maklik gemis omdat die gasheer-CPU die kenmerk het.

Kyk wat die proses werklik sien, nie wat die CPU ondersteun nie: grep -o aes /proc/cpuinfo | head -1 op Linux, of die ekwivalente kenmerkvlae in die hipervisor se CPU-model.

Waar ChaCha20-Poly1305 wen

ChaCha20 is vinnig in draagbare sagteware omdat dit net optelling, rotasie en XOR gebruik, en sy implementerings vermy geheimafhanklike tabelsoektogte per ontwerp. Op n toestel sonder AES-versnelling is dit n wesenlike voordeel, en dit is die rede waarom WireGuard dit gekies het: die WireGuard-protokolbeskrywing lys ChaCha20-Poly1305 as sy datasyfer sonder alternatief.

Daardie enkele keuse se iets nuttigs: op hardeware waar AES versnel word, gee WireGuard n bietjie deurvloei op teenoor AES-GCM, en sy outeurs het dit aanvaar in ruil vir voorspelbare gedrag oor telefone, tuisrouters en houer-gashere. As jou vloot meestal klein ARM-bokse is, is daardie ruil in jou guns.

Die teenoorgestelde geval is n besige x86-konsentrator, waar AES-GCM met AES-NI die vinniger en beter ondersteunde pad is, en waar ChaCha20 meetbare CPU per gigabit kos. Nie een konstruksie is n swakheid nie; die vraag is watter een jou hardeware goedkoop uitvoer.

Wat jou protokol jou werklik laat kies

Let op die splitsing in OpenVPN: die beheerkanaal en die datakanaal word afsonderlik onderhandel, so die suite wat jy vir TLS sien, se niks oor die syfer wat jou vrag beskerm nie. Die sessieopsomming rapporteer albei, en om net een van die twee te lees is n algemene bron van verwarring.

In OpenVPN kom die datakanaal-syfer uit die data-ciphers-lys aan beide kante. As die bediener se lys en die kliënt se lys nie oorvleuel nie, val die verbinding terug op wat data-ciphers-fallback toelaat of misluk heeltemal, en daardie mislukking word gewoonlik aan die verkeerde laag verwyt. Stel dieselfde lys aan beide kante, en bevestig dan die onderhandelde resultaat in die log in plaas daarvan om te aanvaar die volgorde van die lys is geëerbiedig.

Besluit op grond van drie feite oor die ontplooiing

Eerstens, het die eindpunte AES-versnelling? As elke portuur dit het, is AES-GCM die goedkoper keuse en die verstek in die meeste onderhoude konfigurasies. As n betekenisvolle deel klein routers of ouer telefone is, hou ChaCha20-Poly1305 die stert van die vloot daarvan weg om die kapasiteitslimiet te word.

Tweedens, bied die protokol hoegenaamd n keuse? Met WireGuard is die besluit vir jou geneem, en die nuttige werk is om te verifieer dat die gereedskap daarom nie stilweg iets anders vervang nie. Met OpenVPN en IPsec is die antwoord n konfigurasielyn en n onderhandelde resultaat om aan te teken.

Derdens, kan albei kante saamstem? n Syfer wat een portuur nie implementeer nie, is nie n prestasiebesluit nie, dit is n onderbreking. Dit is waarom die portuurlys meer saak maak as enige maatstaf: n gemengde vloot het die snyding van vermoëns nodig, nie die voorkeur van die vinnigste masjien nie.

As jy wel meet, hou die toestel, die eindpunt en die werklading identies en verander een ding. n Toets wat twee bedieners in verskillende streke vergelyk, meet die roete, nie die syfer nie, en n skootrekenaar-maatstaf se niks oor n houer-gasheer wie se CPU-vlae gemaskeer is nie. Vergelyk, en skryf dan neer watter syfer werklik onderhandel is: daardie rekord is meer werd as die maatstaf.