Вышла (http://www.openwall.com/lists/announce/2010/06/15/1) новая версия John the Ripper (http://www.openwall.com/john/) - программы для подбора/аудита Unix-паролей (и не только Unix) по их хешам - впервые с официальной поддержкой параллелизации, реализованной с помощью директив OpenMP (требуется GCC 4.2+ (http://openwall.info/wiki/internal/gcc-local-build), Sun Studio или другой компилятор с поддержкой OpenMP). На данном этапе, OpenMP-параллелизация поддерживается и эффективно работает для "медленных" типов хешей - OpenBSD-подобных на основе Blowfish (алгоритм bcrypt), glibc 2.7+ SHA-crypt, Solaris SunMD5. Для bcrypt используется встроенный в JtR оптимизированный код (на x86-64 вычисляет по два хеша параллельно на каждый thread). Для SHA-crypt и SunMD5 пока что используется системная функция crypt_r(3) на glibc или поддерживающая многопоточность crypt(3C) на Solaris (причем SHA-crypt там поддерживается тоже).
Эффективность этого подхода была проверена еще до релиза на 4- и 8-ядерн...URL: http://www.openwall.com/lists/announce/2010/06/15/1
Новость: https://www.opennet.ru/opennews/art.shtml?num=26972
:)
классика
давно о нем слышно небыло
Берегите, люди, хэши...
Восьмиядерные процессоры... Видеокарта со 112 потоками! В разы быстрее!
Далеко не все *никсоиды - офигенные геймеры кукующие с распоследней геймерской печкой за штуку баксов :).А так - по такой логике CPU надо вообще выбросить, ведь есть же видеокарты :).
А ещё некоторые (не будем показывать пальцем) с дуру закупились t2000-ыми :) Паралельных аппликух которые это понимают так и не появилось, а на обычных оно ниже плинтуса ...Вот теперь остаётся им только переделать эти ящики в кракед-фарм и сделать веб-сервис для услуг _по_ ... :)
> А ещё некоторые (не будем показывать пальцем) с дуру закупились t2000-ыми :) Паралельных аппликух которые это понимают так и не появилось, а на обычных оно ниже плинтуса ...Увы, даже с такой "аппликухой", которой JtR начинает быть, они "на уровне плинтуса" - получается сравнение системы, которая потенциально была быстрой несколько лет назад, но стала быстрой по тем меркам лишь сейчас (появился софт), с современными процессорами от Intel... Вон, 32 потока на T5120 дают примерно такое же быстродействие что один поток на Core i7 - и в пять раз меньше, чем 8 потоков на Core i7.
>А ещё некоторые (не будем показывать пальцем) с дуру закупились t2000-ыми :)
>Паралельных аппликух которые это понимают так и не появилось, а на
>обычных оно ниже плинтуса ...
>
>Вот теперь остаётся им только переделать эти ящики в кракед-фарм и сделать
>веб-сервис для услуг _по_ ... :)Пинайте разрабов на любых форумах и багрепортных - авось и расшевелятся (а они ужос какие консерваторы!) Вон вендосских манагерия+начальство пинают - и появляются одни за другими, и рекламируют везде свою мультиядерность. А чем мы хуже? :)
> распоследней геймерской печкой за штуку баксовДля этой цели подходит видеокарта 4-летней давности.
И даже бюджетные "стартовые" (которые в деле, хоть и не очень то и холодные - тенденция посл. лет к невиданному ранее нагреву железа, но вполне довольны маленькой тихенькой системой охлаждения) видеокарты с 24-48 ядрами уже дают скорость, как минимум сравнимую и в некоторых местах много бОльшую, чем 8+ ядерные процы (не считая виртуальных ядер). И стоят такие они смешные (особенно если вспомним как оно обстояло лет >5 назад) деньги...
А много ли софта использующего видяху для вычислений? Было бы не плохо ее нагрузить, а то простаивает почем зря...
Я знаю 2 программы:
1). Переборщики паролей.
2). Программа для участия в проекте SETI.
И там, и там, скорость вычислений выше раз в 10. Надо CUDA.
Жаль, но не все алгоритмы возможны для перебора на видеокарте. Только некоторые.
>Далеко не все *никсоиды - офигенные геймеры кукующие с распоследней геймерской печкой
>за штуку баксов :).А так - по такой логике CPU надо
>вообще выбросить, ведь есть же видеокарты :).Логика такая - в будущем не нужны отдельные видеокарты. Должен быть GPU-подобный CPU, вернее CPU-подобный GPU или.. чёрт, крыша может съехать. Ну по крайней мере у нас нет отдельного зрительного мозга, а есть сильно интегрированная, и способная на себя брать многие другие функции, зрительная зона. Суть ведь в том, что и тот считает, и тот, причём как минимум в играх и видео - используют те же данные, многократно обмениваясь ими друг с другом, так зачем их разъединять и урезать связи, если они могут помогать друг другу, делая ту же работу быстрее и с меньшей задержкой, к тому же меньше потребляя? И на памяти можно сэкономить - для дешёвых использовать самую обычную DDR-2\3, для "крутых" - разогнанную, нового техпроцесса, DDR-3\5. Просто так, на всякий случай добавляешь с расчётом на лишний гиг-два. Пусть будут на одном чипе. И мостов меньше, и "басы" отдыхают - система меньше жрёт и греется, и кулер лишний для ПК не нужен\ноутбучный справляется лучше и места больше остаётся. Одни плюсы видятся для обычного компа.
А пока Cell только, и тот нестандартный, а эти новые гибридные Интеллы, АМД - всего лишь пародия с присунутым недовидеочипом...
В архивах опеннета проскакивала новость о подобном поделии от IBM. На 129 микропроцессоров на одной подложке (1 чисто для управления).
> впервые с официальной поддержкой параллелизации,нунаканецта...
> реализованной с помощью директив OpenMP
но OpenCL был бы уместнее
OpenMPI? :]
>OpenMPI? :]Ага, и каждому домой по RoadRunnerу иль хотя бы махонький Ломонософ.
--------------
На LVEE 2010 едешь? .... Читать буишь? Помядоры брать? Я в пионерском лагере, теннисный мячик на 60 метров кидал :)
> OpenMPI? :]Нет, именно OpenMP. Не путать - это совершенно разные вещи.
Поддержка MPI (в том числе OpenMPI) была и есть с помощью патча, но она неудобна в использовании (особенно в отношении прерывания/восстановления сессий).
http://openwall.info/wiki/john/parallelization#Extended-efforts
> но OpenCL был бы уместнееКому как, да и неправильно противопоставлять одно другому. Подробнее "тему GPU" я прокомментировал здесь: http://www.linux.org.ru/news/security/5006947
>> но OpenCL был бы уместнее
>
>Кому как, да и неправильно противопоставлять одно другому. Подробнее "тему GPU" я
>прокомментировал здесь: http://www.linux.org.ru/news/security/5006947Да будет Вам известно, что OpenCL умеет работать не только на GPU
Ждем выхода GNU libOpenCL :)
>Да будет Вам известно, что OpenCL умеет работать не только на GPUЭто не противоречит тому, чтобы начать с использования OpenMP, который уже есть на свежих системах "из коробки" и который требует меньше изменений кода. Причем некоторые высокоуровневые изменения для разных способов параллелизации окажутся общими.
лучше бы cuda прицепили
Вот патч и тесты производительности при параллелизации bitslice DES в JtR, тоже с OpenMP-директивами:http://www.openwall.com/lists/john-users/2010/06/27/1
Лучший результат - пока 17M c/s для традиционного crypt(3).
Под серверной загрузкой (даже всего лишь 10%), к сожалению, эффективность OpenMP-подхода для не-медленных хешей оказывается низка (о причинах см. по той же ссылке, выше). Так что этот новый патч - для использования на личных компьютерах или на простаивающих серверах.
Для медленных хешей, о которых была новость, эта проблема с OpenMP-подходом (реакция на другую загрузку) гораздо менее выражена.