The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от opennews (??) on 03-Июл-12, 09:23 
Выпущена (http://www.openwall.com/lists/john-users/2012/06/29/1) новая "community-enhanced" версия подборщика паролей John the Ripper (http://www.openwall.com/john/) 1.7.9-jumbo-6. Несмотря на скромное изменение номера версии, в 1.7.9-jumbo-6 вошли изменения за полгода работы, а также патчи, разработанные ранее. Всего с момента прошлого выпуска добавлено более 40 тысяч строк исходного кода, не считая измененных.


Ключевое отличие новой версии - поддержка CUDA и OpenCL, которая ранее была доступна лишь в виде отдельных патчей и для более ограниченного набора хешей. На GPU реализованы в пригодном для практического использования виде такие хеши как phpass, md5crypt, sha512crypt, sha256crypt, bcrypt, MSCash2 (Windows DCC2), а также WPA-PSK, RAR, Password Safe. Дополнительно присутствуют работоспособные, но пока неэффективные реализации "быстрых" хешей: raw MD5/SHA-1/SHA-224/SHA-256, NTLM, MSCash (Windows DCC), MySQL SHA-1, Netscape LDAP SSHA. Также, присутствуют реализации raw SHA-512 и Mac OS X 10.7 salted SHA-512, однако в них незадолго до этого релиза была обнаружена серьезная ошибка, которую удалось исправить лишь вскоре после релиза (исправление войдет в -jumbo-7).


С практической точки зрения, наиболее интересна может быть поддержка sha512crypt на GPU, которая до её появления в  John the Ripper была недоступна (и в других инструментах тоже, включая проприетарные). На NVIDIA GTX 570 1600 MHz достигается скорость 11400 c/s при rounds=5000, что в 5.5 раз выше скорости имеющейся в этой же версии John the Ripper  реализации на CPU, работающей на процессоре AMD FX-8120. На GPU от AMD пока результаты более скромные.


С теоретической точки зрения, интересна поддержка bcrypt на GPU, которая опять же отсутствует в других инструментах. Как и ожидалось, скорость вычисления bcrypt на GPU низкая, но тем не менее на вопрос удастся ли достичь скорости, хотя бы аналогичной CPU, получен положительный ответ: на AMD Radeon HD 7970 с частотой ядра, повышенной до 1225 MHz (на 32% выше стандартной в 925 MHz), достигается скорость аналогичная процессору AMD FX-8120 (около 5300 c/s при $2a$05). При этом температура GPU остается низкой из-за далеко неполного использования его возможностей в bcrypt.


Подобный результат может подкрепить позиции bcrypt в сравнении с sha512crypt с точки зрения перехода на один из этих хешей операционных систем, приложений, веб-сайтов и т.п. Одно дело теоретические утверждения о неэффективности bcrypt на GPU, и другое - практическая демонстрация с общедоступным исходным кодом, который каждый желающий может проверить на различных GPU и попытаться оптимизировать. Разумеется, это не является доказательством невозможности более эффективной реализации, и более того работы над дальнейшей оптимизацией ведутся и в рамках John the Ripper. Для практического применения подбор bcrypt на GPU со скоростью, аналогичной CPU, может быть актуален для специалистов, у которых уже имеются компьютеры с несколькими GPU.


Для некоторых других типов хешей и не только достигается ускорение, схожее с доступным в других программах - например, 27 раз для WPA-PSK (от 2000 до 55000 паролей в секунду) при переходе с FX-8120 на HD 7970 (на стандартной частоте).


Помимо поддержки GPU, в этой же версии появилась поддержка целого ряда хешей: IBM RACF, своя реализация sha512crypt и sha256crypt (без завязки на системную, как было раньше), Drupal 7 (вариант phpass на основе SHA-512), Django, DragonFly BSD 2.2, WoltLab BB3, новые хеши EPiServer, ГОСТ Р 34.11-94, MD4 как доступная примитива в хешах, определяемых пользователем (дополнительно к MD5 и SHA-1), а также вариант SHA-1, встречающийся в дампе LinkedIn.


Также, появилась поддержка ряда других возможностей: Mac OS X keychains, KeePass 1.x, Password Safe, файлы ODF, документы Office 2007/2010, master-пароли Mozilla Firefox/Thunderbird, архивы RAR в режиме "-p" (режим "-hp" поддерживался и ранее), WPA-PSK/WPA2-PSK, аутентификация VNC и SIP, HMAC-SHA-1/224/256/384/512.


Наконец, были добавлены некоторые функции в основную программу (например, встроенный режим --loopback, при котором ранее подобранные пароли используются как словарь для подбора новых), поддержка OpenMP-параллелизации расширена еще на пару десятков вещей (как поддерживавшихся ранее, так и новых), добавлены оптимизации, включая использование AES-NI через свежие версии OpenSSL при подборе пароля к RAR-архивам и использование AMD XOP (на Bulldozer) для многих хешей на основе MD4, MD5, SHA-1 (использование XOP для DES появилось в одной из предыдущих версий). В частности, для md5crypt благодаря XOP достигается скорость в 204k c/s на FX-8120, что примерно на 20% выше результата для Core i7-2600 с AVX (ранее, без использования XOP, наоборот, процессор от AMD отставал).

URL: http://www.openwall.com/lists/john-users/2012/06/29/1
Новость: https://www.opennet.ru/opennews/art.shtml?num=34250

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 03-Июл-12, 09:23 
поддержка OpenMP-параллелизации расширена еще на пару десятков вещей (как поддерживавшихся ранее, так и новых)

Вещей?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +3 +/
Сообщение от solardiz (ok) on 03-Июл-12, 09:32 
Я так и знал, что это слово не понравится. Мне тоже не нравится. Предложите лучшее, охватывающее такие, извиняюсь, вещи как обычные хеши паролей (например, от Invision Power Board 2), trip-коды, файлы менеджеров паролей, RAR-архивы, Office-документы, WPA-PSK, VNC challenge/response (и это только часть того, что подразумевалось). Знатоки русского - предлагайте - мне это правда пригодится на будущее. :-) Пока у меня лучший вариант - "хешей и шифров" - но и этот вариант мне не нравится.

Кстати, и в английском не всё так просто. JtR сейчас использует свой термин "format" (есть опция --format=такой-то и т.д.), но он мне не нравится. Заменить на hash - будет неправильно в части случаев. Подумываю в 1.8 заменить на cipher, хотя и это тоже криво. Предложите лучшее.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от Аноним (??) on 03-Июл-12, 09:39 
Сущность?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от Дум Дум on 03-Июл-12, 10:05 
Задач? Категорий? Категорий задач? Типов задач?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от Аноним (??) on 03-Июл-12, 10:09 
Применений? Приложений?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

8. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 03-Июл-12, 10:23 
Объекты подбора ?

Кстати, "форматы" тоже неплохо, по крайней мере то что задумано под опцией "--format" более менее понятно сразу, а вот при hash  и cipher потребуется дополнительно выяснять что именно имелось в виду.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

25. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 03-Июл-12, 15:13 
>Предложите лучшее

Криптографических алгоритмов

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

36. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Антон (??) on 03-Июл-12, 18:56 
Почему не object? Понятно, что у всех другие ассоциации, но здесь бы подошло.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

42. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от solardiz (ok) on 04-Июл-12, 02:41 
> Почему не object? Понятно, что у всех другие ассоциации, но здесь бы подошло.

Тогда уж class, что, кстати, соответствует структуре программы (хоть она и на Си). Сейчас для каждого format'а в программе есть свой экземпляр вот такой структуры:

struct fmt_main {
        struct fmt_params params;
        struct fmt_methods methods;
        struct fmt_private private;
        struct fmt_main *next;
};

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

4. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Хвост on 03-Июл-12, 10:02 
Расширена поддержка OpenMP-параллелизации (около 20 позиций).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 03-Июл-12, 10:23 
поддержка OpenMP-параллелизации расширена еще на пару десятков элементов
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +3 +/
Сообщение от Аноним (??) on 03-Июл-12, 10:42 
алоритмов?

(OpenMP поддерживает алгоритмы, обрабатывающие те самые format-ы)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от terr0rist (ok) on 03-Июл-12, 11:39 
точно. термин "алгоритм" используется во всех учебниках и не только.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

20. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Michael Shigorin email(ok) on 03-Июл-12, 14:05 
> алоритмов?

И соответственно --algo.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

34. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от solardiz (ok) on 03-Июл-12, 16:44 
> И соответственно --algo.

Я не назвал эти вещи алгоритмами с самого начала (т.е. в 1990-х) потому, что для одного и того же метода хеширования возможны разные алгоритмы реализации - например, для DES в John'е есть не-bitslice и bitslice реализации, а также варианты их настройки/сборки (тоже разные алгоритмы получаются). Это отличие между методом хеширования (математической функцией, т.е. отображением каких-то входных данных на выходные) и конкретным алгоритмом его реализации иногда очень важно не забывать.

В John'е понятие алгоритм используется буквально. У "форматов" есть поле algorithm_name, которое для примера с DES может содержать разные значения в разных сборках.

Но спасибо за совет. Я подумаю.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

39. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Michael Shigorin email(ok) on 03-Июл-12, 23:54 
> Я не назвал эти вещи алгоритмами с самого начала (т.е. в 1990-х)
> потому, что для одного и того же метода хеширования возможны разные
> алгоритмы реализации - например, для DES в John'е есть не-bitslice и
> bitslice реализации, а также варианты их настройки/сборки (тоже разные
> алгоритмы получаются).

Ходил-ходил, думал-думал, а что если:

--algo=des/bitslice
(либо какой другой разделитель, чтоб простой разбор однозначным оставался)?
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

41. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от solardiz (ok) on 04-Июл-12, 02:34 
> Ходил-ходил, думал-думал, а что если: --algo=des/bitslice (либо какой другой разделитель, чтоб простой разбор однозначным оставался)?

Это излишнее для пользователя усложнение, которое к тому же сложно в реализации (сейчас выбор алгоритма частично определяется на этапе сборки). До недавнего времени, опция --format определяла исключительно тип хеша, шифра и т.п., тогда как выбор алгоритма (конкретной реализации) оставался за John'ом и его сборкой (частично выбор определялся make target'ом, частично конкретной машиной/системой). С появлением поддержки GPU и еще некоторыми изменениями, у нас появилось по нескольку format'ов для одного и того же типа хеша/шифра в одной и той же сборке - например, sha512crypt в наиболее полной сборке может быть вызван с помощью --format=sha512crypt (угадывается по умолчанию при соответствующем входном файле), --format=sha512crypt-cuda, --format=sha512crypt-opencl или даже --format=crypt (при наличии поддержки sha512crypt в системе, т.е. в libcrypt, если мы говорим о Linux/glibc). Это не очень красиво (сами хеши и их алгоритмы реализации всё-таки перепутались), но искусственное разделение (более чем соглашением об использовании суффиксов -cuda и -opencl) и возможность пользователю указать алгоритм более точно, чем это реально требуется, вряд ли чем-то поможет.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

11. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +2 +/
Сообщение от Аноним (??) on 03-Июл-12, 10:58 
Похоже, пора покупать анти-Wi-Fi-обои. :)
И обклеивать ими весь периметр - и стены, и потолок и пол. :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 03-Июл-12, 11:24 
фольга же
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

30. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  –3 +/
Сообщение от Denis email(??) on 03-Июл-12, 16:15 
Сделай доступ по маку и не парься
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

43. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +2 +/
Сообщение от Аноним (??) on 04-Июл-12, 05:18 
> Сделай доступ по маку и не парься

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

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

12. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 03-Июл-12, 11:20 
solardiz, поддержка WPA-PSK1/2 для подбора по словарю и брутфорса или только по словарю?

Спасибо.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от solardiz (ok) on 03-Июл-12, 15:44 
Для любого из поддерживаемых в John режимов, как и всё остальное.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

15. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +2 +/
Сообщение от Мнестрашно on 03-Июл-12, 12:41 
Джон могильщик?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от Аноним (??) on 03-Июл-12, 12:48 
Потрошитель. Да-да, вы правильно его боитесь - используйте сложные пароли.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

16. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 03-Июл-12, 12:47 
> На GPU от AMD пока результаты более скромные.

Что-то недооптимизили явно.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  –1 +/
Сообщение от Аноним (??) on 03-Июл-12, 13:15 
Да, проблема очевидно в коде. Биткоины АМД считаю сильно быстрее НВИДИА.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

23. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 03-Июл-12, 14:14 
> Да, проблема очевидно в коде. Биткоины АМД считаю сильно быстрее НВИДИА.

Ну да. SHA-256 у них что-то совсем позорный на фоне майнеров коинов вышел. Еще hashkiller хеши на AMD очень быстро крушит, и сорец есть. Так что сорц в руки авторам риппера, пусть изучают что недооптимизили.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

26. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 03-Июл-12, 15:28 
А не настораживает то, что это практически все программы которые вообще имеет смысл на AMD картах ускорять? Все остаольное GPU- подобное исключительно на нвидиях крутят. Подсказка: Не все так хорошо с вычислениями у AMD, за исклбчением специально отобранных частных случаев.
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

44. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 04-Июл-12, 05:21 
> нвидиях крутят. Подсказка: Не все так хорошо с вычислениями у AMD,
> за исклбчением специально отобранных частных случаев.

У нвидии относительно мало относительно шустрых ядер. Смысл этого решения мне вообще не понятен - ни два, ни полтора получается. Не параллелящиеся алгоритмы проще гонять на CPU - они еще высокочастотнее и отдельно взятое ядро там намного круче. А сильно параллелящиеся - на амд лучше будут. В результате нвидии остается галимый пиар да какие-то экзотичные виды вычислений.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

29. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +2 +/
Сообщение от solardiz (ok) on 03-Июл-12, 16:04 
> SHA-256 у них что-то совсем позорный на фоне майнеров коинов вышел.

Все "быстрые" хеши на данный момент реализованы в JtR лишь как этап разработки. Проверяемые пароли на данный момент формируются на CPU и передаются на GPU, что дает ограничение скорости примерно на уровне от 20 до 100 миллионов в секунду (в разных случаях) - т.е. в разы или на порядки ниже, чем требуется для "быстрых" хешей на GPU. Эта проблема нам хорошо известна (и была известна до начала разработки), ей мы занимаемся отдельно (планируется частично формировать пароли на GPU). Пока же - есть релиз для, кстати, более актуальных на практике (для аудитов, а не "поиграться") "медленных" хешей, а заодно RAR, WPA-PSK, Password Safe. Кстати, большинство из них использует в основе те же быстрые хеши (особенно SHA-1), и скорость в расчете на одну итерацию такого хеша или же скорость всего "медленного" алгоритма в целом получается вполне сравнимой с тем, что дают конкурирующие программы (в случаях, для которых они вообще есть). Например, в RAR - 256k (262144) итераций SHA-1. Скорость у нас получается 4380 c/s на GTX 570 1600 MHz, т.е. около 1.15 миллиарда SHA-1 в секунду, и это не считая остальных частей задачи (в RAR не только этот SHA-1). На HD 7970 - 7162 c/s и 1.88 миллиарда, соответственно.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

45. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 04-Июл-12, 05:33 
> разы или на порядки ниже, чем требуется для "быстрых" хешей на
> GPU. Эта проблема нам хорошо известна (и была известна до начала
> разработки), ей мы занимаемся отдельно (планируется частично формировать пароли на GPU).

Кстати да, у hashkill с этим тоже некоторые проблемы. Насколько я понял - он далеко не все варианты генерации паролей на GPU переваривает. И вполне себе глючит на некоторых из них. Еще кстати там же можно посмотреть ряд AMD-specific оптимизаций типа BFI_INT и тому подобных. В майнерах народ очень сереьзно рубился в плане скорости и они выжали из AMDшных карточек довольно много.

> MHz, т.е. около 1.15 миллиарда SHA-1 в секунду, и это не
> считая остальных частей задачи (в RAR не только этот SHA-1). На
> HD 7970 - 7162 c/s и 1.88 миллиарда, соответственно.

В принципе достаточно внушающая уважение цифра. Но, блин, если сравнивать результаты sha1 и sha256 влобовую с иными реализациями - что-то невкусно. При нужде распотрошить влобовую sha1 или sha256 я пожалуй hashkill поюзаю. При всем уважении к Ripper'у который весьма и весьма мощная и продвинутая программа, внушающая уважение.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

50. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от solardiz (ok) on 04-Июл-12, 15:50 
BFI_INT раньше надо было патчить в бинарный kernel (многие прописывали в исходник amd_bitalign(), а затем патчили бинарник поиском с заменой) или же программировать на уровне IL (как делали в ElcomSoft). Мы же на этот праздник опоздали, нынче bitselect() транслируется в BFI_INT без всяких сложностей. Его и используем.

> если сравнивать результаты sha1 и sha256 влобовую с иными реализациями - что-то невкусно. При нужде распотрошить влобовую sha1 или sha256 я пожалуй hashkill поюзаю.

Конечно, или Cryptohaze Multiforcer - если говорить об Open Source. Авторы того и другого - у нас в гостях в списке рассылки john-dev, мы понемногу обмениваемся опытом.

"Быстрые" хеши на GPU - это пока не к John'у. Не всё сразу.

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

54. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от solardiz (ok) on 09-Июл-12, 02:24 
Поправка: приведенный мной ранее пересчет с RAR c/s на SHA-1 - ошибочный, т.к. полный буфер заполняется и SHA-1 compression function выполняется не на каждую из 256k итераций (реально это происходит около 110 тысяч раз и зависит от длины пароля). Вот реальные данные (скорости в пересчете на SHA-1, по-прежнему без учета остальных затрат, в 2-3 раза ниже):

http://www.openwall.com/lists/john-dev/2012/07/08/40

С другой стороны, у нас всё же достигается около 1.9 миллиарда SHA-1 в секунду на 7970 в рамках реализации MSCash2 в 1.7.9-jumbo-6, и около 2.1 миллиарда там же в более новом коде (пока не в релизе):

http://www.openwall.com/lists/john-dev/2012/07/08/52

MSCash2 содержит 10240 итераций HMAC-SHA-1 или 20480 вычислений SHA-1 (плюс еще несколько и еще MD4 вне цикла).  92467*20480 = 1.89 миллиарда, 103819*20480 = 2.13 миллиарда.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

31. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от solardiz (ok) on 03-Июл-12, 16:19 
> Что-то недооптимизили явно.

Конечно. Но не факт, что конкретно для sha512crypt нынешние карты от AMD быстрее нынешних же карт от NVIDIA (при оптимальном коде и там и там). Эта задача не сводится чисто к вычислениям, но также слегка затрагивает и работу с памятью - не настолько как bcrypt или тем более scrypt, но более чем многие другие хеши. Вот в этом треде:

http://hashcat.net/forum/thread-790.html

автор hashcat дает такую оценку: "i dont expect sha512crypt being much faster on gpu than on cpu. maybe x 2 or x 3 at best." И по этой причине не торопится с реализацией (скорость не впечатлит, да). У нас же получилось 5.5x (на NVIDIA), что вдвое выше прогноза. Правда, если учесть что реализация на CPU может быть оптимизирована и ускорена как раз где-то еще вдвое (есть конкретные соображения на этот счет), то останутся те самые прогнозируемые 2-3 раза. Также, oclHashcat-plus недавно начал поддерживать raw SHA-512 и вариант, используемый в Mac OS X Lion, давая скорость около 70 миллионов паролей в секунду на один GPU-чип почти одинаково что на GTX 570 1600 MHz, что на HD 7970 (т.е. на таких же карточках, которые мы используем в разработке). У нас достигается близкая скорость: 11400 c/s * 5000 итераций = 57 миллионов. С учетом затрат на "высокоуровневый" алгоритм sha512crypt, это хороший результат. Аналогично, у нас достигается скорость под 70M c/s при подборе паролей для хешей с Mac OS X Lion для случая "many salts" (т.е. когда мы не упираемся в передачу пробуемых паролей от CPU на GPU).

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

46. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 04-Июл-12, 05:46 
>> Что-то недооптимизили явно.
> Конечно. Но не факт, что конкретно для sha512crypt нынешние карты от AMD
> быстрее нынешних же карт от NVIDIA (при оптимальном коде и там и там).

Насчет sha512crypt ничего не скажу (мне он как-то не требовался), а вот гольный sha256 или sha1 на амд мало того что рвет нвидию как тузик грелку в других реализациях, так что самая топовая нвидия не дотягивает даже до моей 90-баксовой 5770, по поводу чего все майнеры биткоинов дружно показали нвидии то же что и Торвальдс ;). Более того, еще и скорость памяти там нафиг не упала: народ ломающий sha (SL3 unlock, etc) и считающий коины ее специально даунклокает до минимума без какой либо потери в скорости. Результат тот же а TDP снижается на несколько ваттов. Что позволяет например поднять частоту ядра GPU еще на несколько МГц при равной температуре (в этом плане майнер от Кона Коливаса довольно крут - динамически меняет частоты ядра GPU в зависимости от температуры, но там сильная специфика AMDшного ADL SKD, которое реализуется только амд и только проприетарным драйвером и вообще достаточно грабельная и глючная штука).

> http://hashcat.net/forum/thread-790.html
> автор hashcat дает такую оценку: "i dont expect sha512crypt being much faster
> on gpu than on cpu.

Ну видимо алгоритм такой. Если он memory intensive и не лезет в локальные регистры (коих там чуть более чем дофига, но не бесконечно) и мотается в основную оперативку - тогда наверное скорость будет порядка соотношения GDDR5 vs DDR3 на соотв. шинах. Но тут еще вопрос - влезет в регистры и скоростные local storage или полезет в относительно медленную основную оперативку постоянно.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

51. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от solardiz (ok) on 04-Июл-12, 16:16 
Да, это мы в курсе (не о конкретных майнерах, а в целом). 5770/6770 - пожалуй, оптимальный выбор по производительности за доллар, если учитывать только стоимость самих карточек. "Топовая нвидия" всё-таки, кажется, дотягивает до примерно такой же производительности по этим хешам - т.е. GTX 580 будет близко, GTX 590 будет быстрее (два чипа) - конечно, за гораздо бОльшие деньги. (GTX 680 будет медленнее, но это другое.)

Для sha512crypt регистров действительно не хватает. Используется локальная память. С глобальной вышло бы еще хуже - например, когда мы поначалу реализовали bcrypt на глобальной памяти, HD 7970 отставал от FX-8120 вдвое, хотя "теоретически" (если бы не скорость доступа к памяти) мог бы использовать все вычислительные ресурсы. Когда мы перевели его на использование LDS, при этом сознательно отказавшись даже от попытки использовать все вычислительные ресурсы (т.к. объема LDS могло хватить максимум на четверть), скорость возрасла вдвое (т.е. до скорости CPU). В случае sha512crypt и тем более SHA-512 всё далеко не так плохо (как с bcrypt), но и далеко не так хорошо как с SHA-256 и "меньшими".

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

19. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  –1 +/
Сообщение от Аноним (??) on 03-Июл-12, 13:35 
Шел 2012 год...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

24. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 03-Июл-12, 14:15 
> Шел 2012 год...

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

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

21. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от dq0s4y71 (??) on 03-Июл-12, 14:06 
> Также, появилась поддержка ряда других возможностей: ... KeePass 1.x,

То есть, он теперь кипассовские базы данных ломать умеет??

Кстати, если он умеет KeePass 1.x, то он умеет и KeePass 2.x - это две параллельные ветки с одинаковым форматом БД.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

32. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от solardiz (ok) on 03-Июл-12, 16:22 
> Кстати, если он умеет KeePass 1.x, то он умеет и KeePass 2.x

Там есть отличия. Поддержка KeePass 2.x появится в ближайшее время (уже есть в git).

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

22. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 03-Июл-12, 14:13 
Ну наконец-то. Заждался. Несколько лет не пользуюсь этой программой как раз из-за отсутствия OpenCL/CUDA. Теперь попробую.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним (??) on 03-Июл-12, 15:51 
А чем отличается стандартный Джон от "community-enhanced"?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

33. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от solardiz (ok) on 03-Июл-12, 16:32 
> А чем отличается стандартный Джон от "community-enhanced"?

Возможностями, объемом и качеством кода. В "community-enhanced" (или -jumbo) новый код включается очень легко, даже если он выглядит противно. ;-) В результате, там поддерживается более 100 различных "форматов" (хешей и шифров, алгоритмов - см. дискуссию о словах), теперь есть поддержка GPU, есть многие другие специфические возможности. В основной ветке же поддерживается только базовый набор хешей, используемых на Unix-системах, и лишь еще несколько других, часть оптимизаций отсутствует, но зато качество кода выше. С точки зрения разработки, основная ветка задает структуру программы и интерфейс для "форматов", а также базовый набор возможностей. Ветка -jumbo не является форком, а базируется на основной ветке (т.е. при выходе нового релиза в основной ветке, -jumbo переносится на эту кодовую базу).

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

35. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от 1 (??) on 03-Июл-12, 16:57 
Спасибо за разъяснение.
Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

37. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +2 +/
Сообщение от oraerk (ok) on 03-Июл-12, 20:39 
Есть баг с конвертацией airodump capture в формат john, воспроизводится так:

1) Качаем: http://wiki.wireshark.org/SampleCaptures?action=AttachFile&d... или используем любую другую капчу с успешным eapol, проверял на своей wifi сетке.
2) Конвертируем в формат hccap. Либо тулзой cap2hccap tool, либо на сайте https://hashcat.net/cap2hccap/ (результаты одинаковые, файлы побайтно получаются одинаковые)
3) Запускаем hccap2john на файле .hccap.
4) Валится ошибка "hccap2john: hccap2john.c:75: process_file: Assertion `bytes==392' failed."

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от solardiz (ok) on 04-Июл-12, 02:15 
Большое спасибо за баг-репорт. Проверим, исправим. Конкретно поддержку WPA-PSK реализовал Lukas в рамках еще продолжающегося GSoC 2012 - так что ему и исправлять. ;-) Багтрекера действительно нет. На данный момент о багах лучше всего сообщать в список рассылки john-users.
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

53. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от solardiz (ok) on 07-Июл-12, 09:58 
Мне оказалось проще сразу исправить самому. Вот патч:

http://www.openwall.com/lists/john-dev/2012/07/07/3

Хотя, если не исправлять другие мелочи, достаточно просто тот assert() выкинуть - он ошибочный.

Для wpa-Induction.pcap пароль Induction подобрался на HD 7970 по all.lst с --rules чуть больше, чем за минуту (при этом первые секунд 20 там уходят на self-test).

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

47. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от dq0s4y71 (??) on 04-Июл-12, 14:45 
Не могу собрать под MinGW:

$ wget http://www.openwall.com/john/g/john-1.7.9-jumbo-6.tar.bz2
$ tar xf john-1.7.9-jumbo-6.tar.bz2
$ cd john-1.7.9-jumbo-6/src
$ make clean win32-mingw-x86-sse2
...
In file included from dynamic_fmt.c:149:0:
sha.h:4:25: fatal error: openssl/sha.h: No such file or directory
compilation terminated.
...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

48. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +1 +/
Сообщение от solardiz (ok) on 04-Июл-12, 15:29 
Надо установить OpenSSL. На http://www.openwall.com/john/ явно сказано про jumbo, что оно "Requires OpenSSL 0.9.7 or newer", причем часть возможностей становится доступна только при сборке с 0.9.8 или новее (при сборке с 0.9.7 выдаются предупреждения о том, что некоторые возможности John'а будут недоступны из-за старого OpenSSL).

Основной и поддерживаемый вариант сборки John под Windows - с помощью Cygwin. Такую сборку я проверял в том числе непосредственно до выпуска -jumbo-6, она работает. При использовании OpenMP, рекомендую взять патченный cygwin1.dll из наших бинарных сборок (например, из john179j5w.zip) - иначе там иногда получается deadlock.

Поддержку сборки с помощью MinGW в jumbo добавил JimF - хотя, кажется, он сам теперь собирает вообще с помощью MSVC (в jumbo опять же есть #ifdef'ы от него и на эту тему). Проверяет ли сборку с MinGW кто-либо еще из разработчиков и делал ли это кто-либо незадолго до выпуска -jumbo-6, я не знаю. Я не проверял. Т.е. работает ли она в этой версии я не знаю.

Поддержка GPU пока что есть под Linux и в тестовом варианте под Mac OS X. Т.е. на данный момент сборка 1.7.9-jumbo-6 под Windows, которая успешно делается с помощью Cygwin, работает без использования GPU.

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

49. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от dq0s4y71 (??) on 04-Июл-12, 15:47 
Спасибо за обстоятельный ответ. Требование OpenSSL 0.9.7 действительно проглядел - оно там набрано мелким шрифтом.

Необходимость пересборки возникла потому, что у вас на главной странице Джона не выложены бинарники jumbo-6, только jumbo-5. Бинарники jumbo-6 нашёл на другой странице: http://openwall.info/wiki/john/custom-builds Попробую их.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

52. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от solardiz (ok) on 04-Июл-12, 16:28 
> Бинарники jumbo-6 нашёл на другой странице: http://openwall.info/wiki/john/custom-builds Попробую их.

Да, их Robert собрал уже после выхода jumbo-6, а я еще не успел на них посмотреть и придать им чуть более официальный статус (хотя до того, чтобы подписать такую сборку нашим ключом, дело всё равно не дойдет). Пока что под Windows сборка jumbo-5 - более официальная и, вероятно, останется такой до выхода и сборки jumbo-7.

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

55. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от user (??) on 10-Июл-12, 22:27 
А пароли от pgp/gpg ключей сабж умеет подбирать? И, если нет, планируется ли такая фича в перспективе?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

56. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от solardiz (ok) on 11-Июл-12, 09:52 
Пока нет (разве что через --stdout и самодельный скрипт). Планируется. Голос зачтен.
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

57. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от user2 (ok) on 11-Июл-12, 23:28 
>через --stdout и самодельный скрипт

Тогда на I/O задержек дофига наберется, или я что-то недопонимаю? Можно попробовать Джона соединить с libgpgme, но это уже не скрипт получится.

>Планируется. Голос зачтен.

Не от членов профсоюза пожелания тоже рассматриваются? А то, их есть у меня:).

7zip. Ну это понятно.

Из экзотики, steghide. (Помнится, еще задолго до всяких шпионских скандалов с рыжими тетками, мы с собутыльниками на форуме в городской локалке говнофотки выкладывали, а внутри оставляли друг другу сообщения.) Штука нераспространенная, и скорее всего мало кому интересна. С другой стороны там 15 криптоалгоритмов, и может кого с технической точки зрения заинтересует.

Truecrypt. Не как 7zip, но достаточно популярен и известен. Только, кроме обычного перебора паролей, еще интересна такая фича. Truecrypt, дополнительно к паролю может использовать файловый ключ. Так вот, из заданного каталога или списка взять файлы и подставлять их вместе с паролями. Используется не больше одного мегабайта от начала файла. Возможно есть смысл загонять их в память, и потом уже прокручивать.

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

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

58. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от solardiz (ok) on 11-Июл-12, 23:51 
Через --stdout и скрипт будет не быстро, но вряд ли для PGP/GPG выйдет такая уж высокая скорость и при работе напрямую. Хотя, конечно, разница в скорости будет.

7-Zip в планах, TrueCrypt в разработке - см. http://openwall.info/wiki/john/wishlist (там же ссылки на уже существующие реализации для TrueCrypt). Про файловые ключи я не знал; не знаю планирует ли Dhiru что-то по их поводу делать - вряд ли. Кстати, пока что я вижу реальный спрос на FileVault ("вот dmg-файл, надо подобрать пароль") и лишь теоретический на TrueCrypt ("хорошо бы", "любопытно"). Так что FileVault постараемся поддержать первым.

Насчет конкретно steghide не знаю и планов нет (т.к. никто до сих пор не интересовался), но некоторые другие подобные поддерживаются в Stegdetect и Stegbreak - http://www.outguess.org/detection.php - кстати, там используется wordlist rules код из John'а (с разрешения, т.к. под другой лицензией). Возможно, нам есть смысл наоборот импортировать остальную часть Stegbreak в современные версии John - подумаем. Спасибо за напоминание.

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

59. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от user2 (ok) on 12-Июл-12, 01:00 
>Через --stdout и скрипт будет не быстро, но вряд ли для PGP/GPG выйдет такая уж высокая скорость и при работе напрямую.

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

>Про файловые ключи я не знал; не знаю планирует ли Dhiru что-то по их поводу делать - вряд ли.

Если вы общаетесь, может стоит ему предложить? А то вдруг, он тоже не подумал. Пусть даже и не сразу реализовывать, но как задел на будущее.

Не очень понимаю, что такое outguess. В steghide используются криптографические алгоритмы - aes, serpent, gost и т. д. А outguess - это просто размещение в файл, или шифрование также есть?

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

60. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от solardiz (ok) on 12-Июл-12, 13:56 
> Интересно, получается у PGP еще большой запас прочности. Не только у зашифрованных данных, но и у самого ключа.

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

Говоря о временном варианте с --stdout, он может работать для скоростей до нескольких миллионов паролей в секунду, что не мало. Если скрипт будет вынужден запускать программу на каждый пароль отдельно (зависит от программы), это даст ограничение на уровне порядка одной тысячи в секунду. Вероятно, с правильным скриптом, запуска gpg на каждый вариант passphrase удастся избежать, например, используя опцию --edit-key и команду passwd там. При этом мы, возможно, упремся уже в эффективность реализации в gpg (которая, конечно, для этой задачи не оптимизировалась). Это если ограничиваться временными вариантами без правки программ - ни встроенной реализации в John'е, ни изменений в GnuPG.

> Если вы общаетесь, может стоит ему предложить?

Про файловые ключи в TrueCrypt я могу упомянуть при случае.

> А outguess - это просто размещение в файл, или шифрование также есть?

Я ссылался на stegbreak от того же автора и расположенный на том же сайте, а не на сам outguess. Но раз вопрос задан - в outguess есть примитивное шифрование с помощью RC4.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

61. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от user2 (ok) on 12-Июл-12, 23:38 
>Я ссылался на stegbreak от того же автора и расположенный на том же сайте, а не на сам outguess.

Ну да, я просто контекст полез там смотреть.

Спасибо за ответы!

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

62. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от solardiz (ok) on 19-Июл-12, 14:15 
Вот пробная реализация поддержки TrueCrypt:

http://thread.gmane.org/gmane.comp.security.openwall.john.us...

(Alain первым нашел на нее время.)

Комментарии приветствуются (лучше - в john-users, а если изменения в код - то в john-dev).

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

63. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от Аноним email(??) on 24-Авг-12, 12:40 
Поиогите с утановкой. Только начал в программме разбираться поставить не могу ошибки на dynamic_fmt.c:6709 eror: `sha_ctx` undeclared  ... и таких много ...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

64. "Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)"  +/
Сообщение от solardiz (ok) on 28-Сен-12, 13:58 
Надо установить OpenSSL. В дистрибутивах это обычно "development" под-пакет, который ставится отдельно. Например, "apt-get install libssl-dev" в Debian/Ubuntu.
Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру