Вышел 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.