AES-GCM или ChaCha20-Poly1305: избор на шифра за податоци на VPN

Двете имиња се 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 чини мерлив процесор по гигабит. Ниту една конструкција не е слабост; прашањето е која вашиот хардвер ја извршува евтино.

Што всушност вашиот протокол ви дозволува да изберете

Обрнете внимание на поделбата во OpenVPN: контролниот канал и каналот за податоци се договараат одделно, па множеството што го гледате за TLS не кажува ништо за шифрата што го штити вашиот товар. Резимето на сесијата известува за двете, а читањето само на едното од двете е чест извор на забуна.

Во OpenVPN шифрата на каналот за податоци доаѓа од списокот data-ciphers на двата краја. Ако списокот на серверот и списокот на клиентот не се сечат, врската или се враќа на она што го дозволува data-ciphers-fallback или целосно паѓа, а тој неуспех обично се препишува на погрешниот слој. Поставете го истиот список на двете страни, потоа потврдете го договорениот резултат во дневникот наместо да претпоставите дека редоследот на списокот е почитуван.

Одлучете врз основа на три факти за распоредувањето

Прво, имаат ли крајните точки AES забрзување? Ако има секој партнер, AES-GCM е поевтиниот избор и стандардната поставка во повеќето одржувани конфигурации. Ако значителен дел се мали рутери или постари телефони, ChaCha20-Poly1305 спречува опашката на флотата да стане граница на капацитетот.

Второ, дали протоколот воопшто нуди избор? Со WireGuard одлуката е донесена наместо вас, а корисната работа е да проверите дека алатките околу него тивко не заменуваат нешто друго. Со OpenVPN и IPsec одговорот е линија во конфигурацијата и договорен резултат што треба да се запише.

Трето, можат ли двете страни да се договорат? Шифра што еден партнер не ја имплементира не е одлука за перформанси, туку прекин. Затоа списокот на партнери е поважен од секое мерење: мешаната флота бара пресек на можностите, а не преференцата на најбрзата машина.

Ако мерите, држете ги уредот, крајната точка и оптоварувањето исти и сменете една работа. Тест што споредува два сервера во различни региони ја мери рутата, не шифрата, а мерењето на преносен компјутер не кажува ништо за домаќин на контејнери чиишто процесорски знаменца се маскирани. Споредете, потоа запишете која шифра навистина е договорена: тој запис вреди повеќе од мерењето.