Вышел (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-х годов.
Новые логические выражения на 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 до ...URL: http://www.openwall.com/lists/john-users/2011/06/22/1
Новость: http://www.opennet.me/opennews/art.shtml?num=30984
solardiz, неужели DES/3DES все еще актуальны для хешей паролей в 2011 году ?
> неужели DES/3DES все еще актуальны для хешей паролей в 2011 году ?3DES никогда не был (не для хешей).
DES-based crypt(3) еще актуален - не столько для админов серверов (им надо исправлять настройки), сколько для тех кто занят compliance'ом (PCI DSS и т.п.) и pentesting'ом. Вон, недавно одна крупная международная компания, купившая JtR Pro, консультировалась со мной по настройке ежемесячного аудита DES-based crypt(3) хешей на паре сотен Solaris'овых серверов для соответствия PCI DSS. Для реальной безопасности - толку мало - во всяком случае, это не лучшая трата времени (лучше бы исправить настройки). Но спрос есть, в том числе коммерческий.
Также, иногда утекают и публикуются базы паролей, хешированных DES-based crypt(3) - например, Gawker. Эти пароли - полезное дополнение для оптимизации алгоритмов перебора (.chr файлы, правила).
спасибо за уточнение )
впрочем, "никогда" это все же не совсем верно, в RedHat 4.0 (1996 год) применялись 3DES хеши для пароля, причем всё было открыто в /etc/passwd и John the Ripper тогда уже существовал ;)
> впрочем, "никогда" это все же не совсем верно, в RedHat 4.0 (1996 год) применялись 3DES хеши для пароляТы плохо помнишь. Там был обычный DES-based crypt(3), как и на Slackware 3.x того же времени. И то и другое у меня еще сохранилось (правда, с моими же переделками за те годы, включая BSDI'ные хеши в клоне libc5). ;-)
В Linux-PAM, который начали использовать в Red Hat Linux очень рано, была поддержка bigcrypt, но это никакой не 3DES.
времени прошло много, так что могу и уже не помнить DES там был или 3DES, а вот слака достаточно быстро перешла на использование shadow и MD5 passwords, blowfish тогда тоже уже был как альтернатива, но от Вас я брала только патчи на ядро, тогда еще 2.2 ;) менять crypt было уж слишком для меня )
Надеюсь, не обидел обращением на ты - привык еще с фидо и т.п. Ко мне тоже можно на ты, хотя можно и по-всякому.По теме: во всех известных мне crypt()'ах на основе DES применяется почти одинаковая модификация DES - для реализации salt'ов. (Собственно DES получается лишь при нулевом salt'е. Для всех других значений salt'а - это не совсем DES.) Отличаются они размером salt'ов (12 или 24 бита), количеством итераций модифицированного-DES (25, либо 20+5 на две половинки в crypt16, либо переменное количество в BSDI), отсутствием или наличием поддержки паролей длиннее 8 символов и способом ее реализации (crypt16 vs. bigcrypt). 3DES там ни при чем.
Но это действительно уже почти история.
> Скорость подбора SSH-ключей на одном компьютере с поддержкой OpenMP составляет сотни тысяч вариантов парольной фразы в секундуНепонятно написано, подбирался закрытый ключ по заданному открытому, или по заданной паре открытый / шифрованный закрытый подбирался пароль к последнему?
> подбирался закрытый ключ по заданному открытому, или по заданной паре открытый / шифрованный закрытый подбирался пароль к последнему?Подбирается парольная фраза к шифрованному закрытому ключу. Высокая скорость перебора означает, что такие фразы надо делать более сложными, чем типичные пароли: http://openwall.info/wiki/internal/ssh (А также то, что разработчикам OpenSSH есть что улучшить. Они в курсе.)
А какое шифрование не брутфорсится на видеокартах?
Blowfish, и соответственно bcrypt, не реализуется на нынешних видеокартах эффективно: http://www.golubev.com/blog/?p=94
Вроде автор блоуфиша сам писал, что не надо его юзать. Туфиш юзайте.
> Вроде автор блоуфиша сам писал, что не надо его юзать. Туфиш юзайте.Twofish - более новая разработка, финалист в конкурсе на AES. Как шифр, он может быть лучше. Но это не означает, что с Blowfish какие-то проблемы, а даже если бы и были, это почти наверняка не влияло бы на использование для хеширования паролей. Так что просто так переделывать bcrypt с Blowfish на Twofish нет никакого смысла. Если что-то в этой области делать, то совсем другое:
http://www.openwall.com/lists/crypt-dev/2011/04/05/2
http://www.openwall.com/lists/crypt-dev/2011/05/09/1
>> Вроде автор блоуфиша сам писал, что не надо его юзать. Туфиш юзайте.
> Twofish - более новая разработка, финалист в конкурсе на AES.Сейчас у него на сайте роюсь,... где-то там читал...
---
Ладно, вот скажи как криптоаналитик, криптоаналитику, =)
когда правительства разрешать шифры с более чем 512-битным
секретным ключом?
> Сейчас у него на сайте роюсь,... где-то там читал...Так я не спорю. Да, авторы Twofish рекомендуют использовать Twofish, а не Blowfish, для новых разработок. Но не по причине "взлома" Blowfish, которого не было, и который, если бы и был, не относился бы к этой теме.
> Ладно, вот скажи как криптоаналитик
Я не считаю себя криптоаналитиком. Я разбираюсь в том, как (не) применять криптографические примитивы и т.п., но я не возьмусь, например, за криптоанализ какого-либо блочного шифра, или во всяком случае не как специалист.
> когда правительства разрешать шифры с более чем 512-битным секретным ключом?
Это тоже должно быть смешно? Давай просто закроем эту ветку.
> когда правительства разрешать шифры с более чем 512-битнымсекретным ключом?
А они запрещены? Обычно очень длинный ключ не используют сугубо по практическим соображениям: шифрование это наука о том как заменить большой секрет маленьким. Тем более что если криптоалгоритм реализован качественно и упростить его не удалось, перебрать 2^512 значений попросту невозможно чисто физически: если на элементарную операцию расходуется хоть какая-то кроха энергии, при 2^512 тебе не хватит энергии во всей вселенной :). По грубым прикидкам, даже квантовых компьютеров можно не бояться уже с 256-битным ключом. А с 512-битным - солнце погаснет раньше чем его подберут.
>Вроде автор блоуфиша сам писал, что не надо его юзать. Туфиш юзайте.Дык это вроде ему АНБ такую рекламу проплатило?
В дополнение к моему предыдущему ответу, на видеокартах также не реализуются эффективно sequential memory-hard functions: http://www.tarsnap.com/scrypt.htmlКоличество thread'ов и их быстродействие ограничиваются объемом памяти и пропускной способностью шины памяти видеокарты. Например, если на компьютере можно позволить себе потратить 512 MB памяти на одну операцию вычисления ключа (key derivation), и причем уже через несколько секунд эта память будет возвращена системе, то на видеокарте с 1 GB памяти поместится всего лишь 2 таких параллельных вычисления.
Было бы круто. Лет ...цать назад. А что, кто-то еще не выбросил DES на помойку? Он же уже давно тупым перебором на небольшом кластере за неделю крякается, улучшение на еще сколько-то процентов мало что в этом меняет.
> ... DES на помойку? Он же уже давно тупым перебором на небольшом кластере за неделю крякаетсяЧистый DES - да. А те же crypt(3) хеши на основе DES - уже не тупым перебором и/или не всего набора возможных паролей (а лишь части). Если неделю умножить на 25 итераций DES и на 4096 salt'ов (т.е. если задача - подобрать все пароли к базе из хотя бы тысяч хешей) - то получим почти 2000 лет. Обычно задача так не ставится, да и "неделя" может быть сокращена во много раз на более подходящем железе, но все же отличие DES от DES-based crypt(3) есть существенное. Из более реальных задач - выявление паролей, не соответствующих требованиям - см. мой комментарий выше. Также, не у каждого аудитора (на соответствие требованиям PCI DSS и т.п.) всегда есть под рукой кластер.
Модификация crypt(3) в BSDI, а также FreeSec (код, присутствующий в основных *BSD, а также в недавних версиях PHP), поддерживает настраиваемое количество итераций DES и не имеет ограничения на длину пароля. Умолчание в BSDI было 725 итераций (т.е. в 29 раз медленнее обычного). В 1998 году, незадолго до ухода на bcrypt, я выставлял на системах 20 тысяч итераций. Такие хеши довольно редки, но они встречаются. phpass их использует, когда CRYPT_BLOWFISH нет, а CRYPT_EXT_DES есть (названия в терминах PHP). (Количество итераций он выставляет в тысячи. Конкретное количество зависит от настроек приложения.) JtR их поддерживает (с недавними изменениями - чуточку быстрее).
Также, DES обладает некоторыми хорошими свойствами для аппаратных (FPGA, ASIC) и программных реализаций (bitslice) - маленький размер, эффективное использование LUT'ов (в частности, на Virtex-6), масштабируемость на любую длину SIMD вектора (благодаря эффективным bitslice реализациям). А маленький размер ключа и блока корректируются способом использования. Мы всерьез рассматриваем DES как возможный компонент для нового метода хеширования паролей (см. мои ссылки на crypt-dev). AES и SHA-2 сложно составить конкуренцию DES, когда речь идет о том какую производительность мы получим на один FPGA-чип в сравнении с реализацией на CPU.
> А что, кто-то еще не выбросил DES на помойку?Solaris хотя бы. Возможно и еще какой некроЫнтерпрайз.
Ошибаешься, анон. В Солярисе это дефолтный алгоритм, но _не единственный_. Уже два года как поддерживается не только MD4 и BF, но и SHA256 и SHA512. Поскольку Солярис сертифицирован на FIPS-140-2.
> Ошибаешься, анон. В Солярисе это дефолтный алгоритм, но _не единственный_. Уже два
> года как поддерживается не только MD4 и BF, но и SHA256
> и SHA512. Поскольку Солярис сертифицирован на FIPS-140-2.Опечатался. MD5, конечно же.