При подготовке Методики расчета «Индекса надежности HTTPS» мы перерыли массу тематической литературы и не раз сталкивались с рекомендацией поддерживать на веб-сервере шифронаборы на основе алгоритма шифрования CHACHA20 в целях снижения нагрузки на мобильные клиенты, которые не умеют в аппаратный AES. В этом контексте обычно упоминались процессоры Mediatek и скопом «старые бюджетные мобильные процессоры».
Действительно ли CHACHA20 со своим верным спутником POLY1305 позволяют не слишком греться мобильным клиентам и стоит ли его поддерживать на веб-сервере? Давайте это обсудим!
CHACHA20 был создан известным специалистом по криптографии Дэниэлом Бернштейном, которого мы любим, в частности, за Curve25519, а также за правозащитную деятельность, благодаря которой только олдфаги помнят, что означало _EXPORT_ в имени шифронабора. Алгоритм неплохо изучен, работает в AEAD-режиме, не имеет известных слабостей и уязвимостей, и является одним из двух алгоритмов шифрования, одобренных IETF для использования в TLS 1.3 (второй – бессмертный AES).
Его теоретическая криптостойкость при использовании в TLS оценивается по-разному, в интервале между AES-128 и AES-256 в режиме GCM, что считается достаточным по сегодняшним меркам и на обозримую перспективу. При этом отмечается, что CHACHA20 «быстрее» AES, т.е. «потребляет меньше процессорных ресурсов на обеспечение того же уровня криптостойкости». Эта формулировка не только отдает душком телемаркетинга (при всем уважении к ее автору), но и упускает важную деталь: на процессорах без аппаратной поддержки AES.
И тут мы наконец возвращаемся к «бюджетным мобильным процессорам», которые перегреваются под AES, начинают троттлить и требовать жидкого азота (сарказм). Производители процессоров в курсе проблемы и решили ее добавлением соответствующего набора инструкций. В x86-совместимых процессорах это AES-NI, в других – свои названия (и свой набор). И тут мы переходим к самому интересному: поддержке AES процессорами.
Intel представил поддержку AES-NI в 2010 году в процессорах архитектуры Westmere, причем далеко не во всех: Atom, Celeron, Pentium и Core i3 она еще долго не полагалась. В поддержке AES-NI без копания в спецификациях можно быть уверенным только начиная с архитектуры Goldmont (Apollo Lake и Denverton), а это уже 2016 год.
У AMD это архитектуры Bulldozer (2011) и Jaguar (2013 год), с ARM все сложнее: поддержка AES-инструкций предусмотрена в архитектуре ARMv8-A (2011 год, первое устройство – 2013 год), но фактическое воплощение их в кремнии зависит от производителя процессора и я лично не стал бы так уверенно свистеть про «старые бюджетные мобильные процессоры», скорее стоит говорить о «не флагманских мобильных процессорах» вообще, в т.ч. выпускаемых поныне.
Проще говоря, встретить процессор без аппаратной поддержки AES не так уж и сложно. Получается, CHACHA20, действительно, отличная альтернатива AES? Давайте взглянем, например, на результаты этого исследования. На процессорах без поддержки AES CHACHA20 заметно опережает его в производительности, зачастую в разы. К сожалению, замеров температуры нам не показали, но если речь идет о серверном процессоре, очевидно, что разница в потребляемых процессорных ресурсах значима.
Ситуация меняется на прямо противоположную, когда речь заходит о процессорах с поддержкой AES. Вряд ли стоит винить в этом CHACHA20, которому никто не предложил персональный набор инструкций в процессоре, а что бывает, когда оба участника играют по одним правилам, мы видели на старых процессорах (напоминаю: AES сливает).
Так что, дружно включаем поддержку CHACHA20 на веб-серверах? Почему бы и нет, хотя бы из того соображения, что все яйца в одну корзину не кладут, и если вдруг завтра в самом AES или его реализации в конкретной криптобиблиотеке найдут дыру, мы легким движением руки сможем отключить его «до выяснения», оставшись на CHACHA20, а не судорожно искать, чем заменить AES, да как это включается.
Куда менее однозначен вопрос о месте CHACHA20 в
Давайте вспомним, как вообще происходит согласование шифронабора при установлении HTTPS-соединения: клиент передает серверу список поддерживаемых им шифронаборов, в порядке «от балды» и изменить этот порядок можно только через групповые политики Windows и только для
Приоритетность шифронаборов на сервере обычно задают исходя из принципа максимально доступной защищенности: более стойкие шифронаборы идут в списке первыми, менее – последними. Современный клиент натыкается на стойкий шифронабор и согласовывает его, «устаревший» клиент – проскакивает по списку дальше, к менее стойкому шифронабору и согласовывает его. Все довольны, всё работает, от каждого – по способностям, каждому – по HTTPS.
И тут в эту стройную картину мира влезает шифронабор на базе CHACHA20, который мы добавляем из соображений снижения нагрузки на «слабых» с аппаратной точки зрения клиентов, ничего не зная о том, являются ли они одновременно «устаревшими» или нет (т.е. флагманом этого года от третьеразрядной китайской компании или середнячком пятилетней давности от первостатейного бренда). Клиент сообщает, что поддерживает TLS 1.3 и полный комплект соответствующих шифронаборов, как на базе AES, так и на базе CHACHA20. Ваше решение, админ, какой шифронабор согласовываем клиенту? Вот и я о том же…
Резюмирую вышесказанное по поводу алгоритма шифрования CHACHA20.
- Алгоритм вполне себе хорош и годится для использования в TLS.
- Шифронаборы на его основе поддерживаются только достаточно современным браузерами, так что совсем без AES пока никуда.
- Выигрыш в производительности от его использования можно получить не только лишь на «старых бюджетных мобильных процессорах», но и на десктопах и серверах. На процессорах с аппаратной поддержкой AES, ситуация меняется на прямо противоположную.
- При установлении HTTPS-соединения не существует способа узнать, поддерживает ли процессор клиента AES на аппаратном уровне. Соответственно, нет способа узнать, какой шифронабор окажется «быстрее» в каждом конкретном случае.
