AES-GCM ці ChaCha20-Poly1305: выбар шыфра для даных VPN
AES-GCM — відавочны выбар на серверах з апаратным паскарэннем, а ChaCha20-Poly1305 добра працуе без яго. Магчыма, пратакол вырашыць за вас.
Абодва назвы — гэта канструкцыі 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 каштуе вымернага часу працэсара на кожны гігабіт. Ні адна канструкцыя не з'яўляецца слабасцю; пытанне ў тым, якую ваша абсталяванне выконвае танна.
Што ваш пратакол фактычна дазваляе выбраць
| Protocol | What you get |
|---|---|
| WireGuard | ChaCha20-Poly1305 only; no negotiation |
| OpenVPN 2.5 and later | Data channel negotiated from data-ciphers: AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 |
| IPsec / IKEv2 | AES-GCM as a combined-mode transform, or ChaCha20-Poly1305 where both peers implement it |
| OpenVPN control channel | TLS 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 адказ — гэта радок канфігурацыі і ўзгоднены вынік, які трэба запісаць.
Па-трэцяе, ці могуць абодва бакі дамовіцца? Шыфр, які адзін партнёр не рэалізуе, — гэта не рашэнне пра прадукцыйнасць, а адключэнне. Таму спіс партнёраў важнейшы за любы бенчмарк: змяшанаму парку патрэбна перасячэнне магчымасцяў, а не перавага самай хуткай машыны.
Калі вы ўсё ж вымяраеце, трымайце прыладу, канцавы пункт і нагрузку аднолькавымі і змяняйце адну рэч. Тэст, які параўноўвае два серверы ў розных рэгіёнах, вымярае маршрут, а не шыфр, а бенчмарк наўтбука нічога не кажа пра хост кантэйнера, чые сцягі працэсара замаскаваныя. Параўнайце, затым запішыце, які шыфр фактычна быў узгоднены: гэты запіс каштоўнейшы за бенчмарк.