https://89.19.215.112/openforum/vsluhforumID3/67994.html Вышла (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 там поддерживается тоже).<br><br><br>Эффективность этого подхода была проверена еще до релиза на 4- и 8-ядерн...<br><br>URL: http://www.ope https://89.19.215.112/openforum/vsluhforumID3/67994.html#23 Mon, 28 Jun 2010 00:17:18 GMT Вот патч и тесты производительности при параллелизации bitslice DES в JtR, тоже с OpenMP-директивами:<br><br>http://www.openwall.com/lists/john-users/2010/06/27/1<br><br>Лучший результат - пока 17M c/s для традиционного crypt(3).<br><br>Под серверной загрузкой (даже всего лишь 10%), к сожалению, эффективность OpenMP-подхода для не-медленных хешей оказывается низка (о причинах см. по той же ссылке, выше). Так что этот новый патч - для использования на личных компьютерах или на простаивающих серверах.<br><br>Для медленных хешей, о которых была новость, эта проблема с OpenMP-подходом (реакция на другую загрузку) гораздо менее выражена.<br> https://89.19.215.112/openforum/vsluhforumID3/67994.html#22 Wed, 16 Jun 2010 11:32:24 GMT &gt;Да будет Вам известно, что OpenCL умеет работать не только на GPU <br><br>Это не противоречит тому, чтобы начать с использования OpenMP, который уже есть на свежих системах "из коробки" и который требует меньше изменений кода. Причем некоторые высокоуровневые изменения для разных способов параллелизации окажутся общими.<br> https://89.19.215.112/openforum/vsluhforumID3/67994.html#21 Wed, 16 Jun 2010 11:17:09 GMT &gt;&gt; но OpenCL был бы уместнее <br>&gt;<br>&gt;Кому как, да и неправильно противопоставлять одно другому. Подробнее "тему GPU" я <br>&gt;прокомментировал здесь: http://www.linux.org.ru/news/security/5006947 <br><br>Да будет Вам известно, что OpenCL умеет работать не только на GPU<br><br> <br>Ждем выхода GNU libOpenCL :)<br> https://89.19.215.112/openforum/vsluhforumID3/67994.html#20 Wed, 16 Jun 2010 10:27:11 GMT &gt; но OpenCL был бы уместнее <br><br>Кому как, да и неправильно противопоставлять одно другому. Подробнее "тему GPU" я прокомментировал здесь: http://www.linux.org.ru/news/security/5006947<br> https://89.19.215.112/openforum/vsluhforumID3/67994.html#19 Wed, 16 Jun 2010 10:18:12 GMT &gt; OpenMPI? :]<br><br>Нет, именно OpenMP. Не путать - это совершенно разные вещи.<br><br>Поддержка MPI (в том числе OpenMPI) была и есть с помощью патча, но она неудобна в использовании (особенно в отношении прерывания/восстановления сессий).<br><br>http://openwall.info/wiki/john/parallelization#Extended-efforts<br> https://89.19.215.112/openforum/vsluhforumID3/67994.html#18 Wed, 16 Jun 2010 07:50:10 GMT Я знаю 2 программы:<br>1). Переборщики паролей.<br>2). Программа для участия в проекте SETI.<br>И там, и там, скорость вычислений выше раз в 10. Надо CUDA.<br>Жаль, но не все алгоритмы возможны для перебора на видеокарте. Только некоторые.<br> https://89.19.215.112/openforum/vsluhforumID3/67994.html#17 Wed, 16 Jun 2010 05:52:32 GMT лучше бы cuda прицепили<br> https://89.19.215.112/openforum/vsluhforumID3/67994.html#16 Wed, 16 Jun 2010 04:34:30 GMT А много ли софта использующего видяху для вычислений? Было бы не плохо ее нагрузить, а то простаивает почем зря...<br> https://89.19.215.112/openforum/vsluhforumID3/67994.html#15 Wed, 16 Jun 2010 03:19:14 GMT В архивах опеннета проскакивала новость о подобном поделии от IBM. На 129 микропроцессоров на одной подложке (1 чисто для управления).<br>