AES-GCM vai ChaCha20-Poly1305: VPN:n datasalauksen valinta

Molemmat nimet ovat AEAD-rakenteita, molemmat on standardoitu, ja nykyisellä x86-palvelimella kumpi tahansa kyllästää gigabitin yhteyden ilman näkyvää vaivaa. Valinnasta tulee mielivaltainen vasta kun poistut siltä palvelimelta: halvoissa reitittimissä, vanhemmissa puhelimissa ja virtuaalisissa laitteissa ei usein ole AES-kiihdytystä, ja siellä ero on suuri. Vertailu ei siis ole siitä, kumpi salaus on nopeampi, vaan siitä, kumpi salaus toimii hyvin tässä päätepisteiden joukossa ja tarjoaako protokolla edes valintaa.

Sama työ, eri ytimet

Molemmat rakenteet antavat luottamuksellisuuden ja eheyden yhdellä kierroksella ja todentavat liittyvät tiedot, minkä vuoksi VPN-protokollat käyttävät niitä datakanavassa. Ero on sisällä: AES-GCM on AES-lohkosalaus laskuritilassa, jossa on polynominen todentaja GF(2^128):n yli, kun taas ChaCha20-Poly1305 on 256-bittisellä avaimella toimiva jonosalaus ja erillinen kertakäyttöinen todentaja.

Operatiivisesti tärkeä on yhteistä: molemmat epäonnistuvat katastrofaalisesti noncen uudelleenkäytössä, molemmat tarvitsevat nonce-avaruuden hallintaa avainta kohden, eikä kumpikaan korjaa vastapuolta, joka todentaa väärän asian. Profiili, joka sanoo AES-256-GCM, ei ole turvallisempi kuin se, joka sanoo CHACHA20-POLY1305; molemmat ovat vahvoja, kun toteutus on oikein.

Missä AES-GCM voittaa

AES:llä on omat käskynsä useimmissa nykyaikaisissa suorittimissa: AES-NI x86:lla, salauslaajennukset ARMv8:ssa ja vastaavat uusissa POWER- ja RISC-V-suunnitelmissa. Kun ne ovat käytettävissä, GCM suorittaa useita lohkoja rinnakkain sykkiluokkaa kohden ja ohjelmistototeutus on merkityksetön. Tämä on tavallinen tilanne palvelimilla, pöytäkoneilla ja nykyisillä puhelimilla, ja siksi kehotus käyttää AES:ää on järkevä oletus datakeskuksessa.

Ongelma on toisen kertaluvun tapaus. Ilman omia käskyjä AES on ohjelmistossa hidas, ja taulupohjaisilla ohjelmistototeutuksilla on pitkä historia välimuistin ajoitusongelmista. VPN-keskitin virtuaalikoneessa, jonka isäntä ei paljasta AES-lippuja vieraalle, on juuri tämä tapaus, ja se jää helposti huomaamatta, koska isännän suorittimessa ominaisuus on.

Tarkista, mitä prosessi todella näkee, ei mitä suoritin tukee: grep -o aes /proc/cpuinfo | head -1 Linuxissa tai vastaava ominaisuuslippu hypervisorin suoritinmallissa.

Missä ChaCha20-Poly1305 voittaa

ChaCha20 on nopea siirrettävässä ohjelmistossa, koska se käyttää vain yhteenlaskua, kierrätystä ja XOR:ia, ja sen toteutukset välttävät suunnittelultaan salaisuudesta riippuvia tauluhakuja. Laitteessa ilman AES-kiihdytystä se on oleellinen etu, ja siksi WireGuard valitsi sen: WireGuard-protokollan kuvaus luettelee ChaCha20-Poly1305:n datasalauksenaan ilman vaihtoehtoa.

Tämä yksi valinta kertoo jotain hyödyllistä: laitteistossa, jossa AES on kiihdytetty, WireGuard luovuttaa hieman suorituskykyä AES-GCM:ään verrattuna, ja sen tekijät ovat hyväksyneet sen vastineeksi ennustettavasta käytöksestä puhelimissa, kotireitittimissä ja kontti-isännissä. Jos laitekantasi on pääosin pieniä ARM-laatikoita, kauppa on sinun edukseen.

Vastakkainen tapaus on kuormitettu x86-keskitin, jossa AES-GCM AES-NI:n kanssa on nopeampi ja paremmin tuettu polku ja jossa ChaCha20 maksaa mitattavaa suoritinaikaa gigabittiä kohden. Kumpikaan rakenne ei ole heikkous; kysymys on siitä, kumman laitteistosi suorittaa halvalla.

Mitä protokollasi todella antaa sinun valita

Huomaa OpenVPN:n jako: ohjauskanava ja datakanava neuvotellaan erikseen, joten TLS:lle näkemäsi sarja ei kerro mitään salauksesta, joka suojaa hyötykuormaasi. Istunnon yhteenveto kertoo molemmat, ja vain toisen lukeminen on tavallinen sekaannuksen lähde.

OpenVPN:ssä datakanavan salaus tulee data-ciphers-listalta molemmissa päissä. Jos palvelimen lista ja asiakkaan lista eivät leikkaa, yhteys joko palaa siihen, mihin data-ciphers-fallback antaa luvan, tai epäonnistuu kokonaan, ja se epäonnistuminen sysätään yleensä väärän kerroksen syyksi. Aseta sama lista molemmille puolille ja vahvista sitten neuvoteltu tulos lokista sen sijaan, että olettaisit listan järjestyksen tulleen noudatetuksi.

Päätä kolmen käyttöönottoa koskevan tosiasian perusteella

Ensinnäkin, onko päätepisteillä AES-kiihdytys? Jos jokaisella vastapuolella on, AES-GCM on halvempi valinta ja oletus useimmissa ylläpidetyissä kokoonpanoissa. Jos merkittävä osa on pieniä reitittimiä tai vanhempia puhelimia, ChaCha20-Poly1305 estää laitekannan hännän muuttumisen kapasiteetin rajaksi.

Toiseksi, tarjoaako protokolla ylipäätään valintaa? WireGuardissa päätös on tehty puolestasi, ja hyödyllinen työ on varmistaa, etteivät sen ympärillä olevat työkalut vaihda hiljaa jotain muuta. OpenVPN:ssä ja IPsecissä vastaus on kokoonpanorivi ja kirjattava neuvoteltu tulos.

Kolmanneksi, voivatko molemmat päät sopia? Salaus, jota yksi vastapuoli ei toteuta, ei ole suorituskykypäätös vaan katkos. Siksi vastapuolten lista on tärkeämpi kuin mikään vertailumittaus: sekalaista laitekantaa varten tarvitaan kykyjen leikkaus, ei nopeimman koneen mieltymys.

Jos mittaat, pidä laite, päätepiste ja kuormitus samoina ja muuta yhtä asiaa. Testi, joka vertaa kahta palvelinta eri alueilla, mittaa reittiä, ei salausta, eikä kannettavan tietokoneen mittaus kerro mitään kontti-isännästä, jonka suoritinliput on peitetty. Vertaa ja kirjoita sitten muistiin, mikä salaus todella neuvoteltiin: se merkintä on arvokkaampi kuin mittaus.