AES-GCM või ChaCha20-Poly1305: VPN-i andmešifri valimine

Mõlemad nimed on AEAD-konstruktsioonid, mõlemad on standarditud, ja tänapäevases x86-serveris küllastab kumbki neist gigabitise lingi ilma nähtava vaevata. Valik lakkab olemast meelevaldne siis, kui sellest serverist lahkute: odavatel ruuteritel, vanematel telefonidel ja virtuaalsetel seadmetel puudub sageli AES-kiirendus, ja seal on vahe suur. Seega ei ole võrdlus selles, milline šiffer on kiirem, vaid selles, milline šiffer töötab selles lõpp-punktide komplektis hästi ja kas protokoll üldse pakub valikut.

Sama töö, teised tuumad

Mõlemad konstruktsioonid annavad konfidentsiaalsuse ja terviklikkuse ühe läbimisega ning autendivad seotud andmeid, mistõttu VPN-protokollid kasutavad neid andmekanalis. Erinevus on sees: AES-GCM on AES-plokkšiffer loenduri režiimis polünoomilise autentijaga üle GF(2^128), samas kui ChaCha20-Poly1305 on 256-bitise võtmega voošiffer eraldi ühekordse autentijaga.

Operatiivselt oluline on ühine: mõlemad ebaõnnestuvad katastroofiliselt nonce korduskasutamisel, mõlemad vajavad nonce-ruumi haldamist võtme kohta, ja kumbki ei paranda partnerit, kes autendib vale asja. Profiil, mis ütleb AES-256-GCM, ei ole turvalisem kui see, mis ütleb CHACHA20-POLY1305; mõlemad on tugevad, kui teostus on õige.

Kus AES-GCM võidab

AES-il on spetsiaalsed käsud enamikus tänapäevastes protsessorites: AES-NI x86-l, krüpto-laiendid ARMv8-l ja ekvivalendid uuemates POWER- ja RISC-V-kavandites. Kui need on olemas, jooksutab GCM mitut plokki paralleelselt tsükli klassi kohta ja tarkvara teostus on tähtsusetu. See on tavaline juhtum serverites, lauaarvutites ja praegustes telefonides, ja seetõttu on nõuanne kasutada AES-i andmekeskuses mõistlik vaikevalik.

Probleem on teist järku juhtum. Ilma spetsiaalsete käskudeta on AES tarkvaras aeglane, ja tabelipõhised tarkvara teostused on need, millel on pikk vahemälu ajastuse probleemide ajalugu. VPN-kontsentraator virtuaalmasinas, mille host ei näita külalisele AES-i lippe, on täpselt see juhtum, ja seda on lihtne tähelepanuta jätta, sest hosti protsessoril on see funktsioon olemas.

Kontrollige, mida protsess tegelikult näeb, mitte mida protsessor toetab: grep -o aes /proc/cpuinfo | head -1 Linuxis või vastav funktsioonilipp hüperviisori protsessorimudelis.

Kus ChaCha20-Poly1305 võidab

ChaCha20 on kaasaskantavas tarkvaras kiire, sest kasutab ainult liitmist, pööramist ja XOR-i, ning selle teostused väldivad disaini järgi saladusest sõltuvaid tabeliotsinguid. AES-kiirenduseta seadmes on see oluline eelis, ja seetõttu valis WireGuard just selle: WireGuardi protokolli kirjeldus loetleb ChaCha20-Poly1305 selle andmešifrina ilma alternatiivita.

See üks valik ütleb midagi kasulikku: riistvaras, kus AES on kiirendatud, loovutab WireGuard veidi läbilaskevõimet võrreldes AES-GCM-iga, ja selle autorid on sellega nõustunud vastutasuks ettearvatava käitumise eest telefonides, koduruuterites ja konteinerite hostides. Kui teie park on peamiselt väikesed ARM-karbid, on see vahetus teie kasuks.

Vastupidine juhtum on koormatud x86-kontsentraator, kus AES-GCM koos AES-NI-ga on kiirem ja paremini toetatud tee, ja kus ChaCha20 maksab mõõdetavat protsessori aega iga gigabiti kohta. Kumbki konstruktsioon ei ole nõrkus; küsimus on, millist teie riistvara odavalt täidab.

Mida teie protokoll teil tegelikult valida laseb

Pange tähele jaotust OpenVPN-is: juhtkanal ja andmekanal peetakse läbirääkimisi eraldi, seega TLS-i jaoks nähtav komplekt ei ütle midagi šifri kohta, mis kaitseb teie lasti. Sessiooni kokkuvõte teatab mõlemast, ja ainult ühe kahest lugemine on tavaline segaduse allikas.

OpenVPN-is tuleb andmekanali šiffer mõlemas otsas data-ciphers loendist. Kui serveri loend ja kliendi loend ei lõiku, langeb ühendus tagasi sellele, mida lubab data-ciphers-fallback, või ebaõnnestub täielikult, ja seda ebaõnnestumist süüdistatakse tavaliselt vales kihis. Pange mõlemale poole sama loend, seejärel kinnitage kokkulepitud tulemus logis, selle asemel et eeldada, et loendi järjekorda austati.

Otsustage kolme juurutamise fakti põhjal

Esiteks, kas lõpp-punktidel on AES-kiirendus? Kui igal partneril on, on AES-GCM odavam valik ja vaikeväärtus enamikus hooldatud konfiguratsioonides. Kui märkimisväärne osa on väikesed ruuterid või vanemad telefonid, hoiab ChaCha20-Poly1305 ära, et pargi saba saaks mahupiiriks.

Teiseks, kas protokoll üldse pakub valikut? WireGuardi puhul on otsus teie eest tehtud, ja kasulik töö on kontrollida, et selle ümber olevad tööriistad ei asenda vaikselt midagi muud. OpenVPN-i ja IPsec-i puhul on vastuseks konfiguratsioonirida ja kirja pandav kokkulepitud tulemus.

Kolmanda, kas mõlemad pooled saavad kokku leppida? Šiffer, mida üks partner ei teosta, ei ole jõudluse otsus, vaid katkestus. Seetõttu loeb partnerite loend rohkem kui ükski võrdlusmõõdik: segapark vajab võimete lõikumist, mitte kiireima masina eelistust.

Kui mõõdate, hoidke seade, lõpp-punkt ja koormus samadena ning muutke ühte asja. Test, mis võrdleb kahte serverit eri piirkondades, mõõdab marsruuti, mitte šifrit, ja sülearvuti mõõtmine ei ütle midagi konteineri hosti kohta, mille protsessorilipud on maskeeritud. Võrrelge ja kirjutage seejärel üles, milline šiffer tegelikult kokku lepiti: see kirje on väärtuslikum kui mõõtmine.