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 отговорът е ред в конфигурацията и договорен резултат, който да се запише.

Трето, могат ли двете страни да се съгласят? Шифър, който един партньор не реализира, не е решение за производителност, а прекъсване. Затова списъкът с партньори е по-важен от всеки бенчмарк: смесеният парк се нуждае от пресичане на възможностите, а не от предпочитанието на най-бързата машина.

Ако все пак мерите, дръжте устройството, крайната точка и натоварването еднакви и променяйте едно нещо. Тест, който сравнява два сървъра в различни региони, измерва маршрута, не шифъра, а бенчмарк на лаптоп не казва нищо за хост за контейнери, чиито процесорни флагове са маскирани. Сравнете, после запишете кой шифър всъщност е договорен: този запис е по-ценен от бенчмарка.