Abi nosaukumi ir AEAD konstrukcijas, abas ir standartizētas, un pašreizējā x86 serverī jebkura no tām piepildīs gigabita savienojumu bez pamanāmas piepūles. Izvēle pārstāj būt patvaļīga, kad pamet šo serveri: lēti maršrutētāji, vecāki tālruņi un virtuālās ierīces bieži vien nav ar AES paātrinājumu, un tur starpība ir liela. Tāpēc salīdzinājums nav par to, kurš šifrs ir ātrāks, bet par to, kurš šifrs labi darbojas šajā galapunktu kopā un vai protokols vispār piedāvā izvēli.

Tas pats darbs, citi kodoli

Abas konstrukcijas vienā piegājienā nodrošina konfidencialitāti un integritāti un autentificē saistītos datus, tāpēc VPN protokoli tās izmanto datu kanālam. Atšķirība ir iekšpusē: AES-GCM ir AES bloka šifrs skaitītāja režīmā ar polinomiālu autentifikatoru virs GF(2^128), savukārt ChaCha20-Poly1305 ir plūsmas šifrs ar 256 bitu atslēgu un atsevišķu vienreizēju autentifikatoru.

Operatīvi svarīgais ir kopīgs: abas katastrofāli sabrūk, atkārtoti lietojot nonce, abām nepieciešama nonce telpas pārvaldība katrai atslēgai, un neviena nelabo partneri, kas autentificē nepareizo lietu. Profils, kurā teikts AES-256-GCM, nav drošāks par to, kurā teikts CHACHA20-POLY1305; abi ir spēcīgi, ja ieviešana ir pareiza.

Kur uzvar AES-GCM

AES ir īpašas instrukcijas lielākajā daļā mūsdienu CPU: AES-NI uz x86, kriptogrāfijas paplašinājumi uz ARMv8 un ekvivalenti jaunākajos POWER un RISC-V dizainos. Kad tie ir, GCM izpilda vairākus blokus paralēli uz cikla klasi, un programmatūras ieviešana kļūst nebūtiska. Tas ir parastais gadījums serveriem, galddatoriem un pašreizējiem tālruņiem, un tāpēc ieteikums lietot AES ir saprātīga noklusējuma vērtība datu centrā.

Problēma ir otrās kārtas gadījums. Bez īpašām instrukcijām AES programmatūrā ir lēns, un uz tabulām balstītas programmatūras ieviešanas ir tās ar garu kešatmiņas laika problēmu vēsturi. VPN koncentrators virtuālajā mašīnā, kuras resursdators guestam neparāda AES karodziņus, ir tieši šis gadījums, un to ir viegli palaist garām, jo resursdatora CPU šī funkcija ir.

Pārbaudi, ko process faktiski redz, nevis ko CPU atbalsta: grep -o aes /proc/cpuinfo | head -1 uz Linux vai atbilstošo funkcijas karodziņu hipervizora CPU modelī.

Kur uzvar ChaCha20-Poly1305

ChaCha20 ir ātrs pārnēsājamā programmatūrā, jo izmanto tikai saskaitīšanu, rotāciju un XOR, un tā ieviešanas pēc dizaina izvairās no noslēpumam atkarīgas tabulu meklēšanas. Ierīcē bez AES paātrinājuma tas ir materiāla priekšrocība, un tāpēc WireGuard to izvēlējās: WireGuard protokola apraksts uzskaita ChaCha20-Poly1305 kā tā datu šifru bez alternatīvas.

Šī vienīgā izvēle pasaka ko noderīgu: aparatūrā, kur AES ir paātrināts, WireGuard atsakās no daļas caurlaidspējas salīdzinājumā ar AES-GCM, un tā autori to pieņēma apmaiņā pret paredzamu uzvedību tālruņos, mājas maršrutētājos un konteineru resursdatoros. Ja tava flote pārsvarā ir mazas ARM kastes, šī apmaiņa ir tavā labā.

Pretējais gadījums ir noslogots x86 koncentrators, kur AES-GCM ar AES-NI ir ātrākais un labāk atbalstītais ceļš, un kur ChaCha20 izmaksā izmērāmu CPU uz katru gigabitu. Neviena konstrukcija nav vājums; jautājums ir, kuru tava aparatūra izpilda lēti.

Ko tavs protokols faktiski ļauj izvēlēties

ProtocolWhat you get
WireGuardChaCha20-Poly1305 only; no negotiation
OpenVPN 2.5 and laterData channel negotiated from data-ciphers: AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305
IPsec / IKEv2AES-GCM as a combined-mode transform, or ChaCha20-Poly1305 where both peers implement it
OpenVPN control channelTLS decides; TLS 1.3 offers AES-GCM and ChaCha20-Poly1305 suites

Ievēro sadalījumu OpenVPN: vadības kanāls un datu kanāls tiek sarunāti atsevišķi, tāpēc komplekts, ko redzi TLS, neko nepasaka par šifru, kas aizsargā tavu kravu. Sesijas kopsavilkums ziņo par abiem, un lasīt tikai vienu no diviem ir biežs apjukuma avots.

OpenVPN datu kanāla šifrs nāk no data-ciphers saraksta abos galos. Ja servera saraksts un klienta saraksts nekrustojas, savienojums vai nu atkāpjas uz to, ko pieļauj data-ciphers-fallback, vai pilnībā sabrūk, un šī neveiksme parasti tiek piedēvēta nepareizajam slānim. Iestati to pašu sarakstu abās pusēs, pēc tam apstiprini sarunāto rezultātu žurnālā, nevis pieņem, ka saraksta kārtība tika ievērota.

Izlem pēc trim faktiem par izvietošanu

Pirmkārt, vai galapunktiem ir AES paātrinājums? Ja tas ir katram partnerim, AES-GCM ir lētākā izvēle un noklusējums lielākajā daļā uzturēto konfigurāciju. Ja ievērojama daļa ir mazi maršrutētāji vai vecāki tālruņi, ChaCha20-Poly1305 neļauj flotes astei kļūt par jaudas ierobežojumu.

Otrkārt, vai protokols vispār piedāvā izvēli? Ar WireGuard lēmums jau ir pieņemts tavā vietā, un noderīgais darbs ir pārbaudīt, vai rīki ap to klusībā neievieto ko citu. Ar OpenVPN un IPsec atbilde ir konfigurācijas rinda un sarunātais rezultāts, kas jāpieraksta.

Treškārt, vai abas puses var vienoties? Šifrs, ko viens partneris neievieš, nav veiktspējas lēmums, tas ir pārtraukums. Tāpēc partneru saraksts ir svarīgāks par jebkuru mērījumu: jauktai flotei vajag iespēju krustpunktu, nevis ātrākās mašīnas izvēli.

Ja mēri, turi ierīci, galapunktu un slodzi vienādus un maini vienu lietu. Tests, kas salīdzina divus serverus dažādos reģionos, mēra maršrutu, nevis šifru, un klēpjdatora mērījums neko nepasaka par konteineru resursdatoru, kura CPU karodziņi ir maskēti. Salīdzini, pēc tam pieraksti, kurš šifrs faktiski tika sarunāts: šis ieraksts ir vērtīgāks par mērījumu.

Saistītie raksti