Абодва назвы — гэта канструкцыі AEAD, абодва стандартызаваныя, і на сучасным серверы x86 любая з іх насыціць гігабітны канал без прыкметных намаганняў. Выбар перастае быць адвольным, калі вы сыходзіце з гэтага сервера: танныя маршрутызатары, старыя тэлефоны і віртуальныя прылады часта не маюць паскарэння AES, і там розніца вялікая. Таму параўнанне не пра тое, які шыфр хутчэйшы, а пра тое, які шыфр добра выконваецца на гэтым наборы канцавых пунктаў і ці прапануе пратакол выбар наогул.

Тая ж праца, іншыя ядры

Абедзве канструкцыі даюць канфідэнцыяльнасць і цэласнасць за адзін праход і аўтэнтыфікуюць звязаныя даныя, таму пратаколы VPN выкарыстоўваюць іх для канала даных. Розніца ўнутры: AES-GCM — гэта блокавы шыфр AES у рэжыме лічыльніка з полінаміальным аўтэнтыфікатарам над GF(2^128), а ChaCha20-Poly1305 — патоковы шыфр з 256-бітным ключом і асобным аднаразовым аўтэнтыфікатарам.

Тое, што важна эксплуатацыйна, агульнае: абодва катастрафічна выходзяць з ладу пры паўторным выкарыстанні nonce, абодва патрабуюць кіравання прасторай nonce для кожнага ключа, і ні адзін не выпраўляе партнёра, які аўтэнтыфікуе не тое. Профіль, які кажа AES-256-GCM, не больш бяспечны за той, што кажа CHACHA20-POLY1305; абодва моцныя, калі рэалізацыя правільная.

Дзе перамагае AES-GCM

AES мае спецыяльныя інструкцыі на большасці сучасных працэсараў: AES-NI на x86, крыптапашырэнні на ARMv8 і эквіваленты на новых распрацоўках POWER і RISC-V. Калі яны ёсць, GCM выконвае некалькі блокаў паралельна за клас цыклаў, і праграмная рэалізацыя не мае значэння. Гэта звычайная справа для сервераў, настольных кампутараў і сучасных тэлефонаў, і менавіта таму парада выкарыстоўваць AES — разумная па змаўчанні ў цэнтры апрацоўкі даных.

Праблема — гэта выпадак другога парадку. Без спецыяльных інструкцый AES у праграмным забеспячэнні павольны, а рэалізацыі, кіраваныя табліцамі, маюць доўгую гісторыю праблем з часам доступу да кэша. Канцэнтратар VPN у віртуальнай машыне, чый хост не паказвае гасцю сцягі AES, — гэта менавіта такі выпадак, і яго лёгка прапусціць, бо працэсар хоста такую функцыю мае.

Праверце, што бачыць працэс, а не што падтрымлівае працэсар: grep -o aes /proc/cpuinfo | head -1 у Linux або адпаведны сцяг функцыі ў мадэлі працэсара гіпервізара.

Дзе перамагае ChaCha20-Poly1305

ChaCha20 хуткі ў пераносным праграмным забеспячэнні, бо выкарыстоўвае толькі складанне, вярчэнне і XOR, а яго рэалізацыі па задуме пазбягаюць пошуку ў табліцах, які залежыць ад сакрэту. На прыладзе без паскарэння AES гэта істотная перавага, і менавіта таму WireGuard абраў яго: апісанне пратакола WireGuard пералічвае ChaCha20-Poly1305 як шыфр даных без альтэрнатывы.

Гэты адзіны выбар кажа нешта карыснае: на апаратным забеспячэнні, дзе AES паскораны, WireGuard саступае частку прапускной здольнасці ў параўнанні з AES-GCM, і яго аўтары прынялі гэта ў абмен на прадказальныя паводзіны на тэлефонах, хатніх маршрутызатарах і хастах кантэйнераў. Калі ваш парк — пераважна невялікія скрынкі ARM, гэты абмен на вашу карысць.

Супрацьлеглы выпадак — загружаны канцэнтратар x86, дзе AES-GCM з AES-NI з'яўляецца хутчэйшым і лепш падтрыманым шляхам, а ChaCha20 каштуе вымернага часу працэсара на кожны гігабіт. Ні адна канструкцыя не з'яўляецца слабасцю; пытанне ў тым, якую ваша абсталяванне выконвае танна.

Што ваш пратакол фактычна дазваляе выбраць

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

Звярніце ўвагу на раздзяленне ў OpenVPN: канал кіравання і канал даных узгадняюцца асобна, таму набор, які вы бачыце для TLS, нічога не кажа пра шыфр, што абараняе вашу карысную нагрузку. Зводка сеансу паведамляе абодва, і чытанне толькі аднаго з двух — частая крыніца блытаніны.

У OpenVPN шыфр канала даных бярэцца са спіса data-ciphers на абодвух канцах. Калі спіс сервера і спіс кліента не перасякаюцца, злучэнне або вяртаецца да таго, што дазваляе data-ciphers-fallback, або цалкам падае, і гэтае падзенне звычайна спісваюць на няправільны ўзровень. Задайце адзін і той жа спіс з абодвух бакоў, затым пацвердзіце ўзгоднены вынік у журнале, а не мяркуйце, што парадак спіса быў выкананы.

Вырашайце з трох фактаў пра разгортванне

Па-першае, ці маюць канцавыя пункты паскарэнне AES? Калі мае кожны партнёр, AES-GCM — больш танны выбар і змаўчанне ў большасці падтрымліваемых канфігурацый. Калі значная доля — невялікія маршрутызатары або старыя тэлефоны, ChaCha20-Poly1305 не дазваляе хвасту парку стаць мяжой ёмістасці.

Па-другое, ці прапануе пратакол выбар наогул? З WireGuard рашэнне прынята за вас, і карысная праца — пераканацца, што інструменты вакол яго моўчкі не падстаўляюць нешта іншае. З OpenVPN і IPsec адказ — гэта радок канфігурацыі і ўзгоднены вынік, які трэба запісаць.

Па-трэцяе, ці могуць абодва бакі дамовіцца? Шыфр, які адзін партнёр не рэалізуе, — гэта не рашэнне пра прадукцыйнасць, а адключэнне. Таму спіс партнёраў важнейшы за любы бенчмарк: змяшанаму парку патрэбна перасячэнне магчымасцяў, а не перавага самай хуткай машыны.

Калі вы ўсё ж вымяраеце, трымайце прыладу, канцавы пункт і нагрузку аднолькавымі і змяняйце адну рэч. Тэст, які параўноўвае два серверы ў розных рэгіёнах, вымярае маршрут, а не шыфр, а бенчмарк наўтбука нічога не кажа пра хост кантэйнера, чые сцягі працэсара замаскаваныя. Параўнайце, затым запішыце, які шыфр фактычна быў узгоднены: гэты запіс каштоўнейшы за бенчмарк.

Падобныя артыкулы