AES-GCM eða ChaCha20-Poly1305: að velja gagnadulkóðun fyrir VPN

Bæði nöfnin eru AEAD-smíðar, bæði eru stöðluð, og á núverandi x86-þjóni mettar hvort um sig gígabíta tengingu án sýnilegrar fyrirhafnar. Valið hættir að vera handahófskennt þegar þú yfirgefur þann þjón: ódýrir beinar, eldri símar og sýndartæki hafa oft ekki AES-hröðun, og þar er munurinn mikill. Samanburðurinn snýst því ekki um hvaða dulritun er hraðari, heldur hvaða dulritun gengur vel á þessu mengi endapunkta og hvort samskiptareglan bjóði yfirhöfuð val.

Sama vinna, mismunandi kjarnar

Báðar smíðarnar veita trúnað og heilleika í einni umferð og sannreyna tengd gögn, og þess vegna nota VPN-samskiptareglur þær fyrir gagnarásina. Munurinn er innanverður: AES-GCM er AES-blokkdulritun í teljaraham með margliðusannreyndara yfir GF(2^128), en ChaCha20-Poly1305 er straumdulritun með 256 bita lykli og aðskildum einnota sannreyndara.

Það sem skiptir máli í rekstri er sameiginlegt: bæði mistakast hörmulega við endurnotkun nonce, bæði þurfa stjórnun nonce-rýmis fyrir hvern lykil, og hvorugt lagar mótaðila sem sannreynir rangt. Prófíll sem segir AES-256-GCM er ekki öruggari en sá sem segir CHACHA20-POLY1305; bæði eru sterk þegar útfærslan er rétt.

Þar sem AES-GCM vinnur

AES hefur sérhæfðar skipanir á flestum nútíma örgjörvum: AES-NI á x86, dulritunarviðbætur á ARMv8 og hliðstæður á nýlegum POWER- og RISC-V-hönnunum. Þegar þær eru til staðar keyrir GCM nokkra blokka samhliða fyrir hvern hringflokk og hugbúnaðarútfærslan verður óviðkomandi. Þetta er algenga tilfellið fyrir þjóna, skjáborð og núverandi síma, og þess vegna er ráðið að nota AES hæfilegt sjálfgefið gildi í gagnaveri.

Vandamálið er tilfellið af annarri gráðu. Án sérhæfðra skipana er AES í hugbúnaði hægt, og töflustýrðar hugbúnaðarútfærslur eru þær sem eiga sér langa sögu um vandamál með tímasetningu skyndiminnis. VPN-samþjöppun í sýndarvél þar sem hýsillinn sýnir gestinum ekki AES-flögg er nákvæmlega þetta tilfelli, og auðvelt er að missa af því vegna þess að örgjörvi hýsilsins hefur eiginleikann.

Athugaðu hvað ferlið sér í raun, ekki hvað örgjörvinn styður: grep -o aes /proc/cpuinfo | head -1 á Linux, eða samsvarandi eiginleikaflögg í örgjörvalíkani ofurstjórnandans.

Þar sem ChaCha20-Poly1305 vinnur

ChaCha20 er hratt í flytjanlegum hugbúnaði því það notar aðeins samlagningu, snúning og XOR, og útfærslur þess forðast af hönnun töfluleit sem er háð leyndarmáli. Á tæki án AES-hröðunar er það efnislegur kostur, og þess vegna valdi WireGuard það: lýsing WireGuard-samskiptareglunnar telur ChaCha20-Poly1305 sem gagnadulritun sína án annars valkosts.

Þetta eina val segir eitthvað gagnlegt: á vélbúnaði þar sem AES er hraðað gefur WireGuard eftir nokkurn afköst miðað við AES-GCM, og höfundar þess sættu því í staðinn fyrir fyrirsjáanlega hegðun á símum, heimabeinum og geymsluhýslum. Ef flotinn þinn er að mestu litlir ARM-kassar er þessi skipti þér í hag.

Hitt tilfellið er annasamur x86-samþjöppun, þar sem AES-GCM með AES-NI er hraðari og betur studd leið, og þar sem ChaCha20 kostar mælanlegan örgjörva á hvern gígabít. Hvorki smíðin er veikleiki; spurningin er hverja vélbúnaðurinn þinn framkvæmir ódýrt.

Hvað samskiptareglan þín leyfir þér í raun að velja

Taktu eftir skiptingunni í OpenVPN: stjórnrásin og gagnarásin eru samningsbundnar í sitthvoru lagi, svo pakkinn sem þú sérð fyrir TLS segir ekkert um dulritunina sem verndar hyrninguna þína. Yfirlit setunnar greinir frá báðum, og að lesa aðeins aðra þeirra er algeng uppspretta ruglings.

Í OpenVPN kemur dulritun gagnarásarinnar úr listanum data-ciphers á báðum endum. Ef listi þjónsins og listi biðlarans skerast ekki fer tengingin annaðhvort aftur í það sem data-ciphers-fallback leyfir eða mistekst algjörlega, og það mistak er venjulega kennt við rangt lag. Stilltu sama lista á báðar hliðar, og staðfestu síðan samningsbundna niðurstöðu í annálnum í stað þess að gera ráð fyrir að röð listans hafi verið virt.

Ákveddu út frá þremur staðreyndum um uppsetninguna

Í fyrsta lagi, hafa endapunktarnir AES-hröðun? Ef hver mótaðili hefur hana er AES-GCM ódýrara valið og sjálfgefið í flestum viðhaldnum stillingum. Ef verulegur hluti eru litlir beinar eða eldri símar kemur ChaCha20-Poly1305 í veg fyrir að hali flotans verði afkastamarkið.

Í öðru lagi, býður samskiptareglan yfirhöfuð val? Með WireGuard er ákvörðunin þegar tekin fyrir þig, og gagnlega verkið er að sannreyna að verkfærin í kringum hana setji ekki eitthvað annað í staðinn í kyrrþey. Með OpenVPN og IPsec er svarið stillingarlína og samningsbundin niðurstaða sem á að skrá.

Í þriðja lagi, geta báðar hliðar komið sér saman? Dulritun sem einn mótaðili útfærir ekki er ekki ákvörðun um afköst, það er bilun. Þess vegna skiptir mótaðilalistinn meira máli en nokkur mælikvarði: blandaður floti þarf sniðmengi getu, ekki val hraðasta vélarinnar.

Ef þú mælir skaltu halda tækinu, endapunktinum og álaginu óbreyttum og breyta einu atriði. Próf sem ber saman tvo þjóna á mismunandi svæðum mælir leiðina, ekki dulritunina, og mælikvarði á fartölvu segir ekkert um geymsluhýsil þar sem örgjörvaflöggin eru fjarlægð. Berðu saman, og skrifaðu síðan niður hvaða dulritun var í raun samningsbundin: sú skráning er meira virði en mælikvarðinn.