Комментарии 22
«процессоры без аппаратной поддержки AES есть»
«прирост производительности при использовании CHACHA20 на процессорах где нет аппаратной поддержки AES есть»
«нет инструментария для определения наличия аппаратной поддержки AES клиентом»
Без цифр и минимальной статистики статья не несет полезной практической нагрузки. Пока я прихожу к выводу, что CHACHA20 мне не сильно нужна. На какой процент потенциальных клиентских устройств я положил таким решением?
2. Это не прирост производительности, а скорее меньшее ее падение.
3.… на этапе согласования параметров TLS. Дальше можно с помощью JS исхитриться и определить.
4. А вот тут нет универсального ответа, каждый решает для своих условий. И в расчет еще надо принять процессор, на котором крутится сервер, и выделено ли серверу физическое ядро процессора, т.к. в виртуалке AES-NI не работает.
в виртуалке 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 аппаратный).
2. Т.е. по Intel i7-6700 у Вас результаты не совпадают с calomel.org на тех же наборах в том же режиме и с теми же библиотеками тех же версий?
Почему не совпадают? Там разница около 7%, и это действительно может зависеть от версии OpenSSL — у меня стандартный, не libressl.
Правда я по привычке протестировал только CBC, на GCM действительно преимущество в 2 с чем-то раза — т.е. аппаратный AES-256-GCM существенно быстрее чем ChaCha20-Poly1305.
Впрочем, результаты ChaCha20 всё равно впечатляют, особенно на RPi 4B (240 MB/s — почти в 5 раз быстрее AES — но там нет акселлератора).
Например, sha256 вы вообще не упомянули, но он используется много раз, как дайджест и внутри сертификатов. Дак вот в android chrome была ошибка, которая портила его скорость очень сильно.
А в TLS 1.3 там уже RSA-PSS, что вообще…
Обычно сравнивают с AES-CTR/AES-GCM, которые лучше оптимизируются.
2. смотря что считать точкой отсчета.
3. все верно, сначала мы plain-text кидаем скрипты, а потом уже устанавливаем соединение с согласованием чиперов. (Это был сарказм, если что.)
4. ныне виртуализация в продакте скорее стандарт, чем что-то связанное с вероятностями. На домашнем компе для развлечения скорее все иначе, но я склонен обсуждать именно боевые системы. Сюда же, накладные расходы на шифрование контента с любым шифрованием в продакте — стат.погрешность, или откровенная криворукость. Вычислительные ресурсы нужны для производства полезных вычислений, а не для обслуживания сопутствующих процессов. Если вопрос и поднимать, то только о конечном устройстве пользователя, но тут возвращаемся к п.1.
4. То же самое замечание. Вы исходите из того, как должно быть в некоем идеальном случае, когда плательщик знает, зачем он платит за сервер и за его обслуживание, а админ знает, что за недобросовестную работу отправится на паперть. Возвращаемся в реальную жизнь все к тем же госсайтам, где в большинстве случаев не могут даже порядок шифронаборов грамотно выстроить, а то и вообще задать его. Грамотно в данном контексте — чтобы была видна хоть какая-то логика, пусть даже и чуждая наблюдателю, но не ее полное отсутствие.
Года 4 назад в моём ведении был раздатчик видео, самописанный на Go с помощью стандартного net/http. (И да, для раздачи видео он был лучше, чем nginx). Я не помню, как я составлял список из алгоритмов TLS, но помню точно, что в профиле CPU и AES и ChaCha20 занимали примерно равное время. Т.е. браузеры явно сами могут разобраться, какой алгоритм им нужен.
У меня, оказывается, затесался исходник, и в нём видно, что различные варианты с AES-GCM я в списке выставил первыми (правда, AES-CBC уже после CHACHA20). Уж не знаю, как клиент убеждал сервер, что ему нужен именно CHACHA20, но факт остаётся фактом.
И давайте не забывать, что я говорю про наблюдение четырёх-пяти-летней давности, а тогда в большинстве мобильных процессоров нативных AES инструкций ещё не было. Возможно, мобильные браузеры (особенно Chrome) каким-то образом форсировали ChaCha20 при его поддержки. Например, браузер вполне мог в первый раз присылать список, содержащий только ChaCha20, и только если сервер отказывался работать в таких нечеловеческих условиях, тогда второй раз присылать уже AES.
Сервер определяет набор шифров только с директивой ssl_prefer_server_ciphers или подобной. По умолчанию клиент может предложить шифр и сервер его примет, если поддерживает.
Для устройств без AES-NI во многих реализациях давно сделан приоритет на то, что они сами предлагают ChaCha20-Poly1305 в первую очередь.
Поэтому на сайте с конфигами от Mozilla указано давно в рекомендуемой конфигурации nginx следующее:
ssl_prefer_server_ciphers off;
Если заводить разговор про скорость, то ChaCha12, надёжности которого все ещё с головой (и security margin все ещё больше, чем у AES) до последних поколений процов равнялся AES-NI. Сейчас, вроде, AES-NI ещё ускорился, и обошёл.
А вообще, интересно, когда начнут адоптить победителей CAESAR? MORUS без AES инструкций быстрее AES-GCM, а AEGiS с AES-NI развивает вообще фантастическую скорость.
Миф про «мобильный» CHACHA20