chacha20 poly1305 что это

Русские Блоги

Оптимизация https должна понимать алгоритм ChaCha20-Poly1305

Несколько дней назад я увидел статью об оптимизации HTTPS, опубликованную неким официальным аккаунтом. Когда я вошел и посмотрел на него, все это были неправильные взгляды, и я чувствовал себя очень плохо.

Основываясь на этих двух вопросах, я расскажу о двух концепциях, упомянутых в этой статье (алгоритм ChaCha20-Poly1305 и группа эквивалентных алгоритмов шифрования соответственно). Я объясню их в двух статьях. Надеюсь, у вас появится больше мыслей. Эта статья в основном объясняет все аспекты алгоритма ChaCha20-Poly1305.

Одна картинка стоит тысячи слов:

В протоколе HTTPS (в протоколе TLS) криптографическая библиотека (OpenSSL, NSS) включает в себя два алгоритма шифрования данных, а именно алгоритм симметричного шифрования и алгоритм MAC. Чтобы обеспечить конфиденциальность и целостность, эти два алгоритма Алгоритмы должны существовать одновременно.

Для криптографических библиотек (таких как OpenSSL), если он используется для обработки алгоритмов симметричного шифрования и алгоритмов MAC, иногда могут возникать проблемы безопасности, и итерации CBC будут сталкиваться с атаками заполнения, что означаетТрадиционный режим шифрованияСуществует угроза безопасности.

В это время появился режим шифрования AEAD, который обрабатывал шифрование и операции MAC внутри, без необходимости в криптографических библиотеках (таких как OpenSSL), и был более безопасным. ChaCha20-Poly1305 также принял режим шифрования AEAD.

С точки зрения только алгоритма шифрования, он разделен на алгоритм блочного шифрования и алгоритм шифрования потокового шифра. RC4 является алгоритмом шифрования потокового шифра, но из-за проблем безопасности он в основном не используется в HTTPS. Более популярным алгоритмом блочного шифрования является AES. Алгоритм, а ChaCha20-Poly1305 является алгоритмом потокового шифрования.

Теперь мы понимаем расположение алгоритма ChaCha20-Poly1305. В целом, если вы хотите узнать больше об AEAD, вы можете обратиться к написанной мной книге «Введение в HTTPS: от принципов к практике». Каковы его преимущества по сравнению с AES-GCM? Почему это появляется?

производительность

Для алгоритмов блочного шифрования, таких как AES, он работает очень быстро на некотором оборудовании, например, на современных серверах и настольных компьютерах есть инструкции по ускорению AES-NI. И если нет инструкции по ускорению, производительность очень низкая, если она работает исключительно через программное обеспечение.

Алгоритм потокового шифра является обратным, и производительность реализации программного обеспечения выше. Большинство мобильных устройств (таких как мобильные телефоны) не поддерживают AES-NI, поэтому шифрование AES выполняется очень медленно. Запуск алгоритмов потокового шифрования, таких как RC4, относительно быстр, но, к сожалению, RC4 уже давно доказал свою безопасность.

В настоящее время здесь используется алгоритм потокового шифра ChaCha20-Poly1305. Помимо обеспечения безопасности, он работает на мобильных устройствах с более высокой производительностью. Многие считают, что на мобильных устройствах (без инструкций AES-NI) производительность алгоритма ChaCha20-Poly1305 в три раза выше, чем у AES-128-GCM, и, конечно, на настольных компьютерах и серверах производительность AES-128-GCM лучше, чем у ChaCha20- Поли1305 выше.

Адам Лэнгли в2014Тест производительности проводился каждый год, см. Следующую таблицу:

Chip	Скорость AES-128-GCM	Скорость ChaCha20-Poly1305
OMAP 4460	24.1 MB/s	75.3 MB/s
Snapdragon S4 Pro	41.5 MB/s	130.9 MB/s
Sandy Bridge Xeon (AESNI)	900 MB/s	500 MB/s

история

Алгоритм ChaCha20-Poly1305 был предложен Google в 2013 году. Алгоритм был включен в Chrome 31 в ноябре, а Chrome на всех устройствах IOS и Android также был включен в апреле 2014 года. Библиотека паролей firfox использует NSS, а версия NSS 3.23 поддерживает ChaCha20 / Poly1305.

CloudFlare также поддерживал алгоритм ChaCha20 / Poly1305 в феврале 2015 года, и было проверено, что 10% трафика используют этот алгоритм.

Тем не менее, будь то Google или CloudFlare, алгоритм ChaCha20 / Poly1305, который они реализовали, не является окончательной версией. Начиная с 2015 года IETF стандартизировал этот алгоритм и прошел через несколько проектов (https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-05окончательно доработан в июне 2016 года (https://tools.ietf.org/html/rfc7905）。

Как самая популярная криптографическая библиотека и библиотека TLS в мире, OpenSSL поддерживает алгоритм ChaCha20-Poly1305, начиная с 1.1.0 (август 2016 г.). Если вы используете более старую версию OpenSSL, вы можете использовать патч, разработанный CloudFlare (https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__1.1.0_chacha20_poly1305.patch）

Поддержка Nginx

Источник

Curve25519, EdDSA и Poly1305: Три обделенных вниманием криптопримитива

Curve25519

Это эллиптическая кривая и набор параметров к ней подобранных таким образом, чтобы обеспечить более высокое быстродействие (в среднем, 20-25%) и избавиться от некоторых проблем с безопасностью у традиционного ECDH.

Кривая используется y 2 = x 3 + 486662x 2 + x. Это — кривая Монтгомери над полем вычетов по модулю простого числа 2 255 − 19 (что и дало название схеме) и с базовой точкой x=9. Схема использует точки в сжатой форме (только X координаты), позволяя таким образом использовать «Лестницу Монтгомери», которая делает умножение точек за фиксированное время, избавляя нас от Timing attacks.

Curve25519 используется как обмен ключами по умолчанию в OpenSSH, I2p, Tor, Tox и даже в IOS.

Чем эта схема так хороша с точки зрения программиста?

Она очень простая и быстрая. Чтобы сгенерировать новую ключевую пару, мы подаем на вход схеме любые 32 случайных байта, которые будут закрытым ключом. Из них мы получаем 32 байта открытого ключа. Затем как обычно, обмениваемся открытыми ключами и считаем общий. Насколько именно она быстрее классического ECDH с 256битными кривыми сказать не возьмусь, зависит от реализации. Мне она нравится за устойчивость к timing attacks и за возможность использовать любые 32байтные массивы в качестве закрытых ключей.

EdDSA

Точнее, ее частный случай, Ed25519, как можно догадаться, тоже убыстренный и усиленный вариант цифровой подписи на эллиптических кривых. Используется схема Шнорра для «Скрученной кривой» Эдвардса, изобретенной, кстати, тем же Даниэлем Бернштайном в 2007 году.

Испольуется такая вот кривая:

которая эквивалентна кривой для Curve25519

EdDSA используется, например, в OpenBSD signify tool, чтобы подписывать образы

И так, Curve25519 и Ed25519 — примитивы на эллиптических кривых, оптимизированные по быстродействию и написанные таким образом, чтобы минимизировать или вовсе исключить влияние входных данных на процесс расчета ключей\подписей.

Poly1305

Это MAC (Message authentication code), работающий совместно с AES или любым другим шифром по вашему желанию. Он считает 16 байтный (128 бит) MAC, используя 256 битный ключ AES, который разделяется на два по 128 бит (k,r) и соль (nonce).
Он разбивает сообщение на блоки по 16 байт и работает с ними как с коэффициентами полинома в r по модулю простого числа 2 130 −5

Результат получается на 4 байта меньше, чем обычный HMAC-SHA1, не имеет проблем с безопасностью и работает быстрее.

Именно поэтому его вместе с потоковым шифром ChaCha20 использует Google вместо RC4, а так же он включен в OpenSSH, которому теперь не нужно зависеть от OpenSSL

Референсная реализация всего этого в библиотеке NaCl на C, но есть порты на java и c#, например.

Надеюсь, после этой статьи у вас появится желание узнать об этих примитивах побольше и использовать их в ваших приложениях.

Источник

Миф про «мобильный» 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.

Источник

Cha Cha20Poly1305 Класс

Определение

Некоторые сведения относятся к предварительной версии продукта, в которую до выпуска могут быть внесены существенные изменения. Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, относительно приведенных здесь сведений.

Представляет симметричный ключ для использования с шифром потока ChaCha20 в комбинированном режиме с помощью средства проверки подлинности Poly1305.

Конструкторы

Инициализирует новый экземпляр класса ChaCha20Poly1305 с указанным ключом.

Свойства

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

Методы

Расшифровывает зашифрованный текст в предоставленный буфер назначения, если можно проверить тег проверки подлинности.

Выполняет определяемые приложением задачи, связанные с удалением, высвобождением или сбросом неуправляемых ресурсов.

Шифрует открытый текст в буфер назначения зашифрованного текста и создает тег проверки подлинности в отдельном буфере.

Определяет, равен ли указанный объект текущему объекту.

Служит хэш-функцией по умолчанию.

Возвращает объект Type для текущего экземпляра.

Создает неполную копию текущего объекта Object.

Возвращает строку, представляющую текущий объект.

Источник

Опубликованы RFC для HTTP/2 и ChaCha20/Poly1305

Точность

Выборочно проверено

Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, завершил формирование RFC для протокола HTTP/2.0 и опубликовал связанную с ним спецификацию, как RFC 7540. RFC получил статус «Предложенного стандарта», после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний.

В основу HTTP/2.0 положен протокол SPDY, разработанный компанией Google и позволяющий ускорить загрузку сайтов на 15-50%. HTTP/2.0 решает задачи повышения эффективности использования сетевых ресурсов и снижения задержек при соединении и обмене данными между клиентом и сервером, в условиях изменившихся современных реалий, при которых для загрузки сайта требуется отправить множество отдельных запросов (в среднем около 100), связанных с получением CSS, файлов JavaScript и картинок. Протокол HTTP/1.1, в силу блокировок при конвейерной передаче данных и высоких накладных расходов на отдачу ресурсов небольшого размера, не может обеспечить должную эффективность и вынуждает устанавливать несколько одновременных TCP-соединений к серверу.

Дополнительно можно обратить внимание на публикацию RFC 7539, стандартизующий потоковый шифр ChaCha20 и алгоритм аутентификации сообщений (MAC) Poly1305, разработанные Дэниелом Бернштейном ( Daniel J. Bernstein), Таней Ланге (Tanja Lange) и Питером Швабе (Peter Schwabe). ChaCha20 и Poly1305 можно рассматривать, как более быстрые и безопасные аналоги AES-256-CTR и HMAC, программная реализация которых позволяет добиться фиксированного времени выполнения без задействования специальной аппаратной поддержки. В настоящее время данные алгоритмы включены в состав OpenSSH и составляют встроенный набор шифров, используемых при сборке без OpenSSL.

Источники [ править ]

Комментарии [ править ]

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

Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.

Несколько советов по оформлению реплик:

). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.

Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.

Источник