The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлена хеш-функция BLAKE2, претендующая на роль высокопроизводительной замены MD5 и SHA1

24.12.2012 17:40

Представлена современная криптографическая хеш-функция BLAKE2, не уступающая по производительности MD5, потребляющая на 33% меньше памяти чем SHA-2/SHA-3 и лишённая известных проблем с безопасностью. BLAKE2 является переработанной версией хэш-функции BLAKE, вошедшей в число финалистов конкурса на разработку криптоалгоритмов для стандарта SHA-3. При проектировании BLAKE2 была поставлена задача обеспечения максимальной производительности программной реализации алгоритма с предоставлением высочайшего уровня безопасности.

В итоге, был подготовлен алгоритм значительно превосходящий по надёжности MD5, но близкий к нему по производительности, что делает его пригодным для использования в областях, где в силу своей производительности до сих пор доминируют MD5 и SHA1 - в облачных хранилищах, системах контроля версий, дистрибутивах программного обеспечения, системах выявления вторжений и средствах цифровой экспертизы (digital forensics).

Как и SHA-3 алгоритм BLAKE2 не чувствителен к размеру хэшируемых данных и защищён от всех свойственных SHA-1 и MD5 видов атак, связанных с возникновением коллизий в процессе хэширования. Надёжность алгоритма подтверждена многолетним аудитом, который проводился в процессе оценки претендентов на звание стандарта SHA-3. По словам разработчиков алгоритма, то, что институт NIST в конечном счёте выбрал алгоритм Keccak в качестве стандарта SHA-3 связано с тем, что была поставлена цель использования в SHA-3 алгоритма принципиально отличающегося от SHA-2 с целью наличия запасного варианта в случае выявления уязвимости в одном из алгоритмов. С точки зрения безопасности алгоритмы Keccak и BLAKE находятся на одном уровне, при этом для BLAKE был проведён даже более глубокий криптоанализ, чем для Keccak.

Для использования подготовлены две реализации BLAKE2:

  • BLAKE2b (или просто BLAKE2) - вариант, оптимизированный для 64-разрядных платформ и поддерживающий акселерацию через задействование инструкций NEON для ARM-систем и SSE2, SSSE3, SSE4.1, AVX и XOP для архитектур x86. Размер результирующего хэша может генерироваться в диапазоне от 1 до 64 байт. Доступны две модификации BLAKE2b, позволяющие существенно увеличить производительность за счёт распараллеливания на многоядерных или SIMD процессорах: BLAKE2bp - с поддержкой распараллеливания на 4 потока, и BLAKE2sp - с поддержкой распараллеливания на 8 потоков (используется OpenMP).
  • BLAKE2s - вариант для 8-, 16- и 32-разрядных платформ, позволяющий генерировать хэши размером от 1 до 32 байт.

Реализации доступны как в виде библиотек для различных языков программирования, так и в форме утилиты b2sum, позволяющей из командной строки хэшировать файлы с использованием методов BLAKE2b, BLAKE2s, BLAKE2bp и BLAKE2sp. При проведении теста на системе с процессором Intel Core i7-2630QM (Sandy Bridge 2GHz) была продемонстрирована производительность в 531 мебибайт в секунду (3.59 процессорных циклов на байт), при использовании процессора AMD FX-8150 (Bulldozer 3.6GHz) производительность составила 628 мебибайт в секунду (5.47 процессорных циклов на байт).



  1. Главная ссылка к новости (http://lists.randombit.net/pip...)
  2. OpenNews: Выбран финальный алгоритм для SHA-3
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: blake2, md5, hash, sha, crypt
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (96) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, pavlinux (ok), 19:02, 24/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    > ... Размер результирующего хэша может генерироваться в диапазоне от 1 до 64 байт.

    Хэш в один байт! Коллизии просто невозможны  :)

     
     
  • 2.8, Dron (ok), 19:41, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +13 +/
    Не всегда требуется отсутствие коллизий.
    Для быстрого поиска хеш в один байт очень даже рулит.
     
     
  • 3.15, Аноним (-), 19:52, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Для быстрого поиска хеш в один байт очень даже рулит.

    До тех пор пока какой-нибудь козел не начнет кормить поиск байтами с одинаковым хэшом оптом, сделав быстрый поиск медленным. //По мотивам бага в btrfs :)

     
     
  • 4.18, GentooBoy (ok), 20:05, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Вы так нечего и не поняли, обработка коллизий в btrfs медленная. Сделаете быструю обработку все гуд будет.
     
     
  • 5.23, Аноним (-), 20:54, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Сделаете быструю обработку все гуд будет.

    А вот нифига.

     
     
  • 6.25, Аноним (-), 21:27, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вам виднее.
    Жираф большой, ему видней. (с) В.С.Высоцкий
     
     
  • 7.30, Аноним (-), 22:14, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну вам виднее.
    > Жираф большой, ему видней. (с) В.С.Высоцкий

    Чтобы дорасти до жирафа, достаточно на начальному уровне разобраться в работе хеш-таблиц и понять, что коллизия все равно требует специальной обработки. Даже если ее оптимизировать, все равно это будет значительно медленнее прямого обращения.

     
     
  • 8.45, Аноним (-), 02:46, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Все так и в простершем случаи обработки получим O n , а теперь c смотрим что был... текст свёрнут, показать
     
     
  • 9.74, Аноним (-), 16:05, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Подсказка то, что было с btrfs, можно прекрасно получить и на O n ... текст свёрнут, показать
     
     
  • 10.81, pavlinux (ok), 19:36, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В жопу надо ваш БТРфс засунуть code mkfs btrfs -l32k -n32k -m single dev s... большой текст свёрнут, показать
     
  • 10.94, Аноним (-), 11:52, 26/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    идите дальше холиварте ... текст свёрнут, показать
     
  • 4.41, solardiz (ok), 01:06, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Один из способов защиты от hashDoS - использование криптографической хеш-функции с ключом (keyed hash). BLAKE2 имеет встроенную поддержку ключа. В то же время, против hashDoS предлагается использовать не BLAKE2, а еще более быстрый и предназначенный именно для этого SipHash (тоже с ключом): https://131002.net/siphash/ (да, JP Aumasson - один из разработчиков как BLAKE2, так и SipHash - во втором случае в соавторстве с не менее известным DJB).
     
     
  • 5.43, Adui (?), 02:35, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    гляньте лучше конферуху заядлого яд-линуксоида http://events.yandex.ru/talks/326/
     
     
  • 6.44, Adui (?), 02:37, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > гляньте лучше конферуху заядлого яд-линуксоида http://events.yandex.ru/talks/326/

    http://www.openwall.com/presentations/Passwords12-The-Future-Of-Hashing/

     
  • 6.61, filosofem (ok), 10:19, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > гляньте лучше конферуху заядлого яд-линуксоида http://events.yandex.ru/talks/326/

    Ты приколист. Предлагаешь solardiz посмотреть видео с solardiz.

     
     
  • 7.65, Аноним (-), 12:48, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ты приколист. Предлагаешь solardiz посмотреть видео с solardiz.

    Может он его просто пиарит бесплатно? :)

     
  • 7.96, Adui (?), 17:46, 26/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Не заметил его ник, прошу прощения.
     
  • 5.56, Аноним (-), 04:51, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ее как раз предлагали авторам btrfs именно в этом контексте, IIRC Да, есть в ... большой текст свёрнут, показать
     
     
  • 6.101, Аноним (-), 23:57, 27/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> (да, JP Aumasson - один из разработчиков как BLAKE2, так и
    >> SipHash - во втором случае в соавторстве с не менее известным DJB).
    > Да, есть в яндексе шарящие люди. И DJB в своем репертуаре -
    > полезные штуки придумаывает.

    Да ты совсем укурился. Причем тут Яндекс?

    btw, solardiz - это человек который написал john the ripper, основатель (если ничо не путаю) openwall, и просто чувак который наверное круче всех сейчас шарит в хешах и паролях с практической точки зрения... с яндексом его вроде не много что связывает, afaik

     
     
  • 7.104, arisu (ok), 02:58, 28/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    хм. мягко говоря — не только «в хэшах и паролях». и то, что solardiz тут пытается дятлам что-то пояснить… блин, ловить момент.
     
  • 3.21, Аноним (-), 20:45, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Для быстрого поиска хеш в один байт очень даже рулит.

    Для быстрого поиска хэш тоже должен быть быстрым, а к криптографическим хэшам типа сабжевого это не относится. При этом от модных фичей последнего толку ровно ноль - коллизии всё равно будут банально из-за малого размера таблицы. Поэтому действительно не понятно зачем нужен сильный, но которкий хэш.

     
  • 2.9, Аноним (-), 19:45, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Главное RNG правильный еще не забыть: http://xkcd.com/221/
     

  • 1.2, Аноним (-), 19:08, 24/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Новая дисциплина специальной олимпиады - Кетчак против Блэйк2.
     
  • 1.3, Аноним (-), 19:18, 24/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    То есть она может быстрее подобраться? Зачем это нужно?
     
     
  • 2.4, Аноним (-), 19:21, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Быстрее посчитаться
     
  • 2.10, Аноним (-), 19:45, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > То есть она может быстрее подобраться

    Ну как бы удачи раздолбать 2^256 вариантов тупым перебором.


     
     
  • 3.24, YetAnotherOnanym (ok), 21:15, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Когда появились MD5 и DES, их авторы тоже что-то подобное говорили, и что теперь? Для каких-то текущих надобностей данные 20-летней давности, естественно, ценности не имеют, а вот крота в своём тылу выцепить, найти его (может быть, уже заслуженного пенсионера) и подвесить за что-нибудь мягкое на ржавом крюке - вполне сгодится.
    В конце концов, закон Мура никто не отменял.
     
     
  • 4.31, Аноним (-), 22:29, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А его тупым перебором никто и не осилиk, т к 2 128 - это довольно дофига А 2 2... большой текст свёрнут, показать
     
     
  • 5.34, sdfsfsf (?), 22:34, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Атомов во вселенной больше, чем 2^256
     
     
  • 6.40, pavlinux (ok), 00:44, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    2^256 - это всего лишь 2^32^8 :)
     
  • 6.42, Аноним (-), 01:52, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Атомов во вселенной больше, чем 2^256

    Хм... да, уели. Но всего на несколько десятичных порядков. (~10^77 vs ~10^79..81)

    Врядли кто станет задействовать значительный кусок вселенной чтобы сломать ваш хэш. Ну так, чисто практически :)

     
     
  • 7.59, Аноним (-), 08:32, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А квантовые компы это будут учитывать?
     
     
  • 8.67, Аноним (-), 12:54, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это будут учитывать создатели оных, по техническим причинам ... текст свёрнут, показать
     
  • 2.19, sdfsfsf (?), 20:13, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хватит уже тиражировать эту мысль, она в корне не верна.

    Запомните уже наконец, хеш-функция - это не KDF.

    Одним из требований к хеш-функции _всегда_ является высокая скорость работы.

    Если какая-либо конкретная хеш-функция используется как примитив для KDF, то используется key stretching, наряду с другими механизмами.

     
     
  • 3.27, Аноним (-), 21:48, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    люди думают что кислотостойкость зависит от скорости функции.
     
     
  • 4.28, Аноним (-), 22:08, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Если рассматривать криптостойкость исключительно как количество вариантов для перебора - нет, не зависит.
    Но на практике приходится иметь дело с временем взлома, которое определяется как количеством вариантов, так и скоростью алгоритма.
     
     
  • 5.46, Аноним (-), 03:06, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Все правильно, по при использовании в паролях мы увеличиваем количество раундов хеширования.
    аля md5(md5(pass)). И да количество коллизий увеличивается в зависимости от алгоритма.
     
     
  • 6.48, Аноним (-), 03:09, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    собственно как и делает MD5(Unix)
     
  • 6.78, Аноним (-), 16:17, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > аля md5(md5(pass)). И да количество коллизий увеличивается в зависимости от алгоритма.

    Речь идет именно о скорости, а не о выборе алгоритма. Т.е., грубо говоря, берем один и тот же алгоритм, и вставляем в него sleepы (полагая, что он не использует внешних элементов типа аппаратных генераторов энтропии, увеличивающих энтропию со временем). Изменится от этого число коллизий?

     
     
  • 7.90, sdfsfsf (?), 20:56, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Иногда такую ахинею тут пишут.

    Запомнили одно слово - "коллизия", а толку ноль.

     

  • 1.5, Аноним (-), 19:26, 24/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/

    пароль 123 запрещён на уровне алгоритма?
     
     
  • 2.6, programmador (ok), 19:36, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, он на нём просто крэшится :-)
    А вобще хз, может и хороший алгоритм, только погоня за производительностью мягко говоря смущает - зачем алгоритм который быстрее брутфорсится...
     
     
  • 3.11, ILYA INDIGO (ok), 19:48, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    За тем, что хеширование используется далеко не только для паролей, а например для проверки целостности/подлинности пакетов.
     
  • 3.12, Аноним (-), 19:50, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > говоря смущает - зачем алгоритм который быстрее брутфорсится...

    Брутфорсить 2^256 занятие весьма тухлое, ибо даже в допущении что 1 цикл на весь алгоритм, 2^256 все-равно получается крайне дохрена и при вашей жизни брутфорс точно не завершится.

    А супротив радужных таблиц оно изначально соль умеет. Так что любители генерить заранее посчитанные таблицы все-таки будут чертыхаться.

    Тем не менее, ряд упрощений и ускорений относительно простого BLAKE - смущает, да. Криптоанализировался таки первый. А второй - упрощен ради скорости. С другой стороны, это все-таки лучше совсем раздолбанного MD5 который по сей день еще не выбросили.

     
  • 3.13, Аноним (-), 19:50, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    да уж, и не говори - теперь не за миллион лет пробутфорсишь, а всего за каких-то 199 тысяч лет.
     
     
  • 4.17, Аноним (-), 19:54, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > да уж, и не говори - теперь не за миллион лет пробутфорсишь,
    > а всего за каких-то 199 тысяч лет.

    Когда находят дыры в криптоалгоритмах, время брутфорса имеет тенденцию сдуваться в некоторые степени двойки. Так что запас не повредит.

     
     
  • 5.57, Аноним (-), 04:54, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > степени двойки. Так что запас не повредит.

    Просто идея хэша - в том что это свертка в некоторый не очень длинный результат. Если не сворачивать - можно в базе хранить войну и мир втоптанную юзером с клавы, но... :)

     
     
  • 6.75, Аноним (-), 16:08, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Просто идея хэша - в том что это свертка в некоторый не
    > очень длинный результат. Если не сворачивать - можно в базе хранить
    > войну и мир втоптанную юзером с клавы, но... :)

    В случае криптозащиты - свертка должна быть необратимой. А для нужд стораджа таки да, достаточно уменьшения размера с сохранением идентичности.

     
     
  • 7.82, Аноним (-), 19:54, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > В случае криптозащиты - свертка должна быть необратимой. А для нужд стораджа
    > таки да, достаточно уменьшения размера с сохранением идентичности.

    Спасибо, Кэп!

     
  • 2.29, Аноним (-), 22:10, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > пароль 123 запрещён на уровне алгоритма?

    Тащемта, алгоритм больше для всяких дедупликаций и контроля целостности, а не для паролей.

    А юзеру циферки 123 в файле хранить не запретишь. Точнее, запретить-то можно, а вот разумно обосновать - не получится.

     
     
  • 3.32, Аноним (-), 22:31, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > а вот разумно обосновать - не получится.

    "Пароль должен быть не менее 10 символов и содержать заглавные и строчные буквы а также цифры и спецсимволы" (c) какой-то сайт. Очень доступно и разумно объясняет что надо вот так или GTFO.

     
     
  • 4.76, Аноним (-), 16:10, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > "Пароль должен быть не менее 10 символов и содержать заглавные и строчные
    > буквы а также цифры и спецсимволы" (c) какой-то сайт. Очень доступно
    > и разумно объясняет что надо вот так или GTFO.

    А при чем здесь пароль? Речь идет об обычных пользовательских данных. Например, записал он себе для памяти, на каком порту работает NTP.

     
     
  • 5.83, Аноним (-), 19:57, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А при чем здесь пароль?

    При том что в случае тыринга такой базы хэшей...
    1) Радужные таблицы, даже если забыть про соль, на такую длину пароля будут иметь категорически непотребный размер.
    2) Словарным атакам такое ограничение тоже не друг и не товарищ.

    > записал он себе для памяти, на каком порту работает NTP.

    А зачем для этого хэши?

     

  • 1.7, ILYA INDIGO (ok), 19:41, 24/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И найдутся же "умники", которые будут этим хешировать пароли.
     
     
  • 2.14, Аноним (-), 19:51, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > И найдутся же "умники", которые будут этим хешировать пароли.

    Так там соль можно скармливать прямо в реализации алгоритма. По поводу чего быстренько нагенерить радужных таблиц может и не получиться. А перебирать все 2^256 вариантов вы немного замахаетесь.

     
     
  • 3.16, Аноним (-), 19:53, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Но все же полегче, чем sha512 :)
     
     
  • 4.33, Аноним (-), 22:33, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Но все же полегче, чем sha512 :)

    Довольно слабое утешение. Т.к. само по себе 2^256 - весьма дофига.

     
     
  • 5.37, szh (ok), 22:45, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    2^256 - весьма дофига, только стойкости паролей пользователей это число никакого отношения не имеет
     
     
  • 6.51, Аноним (-), 04:03, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > 2^256 - весьма дофига, только стойкости паролей пользователей это число никакого отношения не имеет

    Ну если кто ввел 3-буквенный пароль, ему крышка в любом случае. Это и с солью и без, и в SHA-3 и прочих сломают. Ставьте требование на сложность пароля, чтоб радугу на такие размеры под лично вашу уникальную соль обломались генерить.

     
  • 3.35, szh (ok), 22:37, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А перебирать все 2^256 вариантов

    Размечтался. Перебор - по символам, а там и не пахнет таким количеством для 99.9% юзеров.

     
     
  • 4.55, Аноним (-), 04:35, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Размечтался. Перебор - по символам, а там и не пахнет таким количеством для 99.9% юзеров.

    Если это для авторизации где-то - ну завинтите требования на сложность пароля, да и все дела.

     
     
  • 5.62, szh (ok), 11:20, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Если это для авторизации

    хэшировать пароли - это для авторизации, точнее на случай, если базу паролей уведут.

    > ну завинтите требования на сложность пароля

    А кто оплатит потерю пользователей и прибыли ?

    P.S. Bcrypt для этого надо использовать. Тогда и требования к пользователям гораздо ниже.

     
     
  • 6.68, Аноним (-), 13:02, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну я в курсе, да Профит от отсутствия необходимости геморроиться с высылкой раз... большой текст свёрнут, показать
     
     
  • 7.99, szh (ok), 21:10, 26/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Чудес не бывает: или нечто быстрое и сервак не напрягается, но и хакер может относительно быстро брутфорсить, или сервак при большом числе запросов встает р@ком.

    чудо состоит в том, что мир не черно-белый и уменьшить кол-во букв, которое необходимо для стойкого хеша пароля и соответственно во много раз кол-во пользователей которые брутфорсятся, можно и нужно.

    > при этом вообще плевать какя там хэш-функция

    только потому что в том случае salt им не мешает. В отличии от хеширования паролей, о котором идет речь.

     
  • 2.22, qux (ok), 20:51, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А проблема в чем? Даже 32 байта все равно в 2 раза больше, чем у md5. А последним достаточно много пользовались.
     
     
  • 3.26, Аноним (-), 21:46, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    да нету проблем, проблема только в головах.
     
  • 3.36, szh (ok), 22:39, 24/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А проблема в чем? Даже 32 байта все равно в 2 раза
    > больше, чем у md5. А последним достаточно много пользовались.

    Проблема в скорости перебора-подбора, а вовсе не в кол-ве байт. И 16 байт за глаза хватает.

     
     
  • 4.52, Аноним (-), 04:03, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Проблема в скорости перебора-подбора,

    Она линейно параллелится по числу числокрушилок и плюс-минус в несколько раз мало что меняет в этом плане.

     
     
  • 5.77, Аноним (-), 16:13, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Проблема в скорости перебора-подбора,
    > Она линейно параллелится по числу числокрушилок и плюс-минус в несколько раз мало
    > что меняет в этом плане.

    Разница есть. Если перейти от 1 сервера-крушилки к 10 - может быть довольно просто, то от 10 к 100 - немножко сложнее. А от 100 к 1000 - еще сложнее. Хотя кратность одна и та же.

     
     
  • 6.86, Аноним (-), 20:19, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > от 100 к 1000 - еще сложнее. Хотя кратность одна и та же.

    Да, но
    1) Инфраструктуры проверяющей хэши все это тоже касается. А поскольку сервера обычно стоят не только под проверку хэшей, сильно удорожать инфраструктуру мало кто хочет.
    2) Потом какой-нибудь умник еще и разложит на GPU или там что еще и отмасштабируется подешевле ынтырпрайза с такими хэшами, чтоб им пообиднее за потраченное бабло было.

     

  • 1.20, Аноним (-), 20:30, 24/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    замечательно
    длина тоже как у md5 и свободность?
     
     
  • 2.54, Аноним (-), 04:34, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > длина тоже как у md5 и свободность?

    Пастернака^W новость не читал...

     
     
  • 3.70, Аноним (-), 14:19, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    благодарю - сразу не заметил, прочитал новость бегло и в темноте ))
     
  • 2.97, Adui (?), 17:52, 26/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > замечательно
    > длина тоже как у md5 и свободность?

    default = 64

     

  • 1.47, Adui (?), 03:09, 25/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    улучшенный bcrypt на параллелизм http://cipherdev.org/rnd/dhbitty.c
     
     
  • 2.49, Adui (?), 03:10, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    пример http://cipherdev.org/rnd/safe_primes.txt
     
     
  • 3.50, Adui (?), 03:15, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    главная страница проекта http://cipherdev.org/dhbitty.html
     
  • 2.53, Аноним (-), 04:33, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > улучшенный bcrypt на параллелизм http://cipherdev.org/rnd/dhbitty.c

    Кстати, забавная штука. Довольно компактный D-H с интересными свойствами, как то отсутствием приватных ключей как таковых - заменяются приватными passphrase-ами вместо этого. Правда в процессе работы утиля используются какие-то трансформации не относящиеся к широко известным и степень надежности этого - ??. Но идея заменить привкей passphrase-ой интересная.

     
     
  • 3.63, solardiz (ok), 12:43, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но идея заменить привкей passphrase-ой интересная.

    Еще на эту тему:
    http://dankaminsky.com/phidelius
    http://ritter.vg/blog-non_persistent_pgp.html

     
     
  • 4.88, Аноним (-), 20:46, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Еще на эту тему:
    > http://dankaminsky.com/phidelius
    > http://ritter.vg/blog-non_persistent_pgp.html

    Идея у них чем-то похожа, просто у упомянутого гражданина положительной стороной является внятность реализации для пользователя, в том плане что ему достаточно знать юзер:пароль чтобы получить то что ему адресовано. А то что по тем ссылкам - ну да, идею я уловил, но юзеэ в целом менее дружелюбный. Скорее PoC или нечто подобное чем применимое всерьез решение, да еще и околосистемными хаками в процессе. Хаки конечно не есть плохо, но хак системы через LD_PRELOAD для генерации пары ключей - это довольно... странно :)

     
  • 3.80, arisu (ok), 19:31, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Правда в процессе работы утиля используются какие-то трансформации не относящиеся к широко
    > известным и степень надежности этого — ??.

    э… а что неизвестно-то? сurve25519 или EnRUPT?

     
     
  • 4.85, Аноним (-), 20:16, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > э… а что неизвестно-то? сurve25519 или EnRUPT?

    Сurve25519 встречается довольно часто, не отнять. А вот who is EnRUPT я честно говоря слышу чуть ли не впервые. Краткий гуглинг дал понять что оно из себя представляет. Сие довольно быстро вылетело с конкурса sha-3 за довольно невкусные уязвимости. Собственно по каким-то таким соображениям я и отношусь с осторожностью к очередному, 100501-му по счету шифру.

     
     
  • 5.87, arisu (ok), 20:33, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А вот who is EnRUPT я честно говоря слышу чуть ли не впервые.

    «я не знаю» != «никому не известно».

    > Сие довольно быстро вылетело с конкурса sha-3 за довольно невкусные уязвимости.

    и? даже если не обращать внимание, что атака относится к хэш-функции, а не у применению в качестве block cipher (атаки на ключи блочного шифра — несколько другая штука).

    > Собственно по каким-то таким соображениям я
    > и отношусь с осторожностью к очередному, 100501-му по счету шифру.

    замени на любой, к которому относишься лучше, в чём проблема-то? EnRUPT быстрый, простой и подходит для многих практических применений. а больше ничего и не требовалось, собственно — автор нигде не заявлял, что софтина немеряно неломаемая.

     
     
  • 6.89, Аноним (-), 20:56, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Правильно Однако тому что известно всем хоть немного интересующимся вопросом кр... большой текст свёрнут, показать
     
     
  • 7.91, arisu (ok), 21:17, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну просто если я вижу криптографическую софтину — хотелось бы понимать что
    > и нафига там сделано. И почему автор решил это делать именно
    > так.

    а что непонятно-то? EnRUPT — быстрый и простой. при этом достаточен для «домашнего применения». но если охота — замени на другой, в чём трабл-то?

     

  • 1.60, Аноним (-), 09:41, 25/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    терморектальный криптоанализ так и останется самым быстрым методом взлома.
    weakest links ....
     
     
  • 2.64, КриптоАноним (?), 12:48, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Да за...бали уже терморектальные криптоанализаторы своим идеотизмом. Ложите ключи от своей квартиры под коврик на пороге, всё равно, отдадите же. Не, а лучше сэконьме на покупке замков - не покупайте их вообще!
     
  • 2.71, Аноним (-), 15:13, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > терморектальный криптоанализ так и останется самым быстрым методом взлома.
    > weakest links ....

    1) Он отличается ценным свойством: его сложно не заметить.
    2) Боюсь что я не вспомню 256-битный ключ при вообще любом методе дознания...

     
     
  • 3.79, Аноним (-), 16:19, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> терморектальный криптоанализ так и останется самым быстрым методом взлома.
    >> weakest links ....
    > 1) Он отличается ценным свойством: его сложно не заметить.

    Поэтому, как правило, доблестного криптозащитника после анализа могут запросто отправить в /dev/null.

    > 2) Боюсь что я не вспомню 256-битный ключ при вообще любом методе дознания...

    Да и не введешь его при нормально доступе, раз не помнишь.

     
     
  • 4.84, Аноним (-), 19:59, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Да и не введешь его при нормально доступе, раз не помнишь.

    Я могу его взять с некоего маленького носителя. Ну там флешки, SD карты. Думаю вы догадываетесь что делается с таким носителем при пиковой ситуации.

     

  • 1.69, Онаним (?), 13:28, 25/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Один я заметил скрытую рекламу AMD?

    >При проведении теста на системе с процессором Intel Core i7-2630QM (Sandy Bridge 2GHz) была продемонстрирована производительность в 531 мебибайт в секунду
    >при использовании процессора AMD FX-8150 (Bulldozer 3.6GHz) производительность составила 628  мебибайт в секунду

     
     
  • 2.72, Аноним (-), 15:14, 25/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Один я заметил скрытую рекламу AMD?

    Да ладно, просто FX-8xxx у амд - довольно приличные числокрушилки.

     
  • 2.93, someone (??), 03:31, 26/12/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Только вот интел имеет 3,5 циклов на байт, а амд 5,5. Притом что у АМД и частота выше почти в 2 раза, лол.
     

  • 1.92, Adui (?), 22:28, 25/12/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно как этот алгоритм поведет себя на ZFS, против SHA-256
     
     
  • 2.95, Аноним (-), 13:43, 26/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно как этот алгоритм поведет себя на ZFS, против SHA-256

    Возьми сорц, влупи, проведи тесты, опубликуй. Благодарное
    человечество удовлетворит свое и твое любопытство.

     
     
  • 3.98, arisu (ok), 18:53, 26/12/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> Интересно как этот алгоритм поведет себя на ZFS, против SHA-256
    > Возьми сорц, влупи, проведи тесты, опубликуй. Благодарное
    > человечество удовлетворит свое и твое любопытство.

    я сначала это и хотел предложить, а потом на ник внимательней посмотрел: есть мнение, что даже с изи в данном случае толку будет больше.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру