Чаму большы лік ключа не робіць VPN бяспечнейшым

Рэклама кажа 256 біт, іншы прадукт кажа 128 біт, і выснова здаецца відавочнай, пакуль не заўважыш, што лікі апісваюць розныя рэчы. Ключ сіметрычнага шыфра, адкрыты ключ сертыфіката і параметр абмену ключамі не вымяраюцца адной шкалой. Ні адзін з іх не ахоплівае тое, ці правяраў кліент сервер наогул. Лік — гэта рэальная інфармацыя, і яна значна вузейшая, чым мяркуе маркетынг вакол яе.

Спытайцеся, які ключ лічыцца і што ён абараняе, перш чым нешта параўноўваць.

Тры ключы з трыма задачамі

Шыфр даных шыфруе карысную нагрузку тунеля, і яго ключ выводзіцца нанова для сесіі. Адкрыты ключ сертыфіката даказвае ідэнтычнасць канчатковага пункта падчас аўтэнтыфікацыі. Этап абмену ключамі, звычайна эфемерны варыянт Diffie-Hellman, стварае агульны сакрэт, які ні адзін бок не можа аднавіць пазней. Кожны мае свае дапушчэнні трываласці і свае ўмовы памеру.

Вось чаму 256 побач з 2048 побач з 32 нельга ранжыраваць па велічыні; яны — адказы на розныя пытанні.

Нават у межах адной ролі лік кажа нешта толькі адносна сямейства алгарытмаў, якое выкарыстоўваецца.

Дзе лік дапамагае, а дзе спыняецца

У межах аднаго алгарытму большы ключ падвышае кошт пошуку пераборам, і апублікаваныя рэкамендацыі ўсталёўваюць мінімумы для ключоў сертыфікатаў па меры змены вылічальнай магутнасці. Гэта слушнае і вузкае параўнанне: AES-128 і AES-256 абодва супрацьстаяць прамой атацы з вялікім запасам, таму розніца рэдка бывае вырашальным фактарам на практыцы.

Па-за гэтым параўнаннем лік нічога не прадказвае пра памылкі канфігурацыі, праверку сертыфікатаў або версію пратаколу.

Чытайце ўвесь узгоднены набор

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

openvpn --show-ciphers | head -20
openvpn --show-tls | head -20
openssl x509 -in server.crt -noout -text | grep -E 'Public-Key|Signature Algorithm'
wg show

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

Часткі, якіх лік ніколі не вымярае

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

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