[Информационная безопасность] Миф про «мобильный» CHACHA20
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
При подготовке Методики расчета «Индекса надежности 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.
- Алгоритм вполне себе хорош и годится для использования в TLS.
- Шифронаборы на его основе поддерживаются только достаточно современным браузерами, так что совсем без AES пока никуда.
- Выигрыш в производительности от его использования можно получить не только лишь на «старых бюджетных мобильных процессорах», но и на десктопах и серверах. На процессорах с аппаратной поддержкой AES, ситуация меняется на прямо противоположную.
- При установлении HTTPS-соединения не существует способа узнать, поддерживает ли процессор клиента AES на аппаратном уровне. Соответственно, нет способа узнать, какой шифронабор окажется «быстрее» в каждом конкретном случае.
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность] Мошенники начали использовать боты Telegram для поиска персональных данных россиян с целью их шантажа
- [Информационная безопасность] Обнаружены эксплоиты для Linux и Windows с использованием техники Spectre
- [Информационная безопасность] Угрозы информационной безопасности в эпоху цифровой трансформации
- [Информационная безопасность, Cisco, Сетевые технологии, Беспроводные технологии, Сетевое оборудование] Как я прошел обучение в учебном центре «Специалист» при МГТУ им.Н.Э.Баумана по курсу CCNA Безопасность в сетях Cisco
- [Информационная безопасность] Security Week 09: инфосек-драма вокруг Nurserycam
- [Информационная безопасность, Интернет-маркетинг, Законодательство в IT, Патентование, Копирайт] Парсинг общедоступных данных запрещен с 1 марта
- [Информационная безопасность, Разработка веб-сайтов, Google Chrome, Браузеры] Разработчики Chrome внедряют принудительное открытие сайтов через HTTPS
- [Информационная безопасность, Контекстная реклама, Управление продажами] ИБ-исследователь раскритиковал LastPass за 7 встроенных трекеров для Android
- [Информационная безопасность] Особенности подготовки и прохождения международных аудитов безопасности
- [Информационная безопасность, Серверное администрирование] В даркнете продают базу данных 21 млн пользователей популярных VPN-сервисов
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_https, #_aes, #_chacha20, #_tls, #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:10
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 При подготовке Методики расчета «Индекса надежности 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.
=========== Источник: habr.com =========== Похожие новости:
Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:10
Часовой пояс: UTC + 5