LINUX.ORG.RU

yescrypt 1.1.0

 , , , ,


2

1

yescrypt — функция формирования ключа на основе пароля, основанная на scrypt.

Преимущества (по сравнению с scrypt и Argon2):

  • Улучшение устойчивости к оффлайн-атакам (за счет увеличения стоимости атаки при неизменных затратах защищающейся стороны).
  • Дополнительная функциональность (например, в виде возможности переключения на более стойкие настройки без знания пароля) из коробки.
  • Использование криптографических примитивов, одобренных NIST.
  • Остается возможность использовать SHA-256, HMAC, PBKDF2 и scrypt.

Существуют также и недостатки, подробнее описанные на странице проекта.

Со времени предыдущей новости (yescrypt 1.0.1) было несколько минорных релизов.

Изменения в релизе 1.0.2:

  • Больше не используется MAP_POPULATE, ибо в новых многопоточных тестах обнаружилось больше негативных эффектов чем позитивных.

  • В коде SIMD теперь повторно используются буферы для ввода и вывода в BlockMix_pwxform в SMix2. Это может незначительно улучшить частоту попадания в кеш и, следовательно, производительность.

Изменения в релизе 1.0.3:

  • В SMix1 оптимизирована индексация V для последовательной записи.

Изменения в релизе 1.1.0:

  • Произошло слияние yescrypt-opt.c и yescrypt-simd.c, теперь опция «-simd» более недоступна. С этим изменением производительность SIMD-сборок должна быть почти неизменной, но при этом скалярные сборки должны быть производительнее на 64-битных архитектурах (но медленнее на 32-битных) с большим количеством регистров.

Также yescrypt теперь является частью библиотеки libxcrypt, которая используется в дистрибутивах Fedora и ALT Linux.

>>> Подробности

anonymous

Проверено: shell-script ()

Ответ на: комментарий от anonymous

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

Все как всегда.

windows10 ()
Ответ на: комментарий от windows10

Хорошо. Однако, вопросы мусоров меня не волнуют. А волнуют меня нейросети при криптоанализе. Тут где-то мелькал шпионо(?)учёный по этой тематике, предлагал вступить в группу по интересам, если я правильно помню. Возможно, он и/или кто-то ещё дополнят ответ?

anonymous ()

возможности переключения на более стойкие настройки без знания пароля

А это не опасно? А то по-тихому переключат на такие стойкие настройки, что разблокировка ключа будет занимать несколько часов.

AEP ★★★★★ ()
Ответ на: комментарий от AEP

А это не опасно? А то по-тихому переключат на такие стойкие настройки, что разблокировка ключа будет занимать несколько часов.

Это относится к случаю хеширования паролей на сервере или на сервисе какой-нибудь «Интернет-компании». Переключать будет администрация этого сервера/сервиса. Они должны понимать что делают, держать резервные копии (и не забыть их затереть через какое-то время) и т.п. Также, такое переключение само займет соответствующее время на каждый аккаунт, так что будет заметно если время окажется сильно больше ожидаемого.

А выстрелить себе в ногу всё равно можно по-всякому. Это не повод, например, запретить команду «rm».

solardiz ()
Ответ на: комментарий от pon4ik

Как оно по сравнени с `gpg -c`?

Никак, но yescrypt может быть использован в качестве KDF в будущей (или патченной) версии gpg, например, с выделением ему очередного номера в "--s2k-mode", что (при настройке на то же время работы) сделает подбор passphrase более дорогим и менее вероятно успешным. И не только для режима «gpg -c», но и для фраз к секретным ключам.

Как --cipher-algo

Нет, не так.

solardiz ()
Ответ на: комментарий от segfault

Угу. Слишком много внимания этому аспекту. Захешировал через какой-нибудь sha-256 с солью и забыл. Прям взломают ваш сайт задрищенской городской администрации, сольют все пароли, закупят тёсел и будут взламывать день и ночь всех юзеров, вдруг он на свой гымыл такой же пароль поставил и удастся вытащить его секретные договоры на согласование сдачи опердени..

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 2)
Ответ на: комментарий от anonymous

scrypt лучше чем bcrypt большей ценой атак, реализованных на FPGA и ASIC. bcrypt требует мало памяти (4 KiB), scrypt требует настраиваемое количество памяти (обычно сколько-то мегабайт). См. таблицу на странице 14 в исходной статье об scrypt: http://www.tarsnap.com/scrypt.html

С другой стороны, то как именно bcrypt использует свои 4 KiB делает атаки на него, реализованные на GPU, сравнительно медленными. (Этот эффект со временем убавляется - новые GPU справляются лучше, чем старые.)

yescrypt объединяет в себе упомянутые достоинства scrypt и bcrypt, используя оба типа памяти («внешнюю» с большим размером блока и «внутреннюю» с низкой задержкой доступа к отдельным машинным словам), повышая цену атак, реализованных как на FPGA и ASIC, так и на GPU.

yescrypt умеет использовать еще и третий тип памяти, который мы называем ROM, обычно объемом в 100+ гигабайт.

Помимо этого, исходный bcrypt - это только парольный хеш, а не KDF. Намного позже (уже после scrypt) отдельно появился bcrypt-pbkdf, который существенно отличается. yescrypt же объединяет в себе функциональность парольного хеша и KDF.

Недостатком yescrypt (в том числе по сравнению с bcrypt) является сложность его конструкции, что может (более вероятно) приводить к ошибкам в дизайне и/или реализации. Из-за этого поначалу мы предлагали yescrypt для крупных внедрений (Интернет-компании с миллионами пользователей), где эта повышенная сложность является лишь небольшой частью от общей сложности сервиса аутентификации, а польза от yescrypt наиболее ощутима. Сейчас, с интеграцией в libxcrypt, это постепенно меняется - базовая функциональность yescrypt (без ROM) становится легко доступна и для применения на отдельных серверах.

solardiz ()
Ответ на: комментарий от Legioner

Обычный scrypt заполняет какое-то количество памяти (и частично считывает эти данные) за время вычисления одного хеша. Объем используемой памяти оказывается ограничен временем вычисления хеша. При типичных требованиях к производительности это может оказаться несколько мегабайт или десятков мегабайт. Для современных серверов это неоправданно мало, бОльшая часть памяти остается неиспользуемой, хотя эта память тоже могла бы работать против атакующих.

ROM заполняется один раз при запуске сервиса аутентификации, и поэтому его объем не ограничен требованиями к последующей производительности. Его использование работает против атакующих - в меньшей степени в расчете на байт чем scrypt-подобное использование, но зато его объем гораздо больше. Он помогает, в частности, против использования в атаке узлов ботнета с меньшими объемами RAM. Он также обеспечивает то что мы называем ROM port hardness против аппаратных реализаций, см. https://www.openwall.com/presentations/ZeroNights2012-New-In-Password-Hashing/ и https://www.openwall.com/presentations/BSidesLjubljana2017-Yescrypt-Large-sca... начиная со слайда 66.

Типа долго выкачивать, пока будут выкачивать, вы уже их поймаете?

Такой вариант тоже возможен, но для yescrypt не является основным. В этом варианте, ROM должен быть еще больше и должен располагаться на дисковом массиве, а частота доступов к нему должна быть ниже, чем сейчас реализовано в yescrypt. (Эксперименты с ROM на SSD у нас были в промежуточных версиях yescrypt 0.x, но в 1.0+ не вошли.)

solardiz ()
Ответ на: комментарий от anonymous

Как и всегда — смешивайте алгоритмы из разных юрисдикций.

Ты же в курсе, что американский стандарт (AES) был разработан в результате конкурса, в котором победили то ли бельгийцы, то ли голладцы, в общем - европейцы. Проверяли его тоже исследователи по всему миру. Так что эта паранойя выглядит очень необоснованной.

anonymous ()