Представлена (http://lists.randombit.net/pipermail/cryptography/2012-Decem...) современная криптографическая хеш-функция BLAKE2 (https://blake2.net/), не уступающая по производительности MD5, потребляющая на 33% меньше памяти чем SHA-2/SHA-3 и лишенная известных проблем с безопасностью. BLAKE2 является переработанной версией хэш-функции BLAKE, вошедшей в число финалистов конкурса (http://www.opennet.me/opennews/art.shtml?num=35003) на разработку криптоалгоритмов для стандарта 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 процессорных циклов на байт).<center><a href="https://blake2.net/sandy.png"><img src="http://www.opennet.me/opennews/pics_base/0_1356358062.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center>
URL: http://lists.randombit.net/pipermail/cryptography/2012-Decem...
Новость: http://www.opennet.me/opennews/art.shtml?num=35676
> ... Размер результирующего хэша может генерироваться в диапазоне от 1 до 64 байт.Хэш в один байт! Коллизии просто невозможны :)
Не всегда требуется отсутствие коллизий.
Для быстрого поиска хеш в один байт очень даже рулит.
> Для быстрого поиска хеш в один байт очень даже рулит.До тех пор пока какой-нибудь козел не начнет кормить поиск байтами с одинаковым хэшом оптом, сделав быстрый поиск медленным. //По мотивам бага в btrfs :)
Вы так нечего и не поняли, обработка коллизий в btrfs медленная. Сделаете быструю обработку все гуд будет.
> Сделаете быструю обработку все гуд будет.А вот нифига.
Ну вам виднее.
Жираф большой, ему видней. (с) В.С.Высоцкий
> Ну вам виднее.
> Жираф большой, ему видней. (с) В.С.ВысоцкийЧтобы дорасти до жирафа, достаточно на начальному уровне разобраться в работе хеш-таблиц и понять, что коллизия все равно требует специальной обработки. Даже если ее оптимизировать, все равно это будет значительно медленнее прямого обращения.
Все так и в простершем случаи обработки получим O(n), а теперь c смотрим что было с btrfs
Подсказка: то, что было с btrfs, можно прекрасно получить и на O(n).
> Подсказка: то, что было с btrfs, можно прекрасно получить и на O(n).В жопу надо ваш БТРфс засунуть
# mkfs.btrfs -l32k -n32k -m single /dev/sdd1
# mount -t btrfs -o noatime,discard,ssd /dev/sdd1 /media/flash/
# cd /media/flash
# /opt/iozone/bin/iozone -a -b /btrfs.xls -+u -p -B -e -E;Iozone: Performance Test of File I/O
Version $Revision: 3.283 $
Compiled for 64 bit mode.
Build: linux-AMD64Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million,
Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy,
Erik Habbinga, Kris Strecker, Walter Wong.Run began: Tue Dec 25 19:32:40 2012
Auto Mode
CPU utilization Resolution = 0.001 seconds.
CPU utilization Excel chart enabled
Purge Mode On
Using mmap files
Include fsync in write timing
Command line used: /opt/iozone/bin/iozone -a -b /btrfs.xls -+u -p -B -e -E
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
KB reclen write rewrite read reread read write read rewrite read
64 4 2154 2285 615952 710511 727850 2331 679917 2752 1363961
64 8 2162 2316 695778 703068 939223 2502 551422 2711 1183548
64 16 151 2284 673098 1304314 1363961 2248 889431 2668 1780008
64 32 2338 2196 710511 998622 1526887 2227 1087638 2276 1143223
64 64 2277 2285 647135 969761 1163036 2319 955947 2353 727850
128 4 3568 3357 590094 695603 811221 4487 509943 5505 666253
128 8 3424 3507 681476 612303 837806 4570 707520 5419 1561553
128 16 3254 3617 568836 598647 633247 4388 582412 5505 1022989
128 32 3556 3483 533241 493989 604036 3863 422464 4533 735635
128 64 3580 3570 404025 529038 615814 4412 387966 4457 955616
128 128 3503 298 347758 509943 500436 582 456986 3471 486822
256 4 5265 5334 635047 699139 810490 6998 600928 9917 773697
256 8 5673 5319 609801 738065 900936 6818 686620 617 577962
256 16 5237 5292 548161 603630 653204 6177 542347 10723 1117543
256 32 5347 5333 518263 572721 664935 7080 547044 9998 785584
256 64 5835 5705 474098 541253 547044 6114 511109 8828 713067
256 128 6482 7136 465466 514045 596587 7937 489442 7733 615393
256 256 6687 7039 439732 485678 506767 6783 428159 5989 425951
512 4 6826 7135 532767 681566 819085 9279 519367 21228 591951
512 8 7198 7086 568296 696600 836636 9500 600223 20802 588383
512 16 1112 909 519241 571472 678122 12604 450318 20504 464541
512 32 1135 10058 473660 540681 608041 12354 484452 19240 843206
512 64 9525 10014 455960 516618 621233 14551 493242 17506 733478
512 128 10241 10240 565156 1089647 1333173 12867 803757 14953 1510391
512 256 10584 10401 395353 486207 572081 13660 399397 13174 521385
512 512 9982 10222 565156 568899 559560 9387 331156 10068 333314
1024 4 1762 2019 559619 563288 732453 12615 537488 51207 535011
Ошибка сегментированияЭто ещё не всё...
------------[ cut here ]------------
kernel BUG at fs/btrfs/extent-tree.c:1481!
invalid opcode: 0000 [#2] PREEMPT SMP
CPU 3
Modules linked in: btrfs zlib_deflate zlib_inflate ipt_ECN ipt_REJECT iptable_filter xt_recent iptable_mangle xt_DSCP 8250_pnp sr_mod nvidia(O) et131x(C) cdrom 8250 serial_core ohci_hcd evdevPid: 3327, comm: btrfs-transacti Tainted: G D WC O 3.7.1 #1 TYAN Computer Corp. S2895/S2895
RIP: 0010:[<ffffffffa08c175e>] [<ffffffffa08c175e>] 0xffffffffa08c175e
RSP: 0018:ffff8801524b5ac0 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffff880241178540 RCX: 0000000000000000
RDX: 0000000000000008 RSI: 0000160000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000000b2
R13: 00000000ffffffff R14: ffff8802411515b0 R15: ffff8802411515b0
FS: 00007f98822b4740(0000) GS:ffff88025fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007fb195144000 CR3: 00000000015d6000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process btrfs-transacti (pid: 3327, threadinfo ffff8801524b4000, task ffff880152690040)
Stack:
ffff88025269a800 000000000000003d ffff88025368f800 00000000000004b1
0000000000e6a000 ffff8801524b5bf0 0000000000000000 ffffffffffffffff
0000000000000000 a000000000000000 00a80000000000e6 ff00000000000020
Call Trace:
[<ffffffffa08c1841>] ? 0xffffffffa08c1841
[<ffffffff81100eae>] ? 0xffffffff81100eae
[<ffffffffa08c2a09>] ? 0xffffffffa08c2a09
[<ffffffffa08c50a9>] ? 0xffffffffa08c50a9
[<ffffffffa08db44e>] ? 0xffffffffa08db44e
[<ffffffff810671c0>] ? 0xffffffff810671c0
[<ffffffffa08dc37e>] ? 0xffffffffa08dc37e
[<ffffffff810519c0>] ? 0xffffffff810519c0
[<ffffffffa08d30b5>] ? 0xffffffffa08d30b5
[<ffffffffa08d2e50>] ? 0xffffffffa08d2e50
[<ffffffffa08d2e50>] ? 0xffffffffa08d2e50
[<ffffffff81066a00>] ? 0xffffffff81066a00
[<ffffffff814e8374>] ? 0xffffffff814e8374
[<ffffffff81066980>] ? 0xffffffff81066980
[<ffffffff814e8370>] ? 0xffffffff814e8370
Code: 65 e8 67 f9 03 00 e9 bc fd ff ff b8 fe ff ff ff e9 a8 fb ff ff be ef 05 00 00 48 c7 c7 4f 52 93 a0 e8 97 16 78 e0 e9 c1 fb ff ff <0f> 0b 0f 0b 0f 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 41 57 49
RIP [<ffffffffa08c175e>] 0xffffffffa08c175e
RSP <ffff8801524b5ac0>
---[ end trace 0000000000001209 ]---
идите дальше холиварте.
Один из способов защиты от hashDoS - использование криптографической хеш-функции с ключом (keyed hash). BLAKE2 имеет встроенную поддержку ключа. В то же время, против hashDoS предлагается использовать не BLAKE2, а еще более быстрый и предназначенный именно для этого SipHash (тоже с ключом): https://131002.net/siphash/ (да, JP Aumasson - один из разработчиков как BLAKE2, так и SipHash - во втором случае в соавторстве с не менее известным DJB).
гляньте лучше конферуху заядлого яд-линуксоида http://events.yandex.ru/talks/326/
> гляньте лучше конферуху заядлого яд-линуксоида http://events.yandex.ru/talks/326/http://www.openwall.com/presentations/Passwords12-The-Future.../
> гляньте лучше конферуху заядлого яд-линуксоида http://events.yandex.ru/talks/326/Ты приколист. Предлагаешь solardiz посмотреть видео с solardiz.
> Ты приколист. Предлагаешь solardiz посмотреть видео с solardiz.Может он его просто пиарит бесплатно? :)
Не заметил его ник, прошу прощения.
> предназначенный именно для этого SipHash (тоже с ключом): https://131002.net/siphash/Ее как раз предлагали авторам btrfs именно в этом контексте, IIRC :)
> (да, JP Aumasson - один из разработчиков как BLAKE2, так и
> SipHash - во втором случае в соавторстве с не менее известным DJB).Да, есть в яндексе шарящие люди. И DJB в своем репертуаре - полезные штуки придумаывает.
Да, если уж насчет видео которое гражданин ниже привел...
1) Блин, юзали бы парни из яндекса webm уже, а? Он чуть ли не на треть эффективнее ogg theora по битрейт/качество и доступен на совершенно халявных условиях. Какой смысл при этом цепляться за раннего предшественника формата - малопонятно. Все современные браузеры умевшие theora давно уже умеют webm.
2) Ну и ттооррммоозззиттт же у яндекса сервак. Загрузка видео начинается минуту наверное. Пните уже админов яндекса, а? Ну не должны сервера крупной компании так работать.
>> (да, JP Aumasson - один из разработчиков как BLAKE2, так и
>> SipHash - во втором случае в соавторстве с не менее известным DJB).
> Да, есть в яндексе шарящие люди. И DJB в своем репертуаре -
> полезные штуки придумаывает.Да ты совсем укурился. Причем тут Яндекс?
btw, solardiz - это человек который написал john the ripper, основатель (если ничо не путаю) openwall, и просто чувак который наверное круче всех сейчас шарит в хешах и паролях с практической точки зрения... с яндексом его вроде не много что связывает, afaik
хм. мягко говоря — не только «в хэшах и паролях». и то, что solardiz тут пытается дятлам что-то пояснить… блин, ловить момент.
> Для быстрого поиска хеш в один байт очень даже рулит.Для быстрого поиска хэш тоже должен быть быстрым, а к криптографическим хэшам типа сабжевого это не относится. При этом от модных фичей последнего толку ровно ноль - коллизии всё равно будут банально из-за малого размера таблицы. Поэтому действительно не понятно зачем нужен сильный, но которкий хэш.
Главное RNG правильный еще не забыть: http://xkcd.com/221/
Новая дисциплина специальной олимпиады - Кетчак против Блэйк2.
То есть она может быстрее подобраться? Зачем это нужно?
Быстрее посчитаться
> То есть она может быстрее подобратьсяНу как бы удачи раздолбать 2^256 вариантов тупым перебором.
Когда появились MD5 и DES, их авторы тоже что-то подобное говорили, и что теперь? Для каких-то текущих надобностей данные 20-летней давности, естественно, ценности не имеют, а вот крота в своём тылу выцепить, найти его (может быть, уже заслуженного пенсионера) и подвесить за что-нибудь мягкое на ржавом крюке - вполне сгодится.
В конце концов, закон Мура никто не отменял.
> Когда появились MD5А его тупым перебором никто и не осилиk, т.к. 2^128 - это довольно дофига. А 2^256 по идее хватит даже с учетом всего мыслимого прогресса и квантовых компьютеров. Просто нашли уязвимости позволяющие упростить генерацию коллизий до более разумных величин.
> и DES, их авторы тоже что-то подобное говорили,
А DES вообще не алгоритм хэширования. А то что для шифрования 56 битов мало - понимает даже дебил. Криптографы уже на момент выхода DES предупреждали. Потом кого-то задолбало и они на программируемой логике собрали брутфорсер способный за какие-то дни перебрать 56 битов. Потому что этого элементарно мало. Вот только стоит понимать что добавление 1 бита увеличивает сложность брута в ДВА РАЗА. Поэтому 128 битов тупым брутом на современных компьюьтерах уже проблематично. А 256 даже квантовые не возьмут. По чисто практическим соображениям (e.g. затраты энергии на процесс).
> и что теперь?
А ничего. Конечно можно использовать замок и так: http://words.brittina.net/wp-content/uploads/2009/03/fail-ow... Вот это как использование DES с точки зрения криптографов.
> В конце концов, закон Мура никто не отменял.
В конце концов, наличие головного мозга еще не отменяли. Достаточно сразу ориентироваться на заведомо неподъемную сложность перебора. Например пусть у атакуюшего компьютер состояния которого переключаются за минимальную величину которую вообще померять можно, что-нибудь порядка планковской константы. Пусть он чуть ли не бесконечно быстр. При достаточно большом объеме вычислений вычисляющий упрется в то что ему не хватит энергии в доступном закоулке вселенной. Вот 2^256 - это уже из этой оперы. Это совершенно дикое число, если его в десятичной системе записать. Атомов во всей вселенной меньше.
Атомов во вселенной больше, чем 2^256
2^256 - это всего лишь 2^32^8 :)
> Атомов во вселенной больше, чем 2^256Хм... да, уели. Но всего на несколько десятичных порядков. (~10^77 vs ~10^79..81)
Врядли кто станет задействовать значительный кусок вселенной чтобы сломать ваш хэш. Ну так, чисто практически :)
А квантовые компы это будут учитывать?
> А квантовые компы это будут учитывать?Это будут учитывать создатели оных, по техническим причинам :)
Хватит уже тиражировать эту мысль, она в корне не верна.Запомните уже наконец, хеш-функция - это не KDF.
Одним из требований к хеш-функции _всегда_ является высокая скорость работы.
Если какая-либо конкретная хеш-функция используется как примитив для KDF, то используется key stretching, наряду с другими механизмами.
люди думают что кислотостойкость зависит от скорости функции.
Если рассматривать криптостойкость исключительно как количество вариантов для перебора - нет, не зависит.
Но на практике приходится иметь дело с временем взлома, которое определяется как количеством вариантов, так и скоростью алгоритма.
Все правильно, по при использовании в паролях мы увеличиваем количество раундов хеширования.
аля md5(md5(pass)). И да количество коллизий увеличивается в зависимости от алгоритма.
собственно как и делает MD5(Unix)
> аля md5(md5(pass)). И да количество коллизий увеличивается в зависимости от алгоритма.Речь идет именно о скорости, а не о выборе алгоритма. Т.е., грубо говоря, берем один и тот же алгоритм, и вставляем в него sleepы (полагая, что он не использует внешних элементов типа аппаратных генераторов энтропии, увеличивающих энтропию со временем). Изменится от этого число коллизий?
Иногда такую ахинею тут пишут.Запомнили одно слово - "коллизия", а толку ноль.
пароль 123 запрещён на уровне алгоритма?
Ага, он на нём просто крэшится :-)
А вобще хз, может и хороший алгоритм, только погоня за производительностью мягко говоря смущает - зачем алгоритм который быстрее брутфорсится...
За тем, что хеширование используется далеко не только для паролей, а например для проверки целостности/подлинности пакетов.
> говоря смущает - зачем алгоритм который быстрее брутфорсится...Брутфорсить 2^256 занятие весьма тухлое, ибо даже в допущении что 1 цикл на весь алгоритм, 2^256 все-равно получается крайне дохрена и при вашей жизни брутфорс точно не завершится.
А супротив радужных таблиц оно изначально соль умеет. Так что любители генерить заранее посчитанные таблицы все-таки будут чертыхаться.
Тем не менее, ряд упрощений и ускорений относительно простого BLAKE - смущает, да. Криптоанализировался таки первый. А второй - упрощен ради скорости. С другой стороны, это все-таки лучше совсем раздолбанного MD5 который по сей день еще не выбросили.
да уж, и не говори - теперь не за миллион лет пробутфорсишь, а всего за каких-то 199 тысяч лет.
> да уж, и не говори - теперь не за миллион лет пробутфорсишь,
> а всего за каких-то 199 тысяч лет.Когда находят дыры в криптоалгоритмах, время брутфорса имеет тенденцию сдуваться в некоторые степени двойки. Так что запас не повредит.
> степени двойки. Так что запас не повредит.Просто идея хэша - в том что это свертка в некоторый не очень длинный результат. Если не сворачивать - можно в базе хранить войну и мир втоптанную юзером с клавы, но... :)
> Просто идея хэша - в том что это свертка в некоторый не
> очень длинный результат. Если не сворачивать - можно в базе хранить
> войну и мир втоптанную юзером с клавы, но... :)В случае криптозащиты - свертка должна быть необратимой. А для нужд стораджа таки да, достаточно уменьшения размера с сохранением идентичности.
> В случае криптозащиты - свертка должна быть необратимой. А для нужд стораджа
> таки да, достаточно уменьшения размера с сохранением идентичности.Спасибо, Кэп!
> пароль 123 запрещён на уровне алгоритма?Тащемта, алгоритм больше для всяких дедупликаций и контроля целостности, а не для паролей.
А юзеру циферки 123 в файле хранить не запретишь. Точнее, запретить-то можно, а вот разумно обосновать - не получится.
> а вот разумно обосновать - не получится."Пароль должен быть не менее 10 символов и содержать заглавные и строчные буквы а также цифры и спецсимволы" (c) какой-то сайт. Очень доступно и разумно объясняет что надо вот так или GTFO.
> "Пароль должен быть не менее 10 символов и содержать заглавные и строчные
> буквы а также цифры и спецсимволы" (c) какой-то сайт. Очень доступно
> и разумно объясняет что надо вот так или GTFO.А при чем здесь пароль? Речь идет об обычных пользовательских данных. Например, записал он себе для памяти, на каком порту работает NTP.
> А при чем здесь пароль?При том что в случае тыринга такой базы хэшей...
1) Радужные таблицы, даже если забыть про соль, на такую длину пароля будут иметь категорически непотребный размер.
2) Словарным атакам такое ограничение тоже не друг и не товарищ.> записал он себе для памяти, на каком порту работает NTP.
А зачем для этого хэши?
И найдутся же "умники", которые будут этим хешировать пароли.
> И найдутся же "умники", которые будут этим хешировать пароли.Так там соль можно скармливать прямо в реализации алгоритма. По поводу чего быстренько нагенерить радужных таблиц может и не получиться. А перебирать все 2^256 вариантов вы немного замахаетесь.
Но все же полегче, чем sha512 :)
> Но все же полегче, чем sha512 :)Довольно слабое утешение. Т.к. само по себе 2^256 - весьма дофига.
2^256 - весьма дофига, только стойкости паролей пользователей это число никакого отношения не имеет
> 2^256 - весьма дофига, только стойкости паролей пользователей это число никакого отношения не имеетНу если кто ввел 3-буквенный пароль, ему крышка в любом случае. Это и с солью и без, и в SHA-3 и прочих сломают. Ставьте требование на сложность пароля, чтоб радугу на такие размеры под лично вашу уникальную соль обломались генерить.
> А перебирать все 2^256 вариантовРазмечтался. Перебор - по символам, а там и не пахнет таким количеством для 99.9% юзеров.
> Размечтался. Перебор - по символам, а там и не пахнет таким количеством для 99.9% юзеров.Если это для авторизации где-то - ну завинтите требования на сложность пароля, да и все дела.
> Если это для авторизациихэшировать пароли - это для авторизации, точнее на случай, если базу паролей уведут.
> ну завинтите требования на сложность пароля
А кто оплатит потерю пользователей и прибыли ?
P.S. Bcrypt для этого надо использовать. Тогда и требования к пользователям гораздо ниже.
> хэшировать пароли - это для авторизации, точнее на случай, если базу паролей уведут.Ну я в курсе, да.
>> ну завинтите требования на сложность пароля
> А кто оплатит потерю пользователей и прибыли ?Профит от отсутствия необходимости геморроиться с высылкой разломанного пароля идиотам и разруливания последствий.
> P.S. Bcrypt для этого надо использовать. Тогда и требования к пользователям гораздо ниже.
Чудес не бывает: или нечто быстрое и сервак не напрягается, но и хакер может относительно быстро брутфорсить, или сервак при большом числе запросов встает р@ком. Просто потому что брутфорсер - он ничем таким не хуже и может выкроить примерно такое же кол-во ресурсов. А трехбуквенный или словарный пароль ломанут независимо от алгоритма. Знаете как спамеры угоняют аськи под спам? Берут пароль поочевиднее и напускают многопоточный брут авторизаций на большой диапазон. Сотни идиотов обеспечены. Как видите, при этом вообще плевать какя там хэш-функция. Да любая, сломают все-равно.
> Чудес не бывает: или нечто быстрое и сервак не напрягается, но и хакер может относительно быстро брутфорсить, или сервак при большом числе запросов встает р@ком.чудо состоит в том, что мир не черно-белый и уменьшить кол-во букв, которое необходимо для стойкого хеша пароля и соответственно во много раз кол-во пользователей которые брутфорсятся, можно и нужно.
> при этом вообще плевать какя там хэш-функция
только потому что в том случае salt им не мешает. В отличии от хеширования паролей, о котором идет речь.
А проблема в чем? Даже 32 байта все равно в 2 раза больше, чем у md5. А последним достаточно много пользовались.
да нету проблем, проблема только в головах.
> А проблема в чем? Даже 32 байта все равно в 2 раза
> больше, чем у md5. А последним достаточно много пользовались.Проблема в скорости перебора-подбора, а вовсе не в кол-ве байт. И 16 байт за глаза хватает.
> Проблема в скорости перебора-подбора,Она линейно параллелится по числу числокрушилок и плюс-минус в несколько раз мало что меняет в этом плане.
>> Проблема в скорости перебора-подбора,
> Она линейно параллелится по числу числокрушилок и плюс-минус в несколько раз мало
> что меняет в этом плане.Разница есть. Если перейти от 1 сервера-крушилки к 10 - может быть довольно просто, то от 10 к 100 - немножко сложнее. А от 100 к 1000 - еще сложнее. Хотя кратность одна и та же.
> от 100 к 1000 - еще сложнее. Хотя кратность одна и та же.Да, но
1) Инфраструктуры проверяющей хэши все это тоже касается. А поскольку сервера обычно стоят не только под проверку хэшей, сильно удорожать инфраструктуру мало кто хочет.
2) Потом какой-нибудь умник еще и разложит на GPU или там что еще и отмасштабируется подешевле ынтырпрайза с такими хэшами, чтоб им пообиднее за потраченное бабло было.
замечательно
длина тоже как у md5 и свободность?
> длина тоже как у md5 и свободность?Пастернака^W новость не читал...
благодарю - сразу не заметил, прочитал новость бегло и в темноте ))
> замечательно
> длина тоже как у md5 и свободность?default = 64
улучшенный bcrypt на параллелизм http://cipherdev.org/rnd/dhbitty.c
пример http://cipherdev.org/rnd/safe_primes.txt
главная страница проекта http://cipherdev.org/dhbitty.html
> улучшенный bcrypt на параллелизм http://cipherdev.org/rnd/dhbitty.cКстати, забавная штука. Довольно компактный D-H с интересными свойствами, как то отсутствием приватных ключей как таковых - заменяются приватными passphrase-ами вместо этого. Правда в процессе работы утиля используются какие-то трансформации не относящиеся к широко известным и степень надежности этого - ??. Но идея заменить привкей passphrase-ой интересная.
> Но идея заменить привкей passphrase-ой интересная.Еще на эту тему:
http://dankaminsky.com/phidelius
http://ritter.vg/blog-non_persistent_pgp.html
> Еще на эту тему:
> http://dankaminsky.com/phidelius
> http://ritter.vg/blog-non_persistent_pgp.htmlИдея у них чем-то похожа, просто у упомянутого гражданина положительной стороной является внятность реализации для пользователя, в том плане что ему достаточно знать юзер:пароль чтобы получить то что ему адресовано. А то что по тем ссылкам - ну да, идею я уловил, но юзеэ в целом менее дружелюбный. Скорее PoC или нечто подобное чем применимое всерьез решение, да еще и околосистемными хаками в процессе. Хаки конечно не есть плохо, но хак системы через LD_PRELOAD для генерации пары ключей - это довольно... странно :)
> Правда в процессе работы утиля используются какие-то трансформации не относящиеся к широко
> известным и степень надежности этого — ??.э… а что неизвестно-то? сurve25519 или EnRUPT?
> э… а что неизвестно-то? сurve25519 или EnRUPT?Сurve25519 встречается довольно часто, не отнять. А вот who is EnRUPT я честно говоря слышу чуть ли не впервые. Краткий гуглинг дал понять что оно из себя представляет. Сие довольно быстро вылетело с конкурса sha-3 за довольно невкусные уязвимости. Собственно по каким-то таким соображениям я и отношусь с осторожностью к очередному, 100501-му по счету шифру.
> А вот who is EnRUPT я честно говоря слышу чуть ли не впервые.«я не знаю» != «никому не известно».
> Сие довольно быстро вылетело с конкурса sha-3 за довольно невкусные уязвимости.
и? даже если не обращать внимание, что атака относится к хэш-функции, а не у применению в качестве block cipher (атаки на ключи блочного шифра — несколько другая штука).
> Собственно по каким-то таким соображениям я
> и отношусь с осторожностью к очередному, 100501-му по счету шифру.замени на любой, к которому относишься лучше, в чём проблема-то? EnRUPT быстрый, простой и подходит для многих практических применений. а больше ничего и не требовалось, собственно — автор нигде не заявлял, что софтина немеряно неломаемая.
> «я не знаю» != «никому не известно».Правильно. Однако тому что известно всем хоть немного интересующимся вопросом криптографы априори уделили намного больше внимания. По поводу чего, если в популярном алгоритме за длительное время не нашли кучи проблем, можно предположить что он вышел достаточно стойким. А в остальных случаях оптимизм быает чреват. Да, я кой-чему у криптографов научился - они профессиональные параноики-пессимисты. На что у них есть объективные причины.
>> Сие довольно быстро вылетело с конкурса sha-3 за довольно невкусные уязвимости.
> и? даже если не обращать внимание, что атака относится к хэш-функции, а
> не у применению в качестве block cipher (атаки на ключи блочного шифра — несколько
> другая штука).Да, все так, просто это имхо индикатор того что криптографичекие свойства алгоритма в целом не очень хорошие. Какой-то почти-клон *TEA-based, в которых невкусные дыры как-то по жизни находили.
> замени на любой, к которому относишься лучше, в чём проблема-то? EnRUPT быстрый,
> простой и подходит для многих практических применений. а больше ничего иНу вон DES когда-то тоже подходил для практических применений :)
> не требовалось, собственно — автор нигде не заявлял, что софтина немеряно неломаемая.
Ну просто если я вижу криптографическую софтину - хотелось бы понимать что и нафига там сделано. И почему автор решил это делать именно так.
> Ну просто если я вижу криптографическую софтину — хотелось бы понимать что
> и нафига там сделано. И почему автор решил это делать именно
> так.а что непонятно-то? EnRUPT — быстрый и простой. при этом достаточен для «домашнего применения». но если охота — замени на другой, в чём трабл-то?
терморектальный криптоанализ так и останется самым быстрым методом взлома.
weakest links ....
Да за...бали уже терморектальные криптоанализаторы своим идеотизмом. Ложите ключи от своей квартиры под коврик на пороге, всё равно, отдадите же. Не, а лучше сэконьме на покупке замков - не покупайте их вообще!
> терморектальный криптоанализ так и останется самым быстрым методом взлома.
> weakest links ....1) Он отличается ценным свойством: его сложно не заметить.
2) Боюсь что я не вспомню 256-битный ключ при вообще любом методе дознания...
>> терморектальный криптоанализ так и останется самым быстрым методом взлома.
>> weakest links ....
> 1) Он отличается ценным свойством: его сложно не заметить.Поэтому, как правило, доблестного криптозащитника после анализа могут запросто отправить в /dev/null.
> 2) Боюсь что я не вспомню 256-битный ключ при вообще любом методе дознания...
Да и не введешь его при нормально доступе, раз не помнишь.
> Да и не введешь его при нормально доступе, раз не помнишь.Я могу его взять с некоего маленького носителя. Ну там флешки, SD карты. Думаю вы догадываетесь что делается с таким носителем при пиковой ситуации.
Один я заметил скрытую рекламу AMD?>При проведении теста на системе с процессором Intel Core i7-2630QM (Sandy Bridge 2GHz) была продемонстрирована производительность в 531 мебибайт в секунду
>при использовании процессора AMD FX-8150 (Bulldozer 3.6GHz) производительность составила 628 мебибайт в секунду
> Один я заметил скрытую рекламу AMD?Да ладно, просто FX-8xxx у амд - довольно приличные числокрушилки.
Только вот интел имеет 3,5 циклов на байт, а амд 5,5. Притом что у АМД и частота выше почти в 2 раза, лол.
Интересно как этот алгоритм поведет себя на ZFS, против SHA-256
> Интересно как этот алгоритм поведет себя на ZFS, против SHA-256Возьми сорц, влупи, проведи тесты, опубликуй. Благодарное
человечество удовлетворит свое и твое любопытство.
>> Интересно как этот алгоритм поведет себя на ZFS, против SHA-256
> Возьми сорц, влупи, проведи тесты, опубликуй. Благодарное
> человечество удовлетворит свое и твое любопытство.я сначала это и хотел предложить, а потом на ник внимательней посмотрел: есть мнение, что даже с изи в данном случае толку будет больше.
