AES-GCM neu ChaCha20-Poly1305: dewis seiffr data VPN

Mae'r ddau enw yn gystrawennau AEAD, mae'r ddau wedi'u safoni, ac ar weinydd x86 cyfredol bydd y naill neu'r llall yn llenwi cyswllt gigabit heb ymdrech weladwy. Mae'r dewis yn peidio â bod yn fympwyol pan fyddwch yn gadael y gweinydd hwnnw: yn aml nid oes gan lwybryddion rhad, ffonau hŷn ac offer rhithwir gyflymu AES, ac yno mae'r gwahaniaeth yn fawr. Felly nid y cymharu yw pa seiffr sy'n gyflymach, ond pa seiffr sy'n rhedeg yn dda ar y set hon o bwyntiau terfyn, ac a yw'r protocol hyd yn oed yn cynnig dewis.

Yr un gwaith, creiddiau gwahanol

Mae'r ddau gystrawen yn rhoi cyfrinachedd a chywirdeb mewn un pas ac yn dilysu data cysylltiedig, a dyna pam mae protocolau VPN yn eu defnyddio ar gyfer y sianel ddata. Mae'r gwahaniaeth y tu mewn: seiffr bloc AES mewn modd rhifydd gyda dilysydd polynomial dros GF(2^128) yw AES-GCM, tra bo ChaCha20-Poly1305 yn seiffr ffrwd ag allwedd 256 bit a dilysydd un-tro ar wahân.

Mae'r hyn sy'n bwysig yn weithredol yn gyffredin: mae'r ddau yn methu'n drychinebus pan ailddefnyddir nonce, mae'r ddau angen rheoli gofod nonce fesul allwedd, ac nid yw'r naill yn trwsio partner sy'n dilysu'r peth anghywir. Nid yw proffil sy'n dweud AES-256-GCM yn fwy diogel na'r un sy'n dweud CHACHA20-POLY1305; mae'r ddau yn gryf pan fo'r gweithrediad yn gywir.

Lle mae AES-GCM yn ennill

Mae gan AES gyfarwyddiadau pwrpasol ar y rhan fwyaf o broseswyr modern: AES-NI ar x86, yr estyniadau crypto ar ARMv8, a chyfatebwyr ar ddyluniadau POWER a RISC-V diweddar. Pan fyddant yn bresennol mae GCM yn rhedeg sawl bloc yn gyfochrog fesul dosbarth cylch, ac mae'r gweithrediad meddalwedd yn amherthnasol. Dyma'r achos cyffredin ar gyfer gweinyddwyr, cyfrifiaduron bwrdd gwaith a ffonau cyfredol, a dyna pam mae defnyddio AES yn gyngor diofyn rhesymol mewn canolfan ddata.

Y broblem yw'r achos ail-radd. Heb gyfarwyddiadau pwrpasol mae AES mewn meddalwedd yn araf, a'r gweithrediadau meddalwedd sy'n cael eu gyrru gan dablau sydd â hanes hir o broblemau amseru cache. Mae canolbwyntydd VPN mewn peiriant rhithwir nad yw ei westtyn yn datgelu baneri AES i'r gwestai yn union yr achos hwn, ac mae'n hawdd ei fethu oherwydd bod gan brosesydd y gwesttyn y nodwedd.

Gwiriwch yr hyn y mae'r broses yn ei weld mewn gwirionedd, nid yr hyn y mae'r prosesydd yn ei gefnogi: grep -o aes /proc/cpuinfo | head -1 ar Linux, neu'r faner nodwedd gyfatebol ym model prosesydd yr hypervisor.

Lle mae ChaCha20-Poly1305 yn ennill

Mae ChaCha20 yn gyflym mewn meddalwedd cludadwy oherwydd mai dim ond adio, cylchdroi a XOR y mae'n ei ddefnyddio, ac mae ei weithrediadau yn osgoi chwiliadau tabl sy'n dibynnu ar gyfrinach yn ôl dyluniad. Ar ddyfais heb gyflymu AES mae hynny'n fantais sylweddol, a dyna pam y dewisodd WireGuard ef: mae disgrifiad protocol WireGuard yn rhestru ChaCha20-Poly1305 fel ei seiffr data heb unrhyw amgen.

Mae'r un dewis hwnnw'n dweud rhywbeth defnyddiol: ar galedwedd lle mae AES yn cael ei gyflymu mae WireGuard yn ildio rhywfaint o drwybynedd o gymharu ag AES-GCM, ac mae ei awduron wedi derbyn hynny yn gyfnewid am ymddygiad rhagweladwy ar ffonau, llwybryddion cartref a gwesteiwyr cynwysyddion. Os yw eich fflyd yn bennaf yn focsys ARM bach, mae'r cyfnewid hwnnw o'ch plaid.

Y gwrth-achos yw canolbwyntydd x86 prysur, lle mae AES-GCM gydag AES-NI yn llwybr cyflymach a gwell ei gefnogaeth, a lle mae ChaCha20 yn costio prosesydd mesuradwy fesul gigabit. Nid yw'r naill gystrawen yn wendid; y cwestiwn yw pa un y mae eich caledwedd yn ei gyflawni'n rhad.

Beth y mae eich protocol yn caniatáu i chi ei ddewis

Sylwch ar y rhaniad yn OpenVPN: mae'r sianel reoli a'r sianel ddata yn cael eu negodi ar wahân, felly nid yw'r swît a welwch ar gyfer TLS yn dweud dim am y seiffr sy'n diogelu eich llwyth. Mae crynodeb y sesiwn yn adrodd y ddau, ac mae darllen dim ond un o'r ddau yn ffynhonnell gyffredin o ddryswch.

Yn OpenVPN daw seiffr'r sianel ddata o'r rhestr data-ciphers ar y ddau ben. Os nad yw rhestr'r gweinydd a rhestr y cleient yn croesi, naill ai mae'r cysylltiad yn cwympo'n ôl i'r hyn y mae data-ciphers-fallback yn ei ganiatáu neu mae'n methu'n llwyr, a beïir y methiant hwnnw fel arfer ar y haen anghywir. Gosodwch yr un rhestr ar y ddwy ochr, yna cadarnhewch y canlyniad a negodwyd yn y log yn lle tybio bod trefn y rhestr wedi'i pharchu.

Penderfynwch o dri ffaith am y defnyddiad

Yn gyntaf, a oes gan y pwyntiau terfyn gyflymu AES? Os oes gan bob partner, AES-GCM yw'r dewis rhatach a'r diofyn yn y rhan fwyaf o ffurfweddiadau a gynhelir. Os yw cyfran sylweddol yn llwybryddion bach neu'n ffonau hŷn, mae ChaCha20-Poly1305 yn cadw cynffon y fflyd rhag dod yn derfyn gallu.

Yn ail, a yw'r protocol yn cynnig dewis o gwbl? Gyda WireGuard mae'r penderfyniad wedi'i wneud drosoch, a'r gwaith defnyddiol yw gwirio nad yw'r offer o'i amgylch yn rhoi rhywbeth arall yn ei le yn dawel. Gydag OpenVPN ac IPsec, llinell ffurfweddu yw'r ateb a chanlyniad a negodwyd i'w gofnodi.

Yn drydydd, a all y ddau ben gytuno? Nid yw seiffr nad yw un partner yn ei weithredu yn benderfyniad perfformiad, mae'n doriad. Dyna pam mae'r rhestr partneriaid yn bwysicach nag unrhyw feincnod: mae angen croestoriad galluoedd ar fflyd gymysg, nid hoffter y peiriant cyflymaf.

Os byddwch yn mesur, cadwch y ddyfais, y pwynt terfyn a'r llwyth yn union yr un fath a newidwch un peth. Mae prawf sy'n cymharu dau weinydd mewn rhanbarthau gwahanol yn mesur y llwybr, nid y seiffr, ac nid yw meincnod gliniadur yn dweud dim am westtyn cynwysyddion y mae ei faneri prosesydd wedi'u cuddio. Cymharwch, yna nodwch pa seiffr a negodwyd mewn gwirionedd: mae'r cofnod hwnnw'n werth mwy na'r meincnod.