The OpenNET Project / Index page

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

Вышел John the Ripper 1.7.6 с поддержкой параллелизации

15.06.2010 16:12

Вышла новая версия John the Ripper - программы для подбора/аудита Unix-паролей (и не только Unix) по их хешам - впервые с официальной поддержкой параллелизации, реализованной с помощью директив OpenMP (требуется GCC 4.2+, 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-ядерных x86-64 и на UltraSPARC T2 (4 ядра, 32 потока). Для bcrypt, на 4-ядерных Core i7 и UltraSPARC T2 ускорение (по сравнению с одним процессом, не поддерживающим параллелизацию) составило от 5.3 до 5.5 раз (оно превышает 4 раза благодаря SMT). На 8-ядерной системе (без SMT), ускорение составило 7.9 раза. Для SHA-crypt на Linux и Solaris и для SunMD5 на Solaris результаты чуть хуже - ускорение около 3.7 раз на 4-ядерных системах. Для обсуждаемых типов хешей и их типичных настроек (количество итераций, которое регулируется системным администратором) речь может идти об ускорении примерно от 200 до 700-1600 проверяемых комбинаций {пользователь, пароль} в секунду. Дальнейшая параллелизация на несколько машин пока что может осуществляться по-старинке (вручную или с MPI).

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

В будущих версиях JtR ожидается расширение поддержки параллелизации и на другие типы хешей - с использованием встроенного оптимизированного кода. Через crypt_r(3) или crypt(3C) такая параллелизация уже работает и для других типов хешей, но для них использовать ее оказывается нерационально из-за низкой эффективности системных реализаций, сводящей на нет преимущество от параллелизации на "всего лишь" 4-8 потоков в сравнении с оптимизированным кодом в JtR, достигающим той же или лучшей скорости на одном потоке. Так что на данный момент эффективная параллелизация доступна лишь для перечисленных: bcrypt, SHA-crypt, SunMD5.

  1. Главная ссылка к новости (http://www.openwall.com/lists/...)
Автор новости: solardiz
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/26972-password
Ключевые слова: password, security, johntheripper
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (22) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, redactor (?), 16:40, 15/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    :)
    классика
    давно о нем слышно небыло
     
  • 1.2, sHaggY_caT (ok), 16:53, 15/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Берегите, люди, хэши...
     
  • 1.3, Zenitur (?), 17:32, 15/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Восьмиядерные процессоры... Видеокарта со 112 потоками! В разы быстрее!
     
     
  • 2.4, User294 (ok), 17:43, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Далеко не все *никсоиды - офигенные геймеры кукующие с распоследней геймерской печкой за штуку баксов :).А так - по такой логике CPU надо вообще выбросить, ведь есть же видеокарты :).
     
     
  • 3.6, аноним (?), 17:55, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А ещё некоторые (не будем показывать пальцем) с дуру закупились t2000-ыми :) Паралельных аппликух которые это понимают так и не появилось, а на обычных оно ниже плинтуса ...

    Вот теперь остаётся им только переделать эти ящики в кракед-фарм и сделать веб-сервис для услуг _по_ ... :)

     
     
  • 4.7, solardiz (ok), 18:06, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > А ещё некоторые (не будем показывать пальцем) с дуру закупились t2000-ыми :) Паралельных аппликух которые это понимают так и не появилось, а на обычных оно ниже плинтуса ...

    Увы, даже с такой "аппликухой", которой JtR начинает быть, они "на уровне плинтуса" - получается сравнение системы, которая потенциально была быстрой несколько лет назад, но стала быстрой по тем меркам лишь сейчас (появился софт), с современными процессорами от Intel...  Вон, 32 потока на T5120 дают примерно такое же быстродействие что один поток на Core i7 - и в пять раз меньше, чем 8 потоков на Core i7.

     
  • 4.14, yet another anonim (?), 05:36, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >А ещё некоторые (не будем показывать пальцем) с дуру закупились t2000-ыми :)
    >Паралельных аппликух которые это понимают так и не появилось, а на
    >обычных оно ниже плинтуса ...
    >
    >Вот теперь остаётся им только переделать эти ящики в кракед-фарм и сделать
    >веб-сервис для услуг _по_ ... :)

    Пинайте разрабов на любых форумах и багрепортных - авось и расшевелятся (а они ужос какие консерваторы!) Вон вендосских манагерия+начальство пинают - и появляются одни за другими, и рекламируют везде свою мультиядерность. А чем мы хуже? :)

     
  • 3.9, Zenitur (?), 00:18, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > распоследней геймерской печкой за штуку баксов

    Для этой цели подходит видеокарта 4-летней давности.

     
     
  • 4.12, yet another anonim (?), 05:12, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И даже бюджетные "стартовые" (которые в деле, хоть и не очень то и холодные - тенденция посл. лет к невиданному ранее нагреву железа, но вполне довольны маленькой тихенькой системой охлаждения) видеокарты с 24-48 ядрами уже дают скорость, как минимум сравнимую и в некоторых местах много бОльшую, чем 8+ ядерные процы (не считая виртуальных ядер). И стоят такие они смешные (особенно если вспомним как оно обстояло лет >5 назад) деньги...
     
     
  • 5.16, Аноним (-), 08:34, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А много ли софта использующего видяху для вычислений? Было бы не плохо ее нагрузить, а то простаивает почем зря...
     
     
  • 6.18, Zenitur (?), 11:50, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Я знаю 2 программы:
    1). Переборщики паролей.
    2). Программа для участия в проекте SETI.
    И там, и там, скорость вычислений выше раз в 10. Надо CUDA.
    Жаль, но не все алгоритмы возможны для перебора на видеокарте. Только некоторые.
     
  • 3.13, yet another anonim (?), 05:29, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Далеко не все *никсоиды - офигенные геймеры кукующие с распоследней геймерской печкой
    >за штуку баксов :).А так - по такой логике CPU надо
    >вообще выбросить, ведь есть же видеокарты :).

    Логика такая - в будущем не нужны отдельные видеокарты. Должен быть GPU-подобный CPU, вернее CPU-подобный GPU или.. чёрт, крыша может съехать. Ну по крайней мере у нас нет отдельного зрительного мозга, а есть сильно интегрированная, и способная на себя брать многие другие функции, зрительная зона. Суть ведь в том, что и тот считает, и тот, причём как минимум в играх и видео - используют те же данные, многократно обмениваясь ими друг с другом, так зачем их разъединять и урезать связи, если они могут помогать друг другу, делая ту же работу быстрее и с меньшей задержкой, к тому же меньше потребляя? И на памяти можно сэкономить - для дешёвых использовать самую обычную DDR-2\3, для "крутых" - разогнанную, нового техпроцесса, DDR-3\5. Просто так, на всякий случай добавляешь с расчётом на лишний гиг-два. Пусть будут на одном чипе. И мостов меньше, и "басы" отдыхают - система меньше жрёт и греется, и кулер лишний для ПК не нужен\ноутбучный справляется лучше и места больше остаётся. Одни плюсы видятся для обычного компа.
    А пока Cell только, и тот нестандартный, а эти новые гибридные Интеллы, АМД - всего лишь пародия с присунутым недовидеочипом...

     
     
  • 4.15, Ne01eX (??), 07:19, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    В архивах опеннета проскакивала новость о подобном поделии от IBM. На 129 микропроцессоров на одной подложке (1 чисто для управления).
     

  • 1.8, pavlinux (ok), 21:18, 15/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > впервые с официальной поддержкой параллелизации,

    нунаканецта...

    > реализованной с помощью директив OpenMP

    но OpenCL был бы уместнее

     
     
  • 2.10, Michael Shigorin (ok), 00:19, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    OpenMPI? :]
     
     
  • 3.11, pavlinux (ok), 02:01, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >OpenMPI? :]

    Ага, и каждому домой по RoadRunnerу иль хотя бы махонький Ломонософ.

    --------------

    На LVEE 2010 едешь? .... Читать буишь? Помядоры брать? Я в пионерском лагере, теннисный мячик на 60 метров кидал :)

     
  • 3.19, solardiz (ok), 14:18, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > OpenMPI? :]

    Нет, именно OpenMP. Не путать - это совершенно разные вещи.

    Поддержка MPI (в том числе OpenMPI) была и есть с помощью патча, но она неудобна в использовании (особенно в отношении прерывания/восстановления сессий).

    http://openwall.info/wiki/john/parallelization#Extended-efforts

     
  • 2.20, solardiz (ok), 14:27, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > но OpenCL был бы уместнее

    Кому как, да и неправильно противопоставлять одно другому. Подробнее "тему GPU" я прокомментировал здесь: http://www.linux.org.ru/news/security/5006947

     
     
  • 3.21, pavlinux (ok), 15:17, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> но OpenCL был бы уместнее
    >
    >Кому как, да и неправильно противопоставлять одно другому. Подробнее "тему GPU" я
    >прокомментировал здесь: http://www.linux.org.ru/news/security/5006947

    Да будет Вам известно, что OpenCL умеет работать не только на GPU


    Ждем выхода GNU libOpenCL :)

     
     
  • 4.22, solardiz (ok), 15:32, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Да будет Вам известно, что OpenCL умеет работать не только на GPU

    Это не противоречит тому, чтобы начать с использования OpenMP, который уже есть на свежих системах "из коробки" и который требует меньше изменений кода. Причем некоторые высокоуровневые изменения для разных способов параллелизации окажутся общими.

     

  • 1.17, sluge (ok), 09:52, 16/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    лучше бы cuda прицепили
     
  • 1.23, solardiz (ok), 04:17, 28/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот патч и тесты производительности при параллелизации bitslice DES в JtR, тоже с OpenMP-директивами:

    http://www.openwall.com/lists/john-users/2010/06/27/1

    Лучший результат - пока 17M c/s для традиционного crypt(3).

    Под серверной загрузкой (даже всего лишь 10%), к сожалению, эффективность OpenMP-подхода для не-медленных хешей оказывается низка (о причинах см. по той же ссылке, выше). Так что этот новый патч - для использования на личных компьютерах или на простаивающих серверах.

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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