Вышла новая версия John the Ripper

Вышла новая версия John the Ripper

Вышла новая версия John the Ripper, программы для подбора/аудита Unix-паролей (и не только Unix) по их хешам, впервые с официальной поддержкой параллелизации, реализованной с помощью директив OpenMP (требуется GCC 4.2+, Sun Studio или другой компилятор с поддержкой OpenMP).

Вышла новая версия John the Ripper, программы для подбора/аудита Unix-паролей (и не только Unix) по их хешам, впервые с официальной поддержкой параллелизации, реализованной с помощью директив OpenMP (требуется GCC 4.2+, Sun Studio или другой компилятор с поддержкой OpenMP). На данном этапе, OpenMP поддерживается и эффективно работает для "медленных" типов хешей: OpenBSD-подобных на основе Blowfish (алгоритм bcrypt), glibc 2.7+ SHA-crypt, Solaris SunMD5. Для bcrypt используется оптимизированный код (на x86-64 вычисляет по два хеша параллельно на каждый поток). Для 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 ожидается расширение поддержки параллелизма и на другие типы хешей - с использованием имеющегося в JtR оптимизированного кода.

Цифровые следы - ваша слабость, и хакеры это знают.

Подпишитесь и узнайте, как их замести!