https://www.opennet.ru/openforum/vsluhforumID3/78307.html Вышел (http://www.openwall.com/lists/john-users/2011/06/22/1) релиз John the Ripper 1.7.8 (http://www.openwall.com/john/), включающий новые, упрощенные логические выражения, реализующие так называемые S-box'ы (S-блоки, блоки подстановок) в блочном шифре DES, на основе которого построены также некоторые методы хеширования паролей, включая традиционный crypt(3), используемый в Unix начиная с конца 1970-х годов.<br><br><br>Новые логические выражения на 17% проще известных ранее лучших результатов для тех же наборов логических операций. В частности, для набора {AND, OR, XOR, NOT, AND-NOT}, соответствующего типичным процессорам x86 (MMX, SSE2, AVX) и RISC, результат улучшен с 53.375 до 44.125 логических операций на S-box (в среднем для всех восьми S-box'ов). Для набора, содержащего операцию выбора битов, присутствующую на процессорах Cell, PowerPC с AltiVec, будущих x86 процессорах от AMD (начиная с Bulldozer) с расширениями XOP, а также новых видеокартах от ATI/AMD, результат улучшен с 39.875 до ...<br><br>URL: http://www.ope https://www.opennet.ru/openforum/vsluhforumID3/78307.html#23 Tue, 28 Jun 2011 15:25:27 GMT &gt; Ошибаешься, анон. В Солярисе это дефолтный алгоритм, но _не единственный_. Уже два <br>&gt; года как поддерживается не только MD4 и BF, но и SHA256 <br>&gt; и SHA512. Поскольку Солярис сертифицирован на FIPS-140-2.<br><br>Опечатался. MD5, конечно же.<br> https://www.opennet.ru/openforum/vsluhforumID3/78307.html#22 Tue, 28 Jun 2011 15:24:57 GMT Ошибаешься, анон. В Солярисе это дефолтный алгоритм, но _не единственный_. Уже два года как поддерживается не только MD4 и BF, но и SHA256 и SHA512. Поскольку Солярис сертифицирован на FIPS-140-2.<br> https://www.opennet.ru/openforum/vsluhforumID3/78307.html#21 Sat, 25 Jun 2011 21:40:06 GMT &gt;Вроде автор блоуфиша сам писал, что не надо его юзать. Туфиш юзайте.<br><br>Дык это вроде ему АНБ такую рекламу проплатило?<br> https://www.opennet.ru/openforum/vsluhforumID3/78307.html#20 Sat, 25 Jun 2011 16:27:43 GMT В дополнение к моему предыдущему ответу, на видеокартах также не реализуются эффективно sequential memory-hard functions: http://www.tarsnap.com/scrypt.html<br><br>Количество thread'ов и их быстродействие ограничиваются объемом памяти и пропускной способностью шины памяти видеокарты. Например, если на компьютере можно позволить себе потратить 512 MB памяти на одну операцию вычисления ключа (key derivation), и причем уже через несколько секунд эта память будет возвращена системе, то на видеокарте с 1 GB памяти поместится всего лишь 2 таких параллельных вычисления.<br> https://www.opennet.ru/openforum/vsluhforumID3/78307.html#19 Sat, 25 Jun 2011 14:32:37 GMT &gt; ... DES на помойку? Он же уже давно тупым перебором на небольшом кластере за неделю крякается<br><br>Чистый DES - да. А те же crypt(3) хеши на основе DES - уже не тупым перебором и/или не всего набора возможных паролей (а лишь части). Если неделю умножить на 25 итераций DES и на 4096 salt'ов (т.е. если задача - подобрать все пароли к базе из хотя бы тысяч хешей) - то получим почти 2000 лет. Обычно задача так не ставится, да и "неделя" может быть сокращена во много раз на более подходящем железе, но все же отличие DES от DES-based crypt(3) есть существенное. Из более реальных задач - выявление паролей, не соответствующих требованиям - см. мой комментарий выше. Также, не у каждого аудитора (на соответствие требованиям PCI DSS и т.п.) всегда есть под рукой кластер.<br><br>Модификация crypt(3) в BSDI, а также FreeSec (код, присутствующий в основных *BSD, а также в недавних версиях PHP), поддерживает настраиваемое количество итераций DES и не имеет ограничения на длину пароля. Умолчание в BSDI было 725 итераций (т.е. в 2 https://www.opennet.ru/openforum/vsluhforumID3/78307.html#18 Sat, 25 Jun 2011 10:25:07 GMT &gt; А что, кто-то еще не выбросил DES на помойку?<br><br>Solaris хотя бы. Возможно и еще какой некроЫнтерпрайз.<br> https://www.opennet.ru/openforum/vsluhforumID3/78307.html#17 Sat, 25 Jun 2011 10:24:31 GMT &gt; когда правительства разрешать шифры с более чем 512-битным<br><br>секретным ключом?<br>А они запрещены? Обычно очень длинный ключ не используют сугубо по практическим соображениям: шифрование это наука о том как заменить большой секрет маленьким. Тем более что если криптоалгоритм реализован качественно и упростить его не удалось, перебрать 2^512 значений попросту невозможно чисто физически: если на элементарную операцию расходуется хоть какая-то кроха энергии, при 2^512 тебе не хватит энергии во всей вселенной :). По грубым прикидкам, даже квантовых компьютеров можно не бояться уже с 256-битным ключом. А с 512-битным - солнце погаснет раньше чем его подберут.<br> https://www.opennet.ru/openforum/vsluhforumID3/78307.html#16 Sat, 25 Jun 2011 10:15:41 GMT Было бы круто. Лет ...цать назад. А что, кто-то еще не выбросил DES на помойку? Он же уже давно тупым перебором на небольшом кластере за неделю крякается, улучшение на еще сколько-то процентов мало что в этом меняет. <br> https://www.opennet.ru/openforum/vsluhforumID3/78307.html#15 Fri, 24 Jun 2011 21:25:49 GMT &gt; Сейчас у него на сайте роюсь,... где-то там читал...<br><br>Так я не спорю. Да, авторы Twofish рекомендуют использовать Twofish, а не Blowfish, для новых разработок. Но не по причине "взлома" Blowfish, которого не было, и который, если бы и был, не относился бы к этой теме.<br><br>&gt; Ладно, вот скажи как криптоаналитик<br><br>Я не считаю себя криптоаналитиком. Я разбираюсь в том, как (не) применять криптографические примитивы и т.п., но я не возьмусь, например, за криптоанализ какого-либо блочного шифра, или во всяком случае не как специалист.<br><br>&gt; когда правительства разрешать шифры с более чем 512-битным секретным ключом?<br><br>Это тоже должно быть смешно? Давай просто закроем эту ветку.<br>