LINUX.ORG.RU

John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA

 , , , ,


0

3

Выпущена новая версия старейшей поддерживаемой программы для подбора паролей John the Ripper 1.9.0-jumbo-1 (проект развивается с 1996 года). На странице проекта доступны для скачивания исходники, а также готовые сборки под Windows.

Отмечается, что с выхода версии 1.8.0-jumbo-1 прошло 4.5 года, за которые было внесено более 6000 изменений (git commits) от более 80 разработчиков. В течение этого срока разработчики рекомендовали использовать текущую редакцию с GitHub, состояние которой поддерживалось стабильным несмотря на вносимые изменения благодаря непрерывной интеграции, включающей предварительную проверку каждого изменения (pull request) на многих платформах. Особенностью новой версии является появление поддержки FPGA (ПЛИС) в дополнение к CPU, GPU и Xeon Phi.

Для плат ZTEX 1.15y, включающих по 4 микросхемы FPGA и исходно использовавшихся в основном для майнинга Bitcoin, теперь реализованы 7 типов хешей паролей: bcrypt, классический descrypt (включая bigcrypt), sha512crypt, sha256crypt, md5crypt (включая Apache apr1 и AIX smd5), Drupal7 и phpass (используется, в частности, в WordPress). Некоторые из них реализованы на FPGA впервые. Для bcrypt, достигнутая производительность в ~119k c/s при 2^5 итераций («$2b$05») с потребляемой мощностью около 27 ватт существенно превосходит результаты для новейших GPU в расчете на плату, на цену оборудования и на ватт. Также поддерживаются кластеры из плат этого типа, что проверено вплоть до 16 плат (64 FPGA), контролируемых с одного Raspberry Pi 2. Поддерживается обычная функциональность John the Ripper, включая все режимы подбора паролей и одновременную загрузку большого количества хешей. Для ускорения работы реализовано применение маски (режим "--mask", в том числе в комбинации с другими режимами) и сравнение вычисленных хешей с загруженными на стороне FPGA. С точки зрения реализации, во многих из дизайнов (например, для sha512crypt и Drupal7) применены блоки состоящие из многопоточных процессорных ядер (soft CPU cores), взаимодействующих с криптографическими ядрами. Разработку этой функциональности вел Денис Бурыкин в координации с другими разработчиками jumbo.

Другие важнейшие изменения:

  • Поддержка большого количества дополнительных типов хешей, шифров и т.п., включая как классические хеши паролей (например, от новых версий QNX), так и кошельки криптовалют, шифрованные архивы и шифрованные файловые системы (например, Bitlocker и FreeBSD geli), а также поддержку новых разновидностей форматов, поддерживаемых ранее (например, добавлена поддержка bcrypt-pbkdf для OpenBSD softraid) и многое другое. В общей сложности, добавлено 80 форматов на CPU и 47 на OpenCL (и небольшое количество старых удалено как интегрированные в новые и устаревшие). Общее количество форматов теперь 407 на CPU (или 262 не включая «dynamic» форматы, настраиваемые из файлов конфигурации) и 88 на OpenCL.
  • Отказ от поддержки языка CUDA в пользу OpenCL, что ничуть не мешает полноценному использованию GPU от NVIDIA (и даже помогает, благодаря фокусированию разработки и оптимизаций на одну реализацию каждого формата под GPU вместо двух реализаций ранее).
  • Поддержка новых наборов инструкций SIMD - AVX2, AVX-512 (в том числе для второго поколения Xeon Phi) и MIC (для первого поколения) - а также более универсальное и полное использование SIMD в реализациях многих форматов, включая применение ранее поддерживаемых наборов инструкций вплоть до AVX и XOP на x86(-64) и NEON, ASIMD и AltiVec на ARM, Aarch64 и POWER, соответственно. (Частично в рамках GSoC 2015.)
  • Многочисленные оптимизации для CPU и OpenCL, как для более эффективной работы с большим количеством хешей одновременно (например, проверялась загрузка 320 миллионов хешей SHA-1 на GPU), так и для повышения скорости вычисления хешей. Часть из этих оптимизаций универсальные, часть охватывает различные подмножества форматов, а многие специфичны для отдельных форматов.
  • (Авто-)настройка оптимальной буферизации проверяемых паролей на CPU ("--tune=auto --verbosity=5") и оптимальных размерностей задания на OpenCL (включена по умолчанию), в том числе с учетом медленного выхода на полную рабочую частоту GPU серии NVIDIA GTX 10xx и новее. Использование реально загруженных хешей и реальной длины проверяемых паролей (когда она известна заранее) для такой авто-настройки.
  • Добавление компилятора «динамических выражений», указываемых прямо на командной строке и реализующих новые гибридные типы хешей, например "--format=dynamic='sha1(md5($p).$s)'", вычисляемые на CPU с использованием SIMD. В качестве компонентов таких выражений поддерживаются десятки быстрых хешей (от распространенных вроде MD5 до умеренно экзотических вроде Whirlpool), объединение подстрок, кодирование и декодирование, преобразование регистра символов, ссылки на пароль, соль, имя пользователя и строковые константы.
  • Устранение нежелательных отличий от hashcat, в том числе поддержка ранее специфичных для hashcat правил (wordlist rule commands), переход на нумерацию OpenCL устройств с 1-го, применение по умолчанию тех же длин паролей (обычно длина 7) при тестах производительности.
  • Новые режимы генерирования проверяемых паролей (cracking modes), включая PRINCE из hashcat (формирует «фразы», объединяя несколько слов в порядке возрастания суммарной длины), subsets (подбирает пароли с недостаточным количеством различных символов, даже если эти символы пришли из большого набора возможных) и hybrid external (позволяет внешним режимам, описываемым в файлах конфигурации на Си-подобном языке, формировать много проверяемых паролей на основе каждого базового «слова», поступившего от другого режима). Также, несколько новых предопределенных внешних режимов.
  • Дополнительные возможности по использованию нескольких режимов одновременно (один поверх другого - stacking), а также по такому использованию наборов правил (wordlist rules stacking).
  • Усовершенствования режимов mask (постепенное растягивание маски в указанном диапазоне длин, применение маски на стороне OpenCL-устройства или платы FPGA) и single crack (разумное поведение на устройствах, вычисляющих большое количество хешей параллельно, на что ранее в этом режиме не хватало проверяемых паролей, а также ограничения на расход памяти).
  • Много улучшений поддержки Unicode и других кодировок в разных подсистемах.
  • Много улучшений программ *2john (преобразующих файлы разных форматов для использования с john), в особенности wpapcap2john (обрабатывает WiFi трафик).
  • Много новых опций командной строки, настроек в john.conf, опций configure-скрипта и соответствующие им новые возможности, далеко не все из которых удалось упомянуть здесь.
  • Повышение качества кода благодаря встроенной поддержке отладочных сборок с AddressSanitizer (была ранее) и UndefinedBehaviorSanitizer (добавлена), добавлению встроенного фаззера форматов (в рамках GSoC 2015), применению непрерывной интеграции (сборки под десятки сочетаний операционной системы и компилятора и тестирование в них корректной поддержки всех форматов).

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



Проверено: jollheef ()

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

а где такие платы купить?

С этим большая проблема, и поэтому для нас эта часть разработки скорее академическая (у самих эти платы есть, но понимаем что таких пользователей JtR мало) и как тренировка на будущее - надо же поддержку FPGA с чего-то начинать. Следующим шагом возможна поддержка ныне актуальных плат VCU1525/BCU1525 (которые пока дорого стоят - около $4k - но зато их легко купить, а цены потом упадут когда майнеры начнут распродавать) и Amazon AWS F1 (который более доступен по цене для эпизодического использования, при том что там стоят те же VCU1525).

В 2014-2016 платы ZTEX 1.15y было легко купить на eBay (от $50 до 250 EUR за штуку, в зависимости от продавца и количества) и как-то они были даже на Avito (аналогично дешево). Сейчас купить стало трудно. Я думаю, наиболее реально спрашивать на криптовалютных форумах и в тредах, где раньше эти платы обсуждались между их владельцами:

https://bitcointalk.org/index.php?topic=49180

либо в специализированных под-форумах о купле-продаже майнинг-оборудования:

https://bitcointalk.org/index.php?topic=2173693

Возможно, их еще используют для майнинга некоторых altcoin'ов. Вот, например, 2 года назад человек отказался продать свои 27 плат, потому что еще майнил:

https://steemit.com/cryptocurrency/@penname/21-of-the-entire-block-chain-27-z...

Можно его переспросить - может, уже готов продать, если еще не.

А моно искать коллизии, а то в моих паролях в среднем 512 бит информации?

Отвечу шуткой на шутку: лучше стерео, и в одном 0, а в другом 1024 бит, вот и будет в среднем 512.

А коллизии искать можно и их вполне реально найти для классического descrypt - для красоты, так как практического применения редких коллизий хешей паролей почти нет.

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

Столько усилий, да в мирное бы русло бы.

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

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

Ну ты там держи в курсе, ага

Злые вы тут, на LOR'е. ;-) Если что, я не Денис. Не вижу проблемы в giving credit (есть ли в русском точный аналог?), за исключением того что большинству читателей всё равно.

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

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

Вот эта вся гонка и состоит из попыток сломать работающее. В сути своей бессмысленная. Половина мощности современного компьютера идёт на обеспечение безопасности и конфиденциальности. Ах, если бы человечество было другим...

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

Половина мощности современного компьютера идёт на обеспечение безопасности и конфиденциальности.

...а от другой половины 90% - на множество уровней абстракции.

В целом, да.

Но с хешированием паролей на серверах и с их обработкой при работе с шифрованными архивами, файловыми системами и т.п. в этом плане всё вовсе не так плохо. Например, из доклада автора Crack и на тот момент сотрудника Facebook, после внедрения scrypt с прилично-высокими параметрами они тратили на хеширование паролей 0.2% процессорного времени на frontend nodes. А при монтировании шифрованной файловой системы пользователю разумно ждать выполнения KDF, по моему мнению, от 0.1 до 1 секунды. Это мизерная доля от общего расхода процессорного времени за сеанс работы, да и вряд ли было бы лучшее применение этого времени - это был бы просто idle. Разумеется, эта оценка относится только к парольному компоненту, а не ко всему обеспечению «безопасности и конфиденциальности».

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

Но сколько сил тратится на безопасность! Разработка во что превратиласть? Вместо элементарного

функ сенд_месседж(месседж, дестинейшон){
    таргет = файнд(дестинейшон)
    иф сенд(таргет, хелло).ансверед зен:
        сенд(таргет, месседж + хаванайсдей)
}
мы имеем
функ сенд_месседж(месседж, сендер, дестинейшон, сендер_кей, сендер_пруф, сендер_даблпруф, месседж_чексум){
    таргет = файнд(дестинейшон)
    иф чек(таргет).из_риал энд чек(таргет).нот_а_бадгай энд чек(таргет)ещё_хандред_сингз зен:
        тарге
        иф сенд(таргет,хелло).ансверед зен:
            иф сенд(таргет,хелло).из_ин_международнен_сертефикейшон_ссл_листс зен:
                иф сенд(таргет,хелло).из_реал зен:
                    иф сенд(таргет,хелло).всё_ещё_сэйм_гай зен:
........
//спустя три миллиона строк
   сенд(таргет, факоф_пидоры_я_уже_форгетнул_ват_ай_вонил_ту_сэй)
   шут_зе_буллет_ин_зе_хед(сендер)
}
Всё это, конечно, бред, но это отражает омерзение, которое я испытываю к этой части человеческой натуры и ко все этой возне в целом.

ChekPuk ()

А есть табличка по скорости перебора на доллар по разным типам хешей? Т.е. например у атакующего есть миллион долларов, хочется понять, сколько битов он сможет перебрать за год.

Legioner ★★★★★ ()

Александр, по поводу FreeBSD порта JtR, вы когда-то просили сделать jumbo опциональным. Новая версия — хороший повод, но я не вижу диффа (отдельным файлом) между ванильной и jumbo-версией. Плохо (или не туда) смотрю?

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

Ты продержись, пока пубертат не закончится, потом попустит. Но если совсем невмоготу, то рекомендую занятия спортом, общение со сверстниками (в том числе со сверстницами, особенно в романтическом ключе), здоровый режим сна и следи за питанием. Да, и на свежем воздухе хотя бы часа два-три в день проводи. Многие через это прошли, не так страшен чёрт. Удачи!

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

Но сколько сил тратится на безопасность! Разработка во что превратиласть?

Я во многом согласен, но вижу в этом и другие аспекты и с философской и с практической точки зрения. С практической, часть аспектов заботы о безопасности (security) заодно повышает надежность систем (reliability, safety). Не такие, как «чек(таргет).нот_а_бадгай», а такие как наличие защиты страниц в MMU у CPU и использование этого в OS, и упомянутое мной в новости применение нами ASan, UBSan и фаззинга при разработке.

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

Есть тесты hashcat на конкретных GPU. Известны скорости для JtR на FPGA. Но сравнивать скорости на доллар надо при фиксированной производительности хешей для защищающей стороны (все современные хеши паролей имеют параметры, которыми их надо настроить под целевые throughput и latency на целевом оборудовании). Для легких (не memory-hard) хешей я недавно делал такое сравнение (см. также другие мои комментарии в том треде) для принятия решений при разработке libxcrypt. Для серьезных внедрений (онлайн-сервисы с миллионами пользователей, банки и т.п.) мы сейчас рекомендуем наш yescrypt, который сравниваем (см. на страничке по ссылке) с scrypt и Argon2.

Миллион долларов - это на грани того, что некоторые такие атакующие смогут заказать ASIC. Для ASIC'ов, к сожалению наиболее свежие известные мне оценки производительности на доллар - в исходной статье об scrypt, но это 2009 год, да и уже тогда они были сделаны на основе устаревающих техпроцессов.

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

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

по поводу FreeBSD порта JtR, вы когда-то просили сделать jumbo опциональным.

Эта просьба устарела. Раньше был официальный JtR и неофициальный jumbo. Сейчас есть JtR core и JtR jumbo. Возможно, в 2.0 мы прекратим выпускать core отдельно, а jumbo станет единственной текущей версией JtR.

не вижу диффа (отдельным файлом) между ванильной и jumbo-версией.

Да, его нет. Не вижу для него применений. Исходники core сейчас составляют несколько процентов от общего объема исходников jumbo, так что читать такой diff есть смысл разве что нам самим при разработке, чтобы избежать нечаянных отличий. Помимо исходников, core и jumbo включают большие *.chr файлы, а jumbo - еще ~20 MB уже собранных bitstream'ов под FPGA (так как для их сборки требуются проприетарные инструменты, она не проста и занимает много часов).

Поэтому советую продолжить собирать только jumbo. К сожалению, на FreeBSD для сборки jumbo нужен gmake, но это, наверное, очень распространенное требование среди портов. Также, сборка clang'ом не дает поддержку OpenMP, поэтому мы рекомендуем собирать с помощью gcc.

Спасибо!

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

Возможно, в 2.0 мы прекратим выпускать core отдельно, а jumbo станет единственной текущей версией JtR.

Хм, но это будет означать, что вы жестко завяжетесь на OpenSSL, не так ли? Одна из приятных фишек ваниллы сейчас как раз в том, что она не ломается, например, из-за того, что в OpenSSL внезапно перелопатили половину API и заопачили кучу структур.

К сожалению, на FreeBSD для сборки jumbo нужен gmake, но это, наверное, очень распространенное требование среди портов.

Верно; это не проблема совершенно.

Также, сборка clang'ом не дает поддержку OpenMP, поэтому мы рекомендуем собирать с помощью gcc.

Действительно, поддержка OpenMP сейчас закомментарена, это еще с тех времен, когда Clang не умел в OpenMP, но разве он этому не научился за последние год-два?

Спасибо!

Спасибо вам за отличный софт, подробные комментарии, ответы на вопросы и плотное взаимодействие с коммьюнити в целом! :-)

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

С большой натяжкой соглашусь. Некоторое исследовательское полезное зерно есть в этих проектах, но мизерное (применительно к моей гипотетической, утопической вселенной, населённой исключительно добрыми людьми). Ладно. Извини, что развёл тут. Всё равно крякали и будут крякать и гигаваты энергии бросать на перебор паролей и всё этим людишкам мало, надо больше, больше...

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

Intel уже отказалась от Xeon Phi

Да, насколько я слышал эта линейка завершится и будет заменена другой, но разные Xeon Phi есть в уже установленных кластерах, а также есть рабочие станции «для разработки», в которых Knights Landing в качестве хост-процессора (на такой и проверяем наш код, и еще на старой карточке Knights Corner). А еще эти карточки полезны для тестирования масштабируемости на большее количество потоков OpenMP (проверяем 256 и 240 соответственно на упомянутых системах), чем сейчас встречается на типичных серверах (но скоро будет).

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

вы жестко завяжетесь на OpenSSL, не так ли?

Постараемся этого избежать. magnum как раз недавно высказывался в пользу отказа от зависимости jumbo от OpenSSL. Постепенно отвяжем всё больше форматов от такой зависимости, а потом немногие оставшиеся (которые отвязать трудно) сделаем отключаемыми при сборке без OpenSSL.

Clang не умел в OpenMP, но разве он этому не научился за последние год-два?

Не знаю - был бы рад узнать. Попытка собрать clang'ом что-либо с OpenMP на «FreeBSD 12.0-RELEASE-p3 amd64», «FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)» в GCC Compile Farm дает ошибку «/usr/bin/ld: error: unable to find library -lomp» - то есть вроде как clang знает про OpenMP, но библиотеки в системе нет. Там же сборка с помощью gcc дает работоспособный OpenMP.

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

то есть вроде как clang знает про OpenMP, но библиотеки в системе нет.

Пока идет отдельно:

% pkg which /usr/local/lib/libomp.so
/usr/local/lib/libomp.so was installed by package openmp-8.0.0_1
Но:
% pkg info --pkg-message openmp-8.0.0_1                                         
openmp-8.0.0_1:
Always:
===>   NOTICE:

This port is deprecated; you may wish to reconsider installing it:

Part of base system since FreeBSD 11.3/12.1.

It is scheduled to be removed on or after 2019-12-31.

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

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

praseodim ★★★ ()