Вышел John the Ripper 1.7.6 с поддержкой параллелизации
Вышла новая версия 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.
© OpenNet
