| 1.1, Аноним (-), 09:23, 03/07/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
поддержка OpenMP-параллелизации расширена еще на пару десятков вещей (как поддерживавшихся ранее, так и новых)
Вещей?
| | |
| |
| 2.2, solardiz (ok), 09:32, 03/07/2012 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Я так и знал, что это слово не понравится. Мне тоже не нравится. Предложите лучшее, охватывающее такие, извиняюсь, вещи как обычные хеши паролей (например, от Invision Power Board 2), trip-коды, файлы менеджеров паролей, RAR-архивы, Office-документы, WPA-PSK, VNC challenge/response (и это только часть того, что подразумевалось). Знатоки русского - предлагайте - мне это правда пригодится на будущее. :-) Пока у меня лучший вариант - "хешей и шифров" - но и этот вариант мне не нравится.
Кстати, и в английском не всё так просто. JtR сейчас использует свой термин "format" (есть опция --format=такой-то и т.д.), но он мне не нравится. Заменить на hash - будет неправильно в части случаев. Подумываю в 1.8 заменить на cipher, хотя и это тоже криво. Предложите лучшее.
| | |
| |
| 3.8, Аноним (-), 10:23, 03/07/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Объекты подбора ?
Кстати, "форматы" тоже неплохо, по крайней мере то что задумано под опцией "--format" более менее понятно сразу, а вот при hash и cipher потребуется дополнительно выяснять что именно имелось в виду.
| | |
| 3.36, Антон (??), 18:56, 03/07/2012 [^] [^^] [^^^] [ответить]
| +/– |
Почему не object? Понятно, что у всех другие ассоциации, но здесь бы подошло.
| | |
| |
| 4.42, solardiz (ok), 02:41, 04/07/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Почему не object? Понятно, что у всех другие ассоциации, но здесь бы подошло.
Тогда уж class, что, кстати, соответствует структуре программы (хоть она и на Си). Сейчас для каждого format'а в программе есть свой экземпляр вот такой структуры:
struct fmt_main {
struct fmt_params params;
struct fmt_methods methods;
struct fmt_private private;
struct fmt_main *next;
};
| | |
|
|
|
| 1.7, Аноним (-), 10:23, 03/07/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
поддержка OpenMP-параллелизации расширена еще на пару десятков элементов
| | |
| 1.10, Аноним (-), 10:42, 03/07/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
алоритмов?
(OpenMP поддерживает алгоритмы, обрабатывающие те самые format-ы)
| | |
| |
| |
| 3.34, solardiz (ok), 16:44, 03/07/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> И соответственно --algo.
Я не назвал эти вещи алгоритмами с самого начала (т.е. в 1990-х) потому, что для одного и того же метода хеширования возможны разные алгоритмы реализации - например, для DES в John'е есть не-bitslice и bitslice реализации, а также варианты их настройки/сборки (тоже разные алгоритмы получаются). Это отличие между методом хеширования (математической функцией, т.е. отображением каких-то входных данных на выходные) и конкретным алгоритмом его реализации иногда очень важно не забывать.
В John'е понятие алгоритм используется буквально. У "форматов" есть поле algorithm_name, которое для примера с DES может содержать разные значения в разных сборках.
Но спасибо за совет. Я подумаю.
| | |
| |
| 4.39, Michael Shigorin (ok), 23:54, 03/07/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Я не назвал эти вещи алгоритмами с самого начала (т.е. в 1990-х)
> потому, что для одного и того же метода хеширования возможны разные
> алгоритмы реализации - например, для DES в John'е есть не-bitslice и
> bitslice реализации, а также варианты их настройки/сборки (тоже разные
> алгоритмы получаются).
Ходил-ходил, думал-думал, а что если:
--algo=des/bitslice
(либо какой другой разделитель, чтоб простой разбор однозначным оставался)?
| | |
| |
| 5.41, solardiz (ok), 02:34, 04/07/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Ходил-ходил, думал-думал, а что если: --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) и возможность пользователю указать алгоритм более точно, чем это реально требуется, вряд ли чем-то поможет.
| | |
|
|
|
|
| 1.11, Аноним (-), 10:58, 03/07/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Похоже, пора покупать анти-Wi-Fi-обои. :)
И обклеивать ими весь периметр - и стены, и потолок и пол. :)
| | |
| |
| |
| 3.43, Аноним (-), 05:18, 04/07/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Сделай доступ по маку и не парься
Ну конечно же, хакер крякающий хеши на GPU - полный дебил и мак отснифать и установить у себя на сетевке такой же - совершенно не в состоянии. А может быть, секрет в том что не надо других судить по себе?
| | |
|
|
| 1.12, Аноним (-), 11:20, 03/07/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
solardiz, поддержка WPA-PSK1/2 для подбора по словарю и брутфорса или только по словарю?
Спасибо.
| | |
| |
| 2.17, Аноним (-), 12:48, 03/07/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Потрошитель. Да-да, вы правильно его боитесь - используйте сложные пароли.
| | |
|
| 1.16, Аноним (-), 12:47, 03/07/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> На GPU от AMD пока результаты более скромные.
Что-то недооптимизили явно.
| | |
| |
| 2.18, Аноним (-), 13:15, 03/07/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да, проблема очевидно в коде. Биткоины АМД считаю сильно быстрее НВИДИА.
| | |
| |
| 3.23, Аноним (-), 14:14, 03/07/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Да, проблема очевидно в коде. Биткоины АМД считаю сильно быстрее НВИДИА.
Ну да. SHA-256 у них что-то совсем позорный на фоне майнеров коинов вышел. Еще hashkiller хеши на AMD очень быстро крушит, и сорец есть. Так что сорц в руки авторам риппера, пусть изучают что недооптимизили.
| | |
| |
| 4.26, Аноним (-), 15:28, 03/07/2012 [^] [^^] [^^^] [ответить]
| +/– |
А не настораживает то, что это практически все программы которые вообще имеет смысл на AMD картах ускорять? Все остаольное GPU- подобное исключительно на нвидиях крутят. Подсказка: Не все так хорошо с вычислениями у AMD, за исклбчением специально отобранных частных случаев.
| | |
| |
| 5.44, Аноним (-), 05:21, 04/07/2012 [^] [^^] [^^^] [ответить]
| +/– |
> нвидиях крутят. Подсказка: Не все так хорошо с вычислениями у AMD,
> за исклбчением специально отобранных частных случаев.
У нвидии относительно мало относительно шустрых ядер. Смысл этого решения мне вообще не понятен - ни два, ни полтора получается. Не параллелящиеся алгоритмы проще гонять на CPU - они еще высокочастотнее и отдельно взятое ядро там намного круче. А сильно параллелящиеся - на амд лучше будут. В результате нвидии остается галимый пиар да какие-то экзотичные виды вычислений.
| | |
|
| 4.29, solardiz (ok), 16:04, 03/07/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> 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 миллиарда, соответственно.
| | |
| |
| 5.45, Аноним (-), 05:33, 04/07/2012 [^] [^^] [^^^] [ответить] | +/– | Кстати да, у hashkill с этим тоже некоторые проблемы Насколько я понял - он дал... большой текст свёрнут, показать | | |
| |
| 6.50, solardiz (ok), 15:50, 04/07/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
BFI_INT раньше надо было патчить в бинарный kernel (многие прописывали в исходник amd_bitalign(), а затем патчили бинарник поиском с заменой) или же программировать на уровне IL (как делали в ElcomSoft). Мы же на этот праздник опоздали, нынче bitselect() транслируется в BFI_INT без всяких сложностей. Его и используем.
> если сравнивать результаты sha1 и sha256 влобовую с иными реализациями - что-то невкусно. При нужде распотрошить влобовую sha1 или sha256 я пожалуй hashkill поюзаю.
Конечно, или Cryptohaze Multiforcer - если говорить об Open Source. Авторы того и другого - у нас в гостях в списке рассылки john-dev, мы понемногу обмениваемся опытом.
"Быстрые" хеши на GPU - это пока не к John'у. Не всё сразу.
| | |
|
| 5.54, solardiz (ok), 02:24, 09/07/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Поправка: приведенный мной ранее пересчет с 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 миллиарда.
| | |
|
|
|
| 2.31, solardiz (ok), 16:19, 03/07/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Что-то недооптимизили явно.
Конечно. Но не факт, что конкретно для 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).
| | |
| |
| 3.46, Аноним (-), 05:46, 04/07/2012 [^] [^^] [^^^] [ответить] | +/– | Насчет sha512crypt ничего не скажу мне он как-то не требовался , а вот гольный ... большой текст свёрнут, показать | | |
| |
| 4.51, solardiz (ok), 16:16, 04/07/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Да, это мы в курсе (не о конкретных майнерах, а в целом). 5770/6770 - пожалуй, оптимальный выбор по производительности за доллар, если учитывать только стоимость самих карточек. "Топовая нвидия" всё-таки, кажется, дотягивает до примерно такой же производительности по этим хешам - т.е. GTX 580 будет близко, GTX 590 будет быстрее (два чипа) - конечно, за гораздо бОльшие деньги. (GTX 680 будет медленнее, но это другое.)
Для sha512crypt регистров действительно не хватает. Используется локальная память. С глобальной вышло бы еще хуже - например, когда мы поначалу реализовали bcrypt на глобальной памяти, HD 7970 отставал от FX-8120 вдвое, хотя "теоретически" (если бы не скорость доступа к памяти) мог бы использовать все вычислительные ресурсы. Когда мы перевели его на использование LDS, при этом сознательно отказавшись даже от попытки использовать все вычислительные ресурсы (т.к. объема LDS могло хватить максимум на четверть), скорость возрасла вдвое (т.е. до скорости CPU). В случае sha512crypt и тем более SHA-512 всё далеко не так плохо (как с bcrypt), но и далеко не так хорошо как с SHA-256 и "меньшими".
| | |
|
|
|
| |
| 2.24, Аноним (-), 14:15, 03/07/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Шел 2012 год...
...вычисления на GPU захватывали планету, делая казавшиеся надежными еще вчера пароли делом полудня брутфорса на GPU...
| | |
|
| 1.21, dq0s4y71 (??), 14:06, 03/07/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Также, появилась поддержка ряда других возможностей: ... KeePass 1.x,
То есть, он теперь кипассовские базы данных ломать умеет??
Кстати, если он умеет KeePass 1.x, то он умеет и KeePass 2.x - это две параллельные ветки с одинаковым форматом БД.
| | |
| |
| 2.32, solardiz (ok), 16:22, 03/07/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Кстати, если он умеет KeePass 1.x, то он умеет и KeePass 2.x
Там есть отличия. Поддержка KeePass 2.x появится в ближайшее время (уже есть в git).
| | |
|
| 1.22, Аноним (-), 14:13, 03/07/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну наконец-то. Заждался. Несколько лет не пользуюсь этой программой как раз из-за отсутствия OpenCL/CUDA. Теперь попробую.
| | |
| |
| 2.33, solardiz (ok), 16:32, 03/07/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> А чем отличается стандартный Джон от "community-enhanced"?
Возможностями, объемом и качеством кода. В "community-enhanced" (или -jumbo) новый код включается очень легко, даже если он выглядит противно. ;-) В результате, там поддерживается более 100 различных "форматов" (хешей и шифров, алгоритмов - см. дискуссию о словах), теперь есть поддержка GPU, есть многие другие специфические возможности. В основной ветке же поддерживается только базовый набор хешей, используемых на Unix-системах, и лишь еще несколько других, часть оптимизаций отсутствует, но зато качество кода выше. С точки зрения разработки, основная ветка задает структуру программы и интерфейс для "форматов", а также базовый набор возможностей. Ветка -jumbo не является форком, а базируется на основной ветке (т.е. при выходе нового релиза в основной ветке, -jumbo переносится на эту кодовую базу).
| | |
|
| 1.37, oraerk (ok), 20:39, 03/07/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Есть баг с конвертацией airodump capture в формат john, воспроизводится так:
1) Качаем: http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=view&target=wpa или используем любую другую капчу с успешным eapol, проверял на своей wifi сетке.
2) Конвертируем в формат hccap. Либо тулзой cap2hccap tool, либо на сайте https://hashcat.net/cap2hccap/ (результаты одинаковые, файлы побайтно получаются одинаковые)
3) Запускаем hccap2john на файле .hccap.
4) Валится ошибка "hccap2john: hccap2john.c:75: process_file: Assertion 'bytes==392' failed."
Прошу прощения, что пишу тут, но я так и не понял, каким образом правильно постить баги по данной программе. Багтрекера нет, или я плохо искал?
| | |
| |
| 2.40, solardiz (ok), 02:15, 04/07/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Большое спасибо за баг-репорт. Проверим, исправим. Конкретно поддержку WPA-PSK реализовал Lukas в рамках еще продолжающегося GSoC 2012 - так что ему и исправлять. ;-) Багтрекера действительно нет. На данный момент о багах лучше всего сообщать в список рассылки john-users.
| | |
| 2.53, solardiz (ok), 09:58, 07/07/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Мне оказалось проще сразу исправить самому. Вот патч:
http://www.openwall.com/lists/john-dev/2012/07/07/3
Хотя, если не исправлять другие мелочи, достаточно просто тот assert() выкинуть - он ошибочный.
Для wpa-Induction.pcap пароль Induction подобрался на HD 7970 по all.lst с --rules чуть больше, чем за минуту (при этом первые секунд 20 там уходят на self-test).
| | |
|
| |
| 2.48, solardiz (ok), 15:29, 04/07/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Надо установить 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.
| | |
| |
| 3.49, dq0s4y71 (??), 15:47, 04/07/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Спасибо за обстоятельный ответ. Требование OpenSSL 0.9.7 действительно проглядел - оно там набрано мелким шрифтом.
Необходимость пересборки возникла потому, что у вас на главной странице Джона не выложены бинарники jumbo-6, только jumbo-5. Бинарники jumbo-6 нашёл на другой странице: http://openwall.info/wiki/john/custom-builds Попробую их.
| | |
| |
| 4.52, solardiz (ok), 16:28, 04/07/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Бинарники jumbo-6 нашёл на другой странице: http://openwall.info/wiki/john/custom-builds Попробую их.
Да, их Robert собрал уже после выхода jumbo-6, а я еще не успел на них посмотреть и придать им чуть более официальный статус (хотя до того, чтобы подписать такую сборку нашим ключом, дело всё равно не дойдет). Пока что под Windows сборка jumbo-5 - более официальная и, вероятно, останется такой до выхода и сборки jumbo-7.
| | |
|
|
|
| 1.55, user (??), 22:27, 10/07/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А пароли от pgp/gpg ключей сабж умеет подбирать? И, если нет, планируется ли такая фича в перспективе?
| | |
| |
| 2.56, solardiz (ok), 09:52, 11/07/2012 [^] [^^] [^^^] [ответить]
| +/– |
Пока нет (разве что через --stdout и самодельный скрипт). Планируется. Голос зачтен.
| | |
| |
| 3.57, user2 (ok), 23:28, 11/07/2012 [^] [^^] [^^^] [ответить]
| +/– |
 >через --stdout и самодельный скрипт
Тогда на I/O задержек дофига наберется, или я что-то недопонимаю? Можно попробовать Джона соединить с libgpgme, но это уже не скрипт получится.
>Планируется. Голос зачтен.
Не от членов профсоюза пожелания тоже рассматриваются? А то, их есть у меня:).
7zip. Ну это понятно.
Из экзотики, steghide. (Помнится, еще задолго до всяких шпионских скандалов с рыжими тетками, мы с собутыльниками на форуме в городской локалке говнофотки выкладывали, а внутри оставляли друг другу сообщения.) Штука нераспространенная, и скорее всего мало кому интересна. С другой стороны там 15 криптоалгоритмов, и может кого с технической точки зрения заинтересует.
Truecrypt. Не как 7zip, но достаточно популярен и известен. Только, кроме обычного перебора паролей, еще интересна такая фича. Truecrypt, дополнительно к паролю может использовать файловый ключ. Так вот, из заданного каталога или списка взять файлы и подставлять их вместе с паролями. Используется не больше одного мегабайта от начала файла. Возможно есть смысл загонять их в память, и потом уже прокручивать.
Не знаю, станет ли кто заморачиваться всем этим. По крайней мере, думаю, что от запроса хуже не будет.
| | |
| |
| 4.58, solardiz (ok), 23:51, 11/07/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Через --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 - подумаем. Спасибо за напоминание.
| | |
| |
| 5.59, user2 (ok), 01:00, 12/07/2012 [^] [^^] [^^^] [ответить]
| +/– | |
>Через --stdout и скрипт будет не быстро, но вряд ли для PGP/GPG выйдет такая уж высокая скорость и при работе напрямую.
Интересно, получается у PGP еще большой запас прочности. Не только у зашифрованных данных, но и у самого ключа.
>Про файловые ключи я не знал; не знаю планирует ли Dhiru что-то по их поводу делать - вряд ли.
Если вы общаетесь, может стоит ему предложить? А то вдруг, он тоже не подумал. Пусть даже и не сразу реализовывать, но как задел на будущее.
Не очень понимаю, что такое outguess. В steghide используются криптографические алгоритмы - aes, serpent, gost и т. д. А outguess - это просто размещение в файл, или шифрование также есть?
| | |
| |
| 6.60, solardiz (ok), 13:56, 12/07/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Интересно, получается у PGP еще большой запас прочности. Не только у зашифрованных данных, но и у самого ключа.
Это не та мысль, которую я хотел передать. Я ожидаю, что скорость будет разной для разных типов ключей. Конкретнее можно будет сказать только уже реализовав.
Говоря о временном варианте с --stdout, он может работать для скоростей до нескольких миллионов паролей в секунду, что не мало. Если скрипт будет вынужден запускать программу на каждый пароль отдельно (зависит от программы), это даст ограничение на уровне порядка одной тысячи в секунду. Вероятно, с правильным скриптом, запуска gpg на каждый вариант passphrase удастся избежать, например, используя опцию --edit-key и команду passwd там. При этом мы, возможно, упремся уже в эффективность реализации в gpg (которая, конечно, для этой задачи не оптимизировалась). Это если ограничиваться временными вариантами без правки программ - ни встроенной реализации в John'е, ни изменений в GnuPG.
> Если вы общаетесь, может стоит ему предложить?
Про файловые ключи в TrueCrypt я могу упомянуть при случае.
> А outguess - это просто размещение в файл, или шифрование также есть?
Я ссылался на stegbreak от того же автора и расположенный на том же сайте, а не на сам outguess. Но раз вопрос задан - в outguess есть примитивное шифрование с помощью RC4.
| | |
| |
| 7.61, user2 (ok), 23:38, 12/07/2012 [^] [^^] [^^^] [ответить]
| +/– | |
>Я ссылался на stegbreak от того же автора и расположенный на том же сайте, а не на сам outguess.
Ну да, я просто контекст полез там смотреть.
Спасибо за ответы!
| | |
|
|
|
|
|
|
| 1.63, Аноним (63), 12:40, 24/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Поиогите с утановкой. Только начал в программме разбираться поставить не могу ошибки на dynamic_fmt.c:6709 eror: 'sha_ctx' undeclared ... и таких много ...
| | |
| |
| 2.64, solardiz (ok), 13:58, 28/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
Надо установить OpenSSL. В дистрибутивах это обычно "development" под-пакет, который ставится отдельно. Например, "apt-get install libssl-dev" в Debian/Ubuntu.
| | |
|
|
