Миф про «мобильный» CHACHA20


    При подготовке Методики расчета «Индекса надежности 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 и только для Internet Explorer браузеров, использующих SChannel (поправьте, если ошибаюсь). Сервер сравнивает полученный от клиента список со списком поддерживаемых им самим шифронаборов и сообщает клиенту, какой из них он выбрал для защиты соединения. Если на сервере задан приоритет шифронаборов, согласован будет первый совпавший в обоих списках с учетом заданного на сервере приоритета. Если не задан, то админу сервера надо оторвать руки мы погружаемся в область неизведанного теории вероятностей.

    Приоритетность шифронаборов на сервере обычно задают исходя из принципа максимально доступной защищенности: более стойкие шифронаборы идут в списке первыми, менее – последними. Современный клиент натыкается на стойкий шифронабор и согласовывает его, «устаревший» клиент – проскакивает по списку дальше, к менее стойкому шифронабору и согласовывает его. Все довольны, всё работает, от каждого – по способностям, каждому – по HTTPS.

    И тут в эту стройную картину мира влезает шифронабор на базе CHACHA20, который мы добавляем из соображений снижения нагрузки на «слабых» с аппаратной точки зрения клиентов, ничего не зная о том, являются ли они одновременно «устаревшими» или нет (т.е. флагманом этого года от третьеразрядной китайской компании или середнячком пятилетней давности от первостатейного бренда). Клиент сообщает, что поддерживает TLS 1.3 и полный комплект соответствующих шифронаборов, как на базе AES, так и на базе CHACHA20. Ваше решение, админ, какой шифронабор согласовываем клиенту? Вот и я о том же…

    Резюмирую вышесказанное по поводу алгоритма шифрования CHACHA20.

    1. Алгоритм вполне себе хорош и годится для использования в TLS.
    2. Шифронаборы на его основе поддерживаются только достаточно современным браузерами, так что совсем без AES пока никуда.
    3. Выигрыш в производительности от его использования можно получить не только лишь на «старых бюджетных мобильных процессорах», но и на десктопах и серверах. На процессорах с аппаратной поддержкой AES, ситуация меняется на прямо противоположную.
    4. При установлении HTTPS-соединения не существует способа узнать, поддерживает ли процессор клиента AES на аппаратном уровне. Соответственно, нет способа узнать, какой шифронабор окажется «быстрее» в каждом конкретном случае.

    Комментарии 20

      +2
      Много текста из которого следует:
      «процессоры без аппаратной поддержки AES есть»
      «прирост производительности при использовании CHACHA20 на процессорах где нет аппаратной поддержки AES есть»
      «нет инструментария для определения наличия аппаратной поддержки AES клиентом»
      Без цифр и минимальной статистики статья не несет полезной практической нагрузки. Пока я прихожу к выводу, что CHACHA20 мне не сильно нужна. На какой процент потенциальных клиентских устройств я положил таким решением?
        +1
        1. Это не новость, но вопреки утверждению, встречающегося в «популярной литературе», проблема затрагивает значительно более широкий спектр процессоров, в т.ч. серверных.
        2. Это не прирост производительности, а скорее меньшее ее падение.
        3.… на этапе согласования параметров TLS. Дальше можно с помощью JS исхитриться и определить.
        4. А вот тут нет универсального ответа, каждый решает для своих условий. И в расчет еще надо принять процессор, на котором крутится сервер, и выделено ли серверу физическое ядро процессора, т.к. в виртуалке AES-NI не работает.
          0
          в виртуалке AES-NI не работает

          Если QEMU — точно работает (если поддерживается на хосте), как минимум может работать если не запрещен, ядро выделять не надо.


          А вот насчёт "преимущества" ускоренного аппаратно AES — очень сомневаюсь. Только что проверил на Ryzen 5 3600X (с ускорением):


          type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
          aes-256-cbc     794215.77k  1057164.50k  1152047.87k  1182695.00k  1187192.83k  1187823.62k

          Около 1 GB/s (без ускорения около 220 MB/s), но в то же время chacha20-poly1305:


          type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
          chacha20-poly1305   291629.58k   628555.61k  1290161.24k  2275046.14k  2345852.93k  2350077.27k

          Больше 2 GB/s — разница в два раза, это очень ощутимо. На Intel i7-6700 почти то же самое (только AES чуть меньше 1 GB/s аппаратный).

            0
            1. Чуял мой хвост, что недокурил я доки — ну не могли не реализовать проброс в виртуалку. Спасибо за поправку!
            2. Т.е. по Intel i7-6700 у Вас результаты не совпадают с calomel.org на тех же наборах в том же режиме и с теми же библиотеками тех же версий?
              +1

              Почему не совпадают? Там разница около 7%, и это действительно может зависеть от версии OpenSSL — у меня стандартный, не libressl.


              Правда я по привычке протестировал только CBC, на GCM действительно преимущество в 2 с чем-то раза — т.е. аппаратный AES-256-GCM существенно быстрее чем ChaCha20-Poly1305.


              Впрочем, результаты ChaCha20 всё равно впечатляют, особенно на RPi 4B (240 MB/s — почти в 5 раз быстрее AES — но там нет акселлератора).

                0
                Там вообще странное: на разных процессорах преимущество одного алгоритма над другим может различаться в разы. Например:
                Intel P4 3Ghz Will 109 26
                Intel ATOM D525 98 51
                и как это объяснить?
                0
                Также ваша ошибка в том, что вы не совсем осознаете размер и сложность, и насколько легко допустить ошибку.
                Например, sha256 вы вообще не упомянули, но он используется много раз, как дайджест и внутри сертификатов. Дак вот в android chrome была ошибка, которая портила его скорость очень сильно.
                А в TLS 1.3 там уже RSA-PSS, что вообще…
                  0
                  Не могли бы Вы пояснить, какое отношение SHA256 имеет к толерантности алгоритмов шифрования к базовому набору x86 инструкций?
                0

                Обычно сравнивают с AES-CTR/AES-GCM, которые лучше оптимизируются.

                0
                1. Предлагаю исходить из того, что оборудование работает 3-5 лет в рамках гарантии и еще 3-5 по сервисному контракту, после чего отправляться в помойку. (так живет цивилизованный мир и к этому нужно по меньшей мере стремиться. причины экономические, с определенного момента стоимость рисков выхода системы из строя существенно выше стоимости железа). Итого, заявленный спектр резко сократился. Открою страшную тайну, любое бизнес-приложение (сайты к ним относятся) нацелено на платежеспособную аудиторию и если 1-3% низкопроизводительных клиентских устройств (== едва-ли платежеспособных клиентов) будут иметь проблемы производительности проблема едва ли будет восприниматься как таковая. Риски безопасности, связанные с включением новых чиперов (за математику шифрования переживать особо не приходится, проблема скорее в дополнительном коде в исполнении, который потенциально расширяет пул ошибок в продакте), а так же расходы и риски внесения изменений конфигурации оборудования как правило выше, чем вероятные убытки от того, что на древнем телефоне что-то будет притормаживать, при условии, что владелец к этому скорее всего уже привык.
                2. смотря что считать точкой отсчета.
                3. все верно, сначала мы plain-text кидаем скрипты, а потом уже устанавливаем соединение с согласованием чиперов. (Это был сарказм, если что.)
                4. ныне виртуализация в продакте скорее стандарт, чем что-то связанное с вероятностями. На домашнем компе для развлечения скорее все иначе, но я склонен обсуждать именно боевые системы. Сюда же, накладные расходы на шифрование контента с любым шифрованием в продакте — стат.погрешность, или откровенная криворукость. Вычислительные ресурсы нужны для производства полезных вычислений, а не для обслуживания сопутствующих процессов. Если вопрос и поднимать, то только о конечном устройстве пользователя, но тут возвращаемся к п.1.
                  0
                  1. Это бизнес-подход, а HTTPS используется не только в бизнесе ;) Скажем, те же госсайты, у которых (по идее) другая задача: быть доступными всем, даже той бабке с «дисковым смартфоном».
                  4. То же самое замечание. Вы исходите из того, как должно быть в некоем идеальном случае, когда плательщик знает, зачем он платит за сервер и за его обслуживание, а админ знает, что за недобросовестную работу отправится на паперть. Возвращаемся в реальную жизнь все к тем же госсайтам, где в большинстве случаев не могут даже порядок шифронаборов грамотно выстроить, а то и вообще задать его. Грамотно в данном контексте — чтобы была видна хоть какая-то логика, пусть даже и чуждая наблюдателю, но не ее полное отсутствие.
              0
              .
                0

                Года 4 назад в моём ведении был раздатчик видео, самописанный на Go с помощью стандартного net/http. (И да, для раздачи видео он был лучше, чем nginx). Я не помню, как я составлял список из алгоритмов TLS, но помню точно, что в профиле CPU и AES и ChaCha20 занимали примерно равное время. Т.е. браузеры явно сами могут разобраться, какой алгоритм им нужен.

                  0
                  Как Вы себе это представляете? В самом TLS не предусмотрен механизм, который позволяет клиенту выбирать шифронабор. Разве что пользователь руками отключит все шифронаборы, кроме одного любимого, который и будет вынужден согласовать сервер, если поддерживает его. Зайдите сюда, например, www.howsmyssl.com и увидите все шифронаборы, которые готов использовать Ваш браузер, хотя по Вашей версии там должны быть только на основе AES или только CHACHA20.
                    0
                    Я себе это вообще ни как не представляю. Я говорю только о том, что видел своими глазами, и только то, что уже сказал.

                    У меня, оказывается, затесался исходник, и в нём видно, что различные варианты с AES-GCM я в списке выставил первыми (правда, AES-CBC уже после CHACHA20). Уж не знаю, как клиент убеждал сервер, что ему нужен именно CHACHA20, но факт остаётся фактом.

                    И давайте не забывать, что я говорю про наблюдение четырёх-пяти-летней давности, а тогда в большинстве мобильных процессоров нативных AES инструкций ещё не было. Возможно, мобильные браузеры (особенно Chrome) каким-то образом форсировали ChaCha20 при его поддержки. Например, браузер вполне мог в первый раз присылать список, содержащий только ChaCha20, и только если сервер отказывался работать в таких нечеловеческих условиях, тогда второй раз присылать уже AES.
                      0
                      Сценарий рабочий, тем более что Гугл активно форсил CHACHA20, но думаю, его бы быстро спалили за такие фокусы. А у Вас случаем не один AES-256 до CHACHA20 стоял?
                        0

                        У меня стояло 4 AES-GCM варианта: по два на 128 и 256. Потом ChaCha, потом AES-CBC.

                          0
                          Хм, тогда действительно интересно, как до CHACHA20 дело доходило…
                  0

                  Если заводить разговор про скорость, то ChaCha12, надёжности которого все ещё с головой (и security margin все ещё больше, чем у AES) до последних поколений процов равнялся AES-NI. Сейчас, вроде, AES-NI ещё ускорился, и обошёл.


                  А вообще, интересно, когда начнут адоптить победителей CAESAR? MORUS без AES инструкций быстрее AES-GCM, а AEGiS с AES-NI развивает вообще фантастическую скорость.

                    0
                    А если с chacha8 сравнить? Он тоже надежный (используют «топовые» рансомварщики).

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое