1.1, анонимус12345 (?), 10:59, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –35 +/– |
>можно обойтись 7 раундами вместо 10 при сохранении того же уровня надёжности (для наглядности приводится пример с перемешиванием фруктов в миксере - через 7 секунд фрукты уже полностью перемешаны и дополнительные 3 секунды не скажутся на консистенции смеси).
доказательство от бога, пусть и "для наглядности", но сравнение конечно замечательное, домохозяйкам понравится
| |
|
2.2, funny.falcon (?), 11:04, 12/01/2020 [^] [^^] [^^^] [ответить]
| +27 +/– |
Это не доказательство, а объяснение. Аргументация в публикации про функцию, доказательства в публикациях, на которые она ссылается.
| |
|
3.30, Аноним (30), 15:30, 12/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Сначала "шифруем весь веб эллиптическими кривыми", которые подозрительно малы, теперь хеши делаем по проще. Моя паранойя зашкаливает ... в холодном поту снится заговор анб по прослушке всего мира ...
| |
|
4.70, Аноним (-), 06:36, 13/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
The perfection is not when there is nothing to add, but when there is nothing to remove (some wikipedia deletionist's motto)
| |
|
5.162, jt3k (ok), 19:10, 29/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Перевод не забываем добавлять:
"Совершенство заключается не в том, когда нечего добавить, а в том, когда нечего удалить (девиз какого-нибудь удалителя из Википедии). "
| |
|
|
|
|
3.64, Ivan_83 (ok), 01:30, 13/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Если ты меняешь поведение функции - она уже не будет blake3.
Можешь точно так же взять AES и вместо 10/12 раундов сделать 16-128, только это не будет AES уже.
| |
|
4.71, Аноним (-), 06:37, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
DJB вас тут знатно затроллил в Salsa/ChaCha - он там таки это параметром обозвал :)
| |
4.101, BigBoobs (?), 15:10, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
>взять AES и вместо 10/12 раундов сделать 16-128, только это не будет AES уже.
Главное, что криптостойкость не уменьшится. И весьма вероятно возрастёт.
| |
|
|
6.124, Аноним (124), 11:26, 14/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
В изначальных rijndael вроде и так бывало. AES - это несколько стандартизированных параметров rijndael, если кто в танке.
Само по себе увеличение раундов улучшает перемешивание и усложняет криптоанализ. Просто от числа раундов и тормозить сильнее начинает. Так что число раундов пытаются брать "достаточным" - и не более того.
| |
|
5.163, jt3k (ok), 19:13, 29/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
если кубик рубика долго мешать то рано или поздно он всоже соберётся.
А если его мешать одним и тем же способом то он соберётся быстрее. инфа сотка - попробуйте на досуге
| |
|
|
|
2.75, Ретроград (?), 09:22, 13/01/2020 [^] [^^] [^^^] [ответить]
| –4 +/– |
Только оно неправильное в корне, ибо хэширование - это не блендер. Корректнее было бы сказать "сколько разрезов нужно сделать в яблоке, чтоб его нельзя было восстановить?" Ибо при хэшировании информация не перемешивается в кашу (несмотря на название "хэширование"), а аккуратно разрезается на дольки, которые переставляются. И тут вдруг оказывается, что чем больше - тем лучше.
| |
|
3.79, Nortrum (ok), 10:44, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Нет, если просто делать дольки, то в итоге остаётся весь тот-же объект, просто в мелких кусочках. Хэш функция же не сохраняет все данные, а предсказуемо перемешивает и оставляет только сущность данных, а не сами данные.
| |
3.91, Аноним (91), 13:40, 13/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вполне нормальная аналогия. Хеширование - это хорошенько проблендерить и взять чайную ложку из получившейся смеси. После хорошей хеш-функции в чайной ложке будут составляющие всех фруктов, но ни один из них воссоздать из неё не удастся.
| |
|
4.97, Аноним (-), 14:54, 13/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> ни один из них воссоздать из неё не удастся.
Генетики готовы с этим поспорить :)
| |
|
5.122, Y (??), 04:43, 14/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Генетики восстановят вид и вкус фрукта, но не смогут создать "побитную" копию.
| |
5.134, None (??), 15:54, 14/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Если на 7 раунде фрукты оказались порезаны на сахара и аминокислоты, генетики могут отдыхать.
| |
|
|
|
|
1.3, Аноним (3), 11:05, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
И каким же образом гарантируется отсутствие коллизий? Длина хэша то всё равно конечна, хотя и возможно там огромный выход, но всё таки.
| |
|
2.4, Аноним (4), 11:25, 12/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Гарантировать можно только, что у данных размером с длину хэша и меньше нет коллизий. Но что они имели в виду мне так же не понятно.
| |
|
3.41, Нонон (?), 17:00, 12/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Нельзя такое гарантировать))))
Это уже больше вариантов чем хешей. Потому что у хешей только одна длина
| |
|
4.54, Аноним (54), 20:55, 12/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Можно. Входные данные дополняются нулями до нужного размера у большинства хеш-функций.
| |
|
|
2.6, funny.falcon (?), 11:56, 12/01/2020 [^] [^^] [^^^] [ответить]
| +9 +/– |
Думаю, имеются в виду именно «преднамеренные» коллизии, иными словами, атаки на хэш-функцию. Т.е. функция, как уверенны авторитетные авторы, не допускает нахождение коллизий проще, чем brute-force (т.е. чем методом полного перебора).
Парадокс дней рождения конечно же, ни кто не отменял. (на нем и основывается bruteforce, с которым сравнивают все остальные способы атак). Но для хэша с результатом в 256 бит ожидать случайного совпадения хэш-суммы - это нужно быть очень большим оптимистом.
Также можно сформулировать, что нахождение коллизий является NP задачей, ноне является P задачей.
| |
2.15, Аноним (15), 12:46, 12/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Отсутствие коллизий не гарантируется. Трудность их нахождения тоже. Это имеет непосредственное отношение к проблеме p ?? np;
| |
2.34, Аноним (34), 16:00, 12/01/2020 [^] [^^] [^^^] [ответить]
| +19 +/– |
> И каким же образом гарантируется отсутствие коллизий?
Гарантия два года.
| |
|
|
4.144, KonstantinB (??), 21:46, 14/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это не соответствует определению хэш-функции :)
A hash function is any function that can be used to map data of arbitrary size to fixed-size values.
| |
|
|
2.151, Ананимус (?), 11:56, 15/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Гарантируется, что если у тебя есть условный набор данных A и его хеш H1, то нельзя (за разумное время) подобрать произвольный контент B с хешом H2, таким образом, чтобы H1 = H2. То есть на каких-то данных так и будет, но сделать это специально (залить в установщик дистрибутива эксплоит таким образом, чтобы хеш-суммы сошлись) слишком трудоемко.
| |
|
|
2.7, funny.falcon (?), 12:01, 12/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Алгоритм предусматривает использование векторных инструкций для параллелизации вычислений. Собственно, они и объясняют, что использование векторных инструкций даёт больший выигрыш в сравнении с аналогичной конструкцией над 64битными словами т.к стейт в два раза меньше и для его перемешивания требуется меньше раундов.
Если векторные инструкции задействовать не получается, то больший стейт над 64 битными словами и с блоком в два раза большего размера будет эффективнее. Но aarch64 имеет векторные инструкции.
| |
|
|
2.11, funny.falcon (?), 12:15, 12/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Это не сифер.
Хотя, т.к алгоритм имеет режим генерации очень большого результат, его можно приспособить для поточного шифра. Но зачем?
К тому же, для диска поточный шифр не очень-то применим. Можно, опять-таки, воспользоваться недавно изобретённой конструкцией, когда блок разбивается на неравные части: маленькую и большую. Маленькая шифруется блочным шифром с использованием хешсуммы от большой в качестве IV. Затем большая шифруется поточным шифром с использованием зашифрованной маленькой части в качестве IV. В оригинале использовались AES128, ChaCha12 и какая-то быстрая не криптографическая хэшфункция для первого этапа. Можно эту первую хэшфункцию и поточный шифр заменить на Blake3, а AES оставить для блочного шифра маленькой части.
| |
|
3.68, Sw00p aka Jerom (?), 02:48, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
>Можно, опять-таки, воспользоваться недавно изобретённой конструкцией, когда блок разбивается на неравные части: маленькую и большую.
Что это там недавно изобрели? поподробнее
| |
|
|
|
2.12, funny.falcon (?), 12:19, 12/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Так не шифруй этим пароли. Авторы прямо говорят: для шифрования паролей есть медленные функции, Argon2 на пример.
А для данных большой кардинальности я пожелаю тебе удачи, терпения, очень много денег и тепловой энергии всей вселенной - они тебе понадобятся, чтобы найти коллизии в 256битном хэше со 128битной надежностью.
| |
|
3.13, Аноним (13), 12:45, 12/01/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
То есть, другие алгоритмы имеют уязвимости, использование которых, позволяет сократить в 10 раз время подбора коллизии, и это плохо. А этот алгоритм из коробки работает в 10 раз быстрее, позволяя провести полный брутфорс в 10 раз быстрее, и это хорошо. Ладно.
| |
|
4.20, funny.falcon (?), 13:52, 12/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Сразу оговорюсь: я говорю не про пароли. Пароли легче подбирать потому, что большинство людей используют простые пароли. Из-за этой человеческой лени приходится использовать медленные алгоритмы потребляющие много памяти. И это не SHA-*.
Если же говорить про данные большой кардинальности (допустим, 128 бит - 22 символьный полностью случайный пароль, или ключ шифрования. Да даже просто достаточно длинный коммерчески важный документ), то на полный перебор с использованием всех вычислительных ресурсов планеты с SHA-256 у тебя ушло бы 10000 миллиардов лет, а сейчас всего 1000 миллиардов лет.
Раз ты искренне беспокоишься о такой разнице, заначит, я полагаю, ты собираешься жить не меньше тысячи миллиардов лет. И твои враги, которых ты боишься, тоже.
| |
|
5.35, Аноним (35), 16:19, 12/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
>128 бит - 22 символьный полностью случайный пароль
Это как? Один символ - 8 бит. как минимум, т.е. в 128 битах 16 символов.
| |
|
6.46, funny.falcon (?), 19:16, 12/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Когда я говорю «пароль», я имею в виду буквенно-символьный. Я так и написал «22 символьный пароль», а не «22 байтовый», чтобы сразу дать намёк на то, что я имею в виду. Конечно, есть возможность набирать с клавиатуры и непечатаемые символы, но я бы не стал ею пользоваться.
Примерным приближением «буквенно-символьного» является Base64 , который кодирует 6 бит на символ. Добавление ещё пары десятков символов все равно целого бита не добавит, а значит приближение довольно верное.
22 символа на 6 бит = 132 бита. Если считать, что мы печатными символами можем закодировать 6.5 бит, то хватит и 20 символов.
| |
6.98, Аноним (-), 15:00, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Это как? Один символ - 8 бит. как минимум
Мечтать не вредно. Есть разница между тем сколько битов используется для хранения и сколько битов энтропии реально содержится.
Вот например password123 теоретически содержит в себе 11 символов. Не менее 88 битов. Практически, его знает любой словарь брутфорса. Кроме того использованы только латинские строчные буквы и цифры, это всего 36 вариантов на символ. То-есть даже если использовать все буквы - это лишь 36^11 а вовсе не 2^88. И это довольно большая разница.
| |
|
|
|
3.56, хотел спросить (?), 21:28, 12/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
> в 256битном хэше со 128битной надежностью
можно про это подробнее? что значит надежность? и почему вполовину меньшая энтропии?
| |
|
4.99, Аноним (-), 15:01, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ну например, birthday paradox гарантирует вам что 2^256 попыток вам делать скорее всего не придется :)
| |
|
5.121, хотел спросить (?), 23:37, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Ну например, birthday paradox гарантирует вам что 2^256 попыток вам делать скорее
> всего не придется :)
давайтие еще разок
1) что называется надежностью?
2) почему она меньше энтропии в 2^128 раз?
| |
|
6.139, Аноним (-), 18:33, 14/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> 1) что называется надежностью?
Обычно пессимистичная оценка числа операций за которые это может получиться взломать.
> 2) почему она меньше энтропии в 2^128 раз?
Почитайте про birthday paradox. За 2^256 попыток вы переберете вообще пространство хэшей. Однако в зависимости от атаки нас интересует вовсе не все множество хешей, а чтобы посчитаный хэш совпал с желаемым. Или даже чтобы совпало с хоть 1 из набора в котором дохрена хэшей. В любом случае это будет валидной коллизией. В примере с людьми в комнате и их днями рождений показывается, что чем больше людей в комнате - тем вероятнее что хоть у кого-то из них дни рождения окажутся в один и тот же день. С коллизиями этот номер тоже работает.
| |
|
7.142, Аноним84701 (ok), 19:13, 14/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Почитайте про birthday paradox. За 2^256 попыток вы переберете вообще пространство хэшей.
> Однако в зависимости от атаки нас интересует вовсе не все множество
Если нас интересует коллизия к конкретным данным/хэшу (о чем в #12 изначально шла речь), то очевидно, что аналогия с "парадоксом дней рождения" тут не сработает -- это все равно, что подсчитать вероятность совпадения дня рождения с _конкретным_ человеком (для 50% вероятности нужна группа даже заметно больше 365/2. Т.е. не сравнить с группов в 23 человека, если допускать совпадения для любых двух персон)
Ваш КО.
| |
|
|
|
|
|
|
1.18, VINRARUS (ok), 13:38, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
>Доступна криптографическая хеш-функция BLAKE3, которая в 10 раз быстрее SHA-2
Жалко шо с файлом весом в 10 Гб на HDD это не распространяется...
| |
|
2.88, Аноним (-), 13:36, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Жалко шо с файлом весом в 10 Гб на HDD это не распространяется...
Дяденьки хайпуют и набивают себе цену, сценариями взятыми буквально из пальца. Что для криптографов как-то не солидно.
| |
|
3.112, funny.falcon (?), 18:53, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ну, разбиение на 64кБ блоки вполне себе полезно. А на таком размере они уже разгоняются до 90% пиковой скорости.
| |
|
|
1.22, Аноним (22), 14:07, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Так понимаю, прекрасно подойдёт для контроля целостности оффлайн-архивов?
| |
|
2.24, Аноним (15), 14:15, 12/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Нет, нельзя. Целлостность подразумевает защиту от вредоносного изменения. В рар5 они только как контрольные суммы используются. Для защиты от вредоносного изменения нужен MAC или цифровая подпись.
| |
|
|
2.27, Васька кот (?), 15:02, 12/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Хешем засабжируют пароли. Те кто это делают в сотни раз умнее рассуждающих тут офисных тараканов.
| |
2.37, Аноним (37), 16:33, 12/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Стоп, а почему не хешировать сабжем пароли, если это нормальная *криптографическая* хеш-функция?
| |
|
3.40, Ilya Indigo (ok), 16:46, 12/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Стоп, а почему не хешировать сабжем пароли, если это нормальная *криптографическая* хеш-функция?
Откуда вы взяли термин *нормальная*?
хеш-функции бывают быстрые и медленные, бывают разной длины ключа но они не бывают нормальными и не нормальными!
Нельзя, потому что она быстрая, а для паролей нужны медленные.
| |
|
4.49, Аноним (49), 20:01, 12/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Так колизии-то в разумное время все равно не подобрать, особенно если солить. Зачем замедлять себя без нужды, если не зачем боятся коллизий?
| |
|
5.52, Аноним (52), 20:34, 12/01/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Если пароль из трёх символов то он перебирается быстро.
Если пароль из 20 символов случайных то можно хешировать без проблем.
Вот только люди не умеют придумывать случайные пароли
| |
|
6.59, пох. (?), 22:43, 12/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
придумывать-то умеют (любой произвольный пароль - "случаен"). Они их, с-ки, запоминать не умеют.
А если придумывать запоминаемые - то рано или поздно они будут подобраны.
| |
|
7.66, Аноним (49), 01:41, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Говорят можно бессмысленные легкозапоминаемые парольные фразы в 60 символов придумывать и никто не подберет
| |
|
8.76, пох. (?), 09:39, 13/01/2020 [^] [^^] [^^^] [ответить] | +/– | придумывать - можно Запомнить - опять же нет ну то есть одну ты запомнишь, есл... текст свёрнут, показать | |
|
|
|
11.153, пох. (?), 12:12, 15/01/2020 [^] [^^] [^^^] [ответить] | +/– | его просто запомнить - проблема Не набор бессвязных слов, а какой именно из нег... текст свёрнут, показать | |
|
10.152, пох. (?), 12:10, 15/01/2020 [^] [^^] [^^^] [ответить] | +/– | чего гуглить - попробуй вспомнить тот пароль А теперь представь, что таких бред... текст свёрнут, показать | |
|
|
8.78, КО (?), 10:43, 13/01/2020 [^] [^^] [^^^] [ответить] | +/– | И при этом нужна хеш функция у которой не будет коллизии для этих 60 символов с ... текст свёрнут, показать | |
|
9.154, пох. (?), 12:13, 15/01/2020 [^] [^^] [^^^] [ответить] | +/– | это же код от нашего чемодана то есть я реально видел такой рутовый пароль ... текст свёрнут, показать | |
|
|
|
|
|
|
|
2.74, Аноним (74), 07:09, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
>Надеюсь сабжем никто не додумается хешировать пароли...
>Применение в режимах ... KDF
Уже.
| |
|
3.113, funny.falcon (?), 19:00, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
KDF имеет много сфер применения.
Например, вы один раз захэшировали свой запоминаемый пароль чем-то вроде Argon2. Надежно? Надежно.
Но один и тот же хэш от пароля везде пихать все равно не надежно.
Потому вы делаете зависимый пароль с ключом-доменом, наследуя его от полученного с помощью Argon2. Здесь уже не требуется медленная хэшфункция, т.к. пространство ключей уже очень большое, и все тормоза на подбор были спрятаны на первом этапе преобразования исходного ключа с помощью аргона.
| |
|
|
1.28, Аноним (28), 15:12, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
Эталонная реализация написана на языке Rust.
В эталонной реализации присутствует код на Си с интересными комментариями, что парни писавшие код на Си не писали на нем с колледжа и не рекомендуют использовать код на Си в своих проектах.
| |
|
2.29, Аноним (34), 15:27, 12/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это будущее, сынок, привыкай. На место одних языков приходят другие.
| |
|
|
4.33, Аноним (34), 15:59, 12/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да не, причем тут скриптовые языки. Я говорю про системное программирование. В системном программировании си больше не язык №1. Точнее, он «номер "один-с-половиной"». Уже потихоньку вытесняется другими языками.
| |
|
5.80, КО (?), 10:44, 13/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Я говорю про системное программирование.
Комментируя задачу про прикладное программирование. :)
| |
|
4.161, 123 (??), 09:13, 28/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Жуть какая, уже 2020, а у вас до сих пор "php рулит". На пенсию не пора?
| |
|
3.61, Аноним (61), 01:06, 13/01/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
Видимо на место си пришёл си, потому что написать все на расте не шмогли.
| |
3.90, Аноним (-), 13:39, 13/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Это будущее, сынок, привыкай. На место одних языков приходят другие.
...поэтому вот вам крипто, прямо из репов контролируемых DRMщиками из мозиллы. С стремным обвесом оттуда же. Завязанное на LLVM контролируемый гуглом. Ну офигенно, чо. Сразу доверие к такому крипто повышается.
| |
|
2.36, leap42 (ok), 16:32, 12/01/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Эталонная реализация написана на языке Rust.
> В эталонной реализации присутствует код на Си
лол, там 42% на Си
| |
|
3.92, Аноним (-), 13:40, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Да хоть на вижалбейсике пусть пишут.
И чего с ним потом делать? Самому переписывать? А точно не облажаешься? Крипто штука деликатная. Пара необдуманных операций - и ваша карта бита.
| |
|
4.115, Ivan_83 (ok), 19:07, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Есть же тестовые вектора.
У меня своих реализаций хэшей хватает, и ничего.
| |
|
5.126, Аноним (124), 11:33, 14/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Тестовые вектора не гарантируют отсутствие нежелательных свойств.
Ну вот например: если крипто отрабатывает за разное время для разных данных/ключей/..., это уже хреново - потому что атакующий способный точно измерять время начинает получать очень приличное инфо о том что алгоритм реально делал. И чему был равен вон тот битик, или вот этот вот.
> У меня своих реализаций хэшей хватает, и ничего.
Надеюсь, это не позиционируется как что-то криптостойкое. Потому что есть 99.9% вероятности что оно ни разу не.
| |
|
6.157, Ivan_83 (ok), 22:46, 16/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Конечно позиционирую, как минимум Super Top Secret надо в мои алгоримы пихать :)
Меня эти детские фобии вокруг крипты уже достали, если чесно.
| |
|
|
|
|
|
1.32, Аноним (32), 15:58, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
>с гарантией отсутствия коллизий
дальше можно не читать. используйте то что стандартизировано - sha3
| |
|
2.38, Аноним (37), 16:35, 12/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
А что вас тут смущает? В SHA-3 как бы тоже коллизий нет (ну вы должны понимать, что это жаргон, на самом деле надо читать "нельзя подобрать коллизию за вменяемое время")
| |
|
3.39, Аноним (32), 16:39, 12/01/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
какой жаргон? коллизии есть и точка. а время скажем на квантовом компе будет вменяемым
| |
|
4.44, Аноним (44), 17:44, 12/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
>квантовом компе
Это который на квантовых наноточках сингулярности с элементами ИИ?
| |
4.47, BigBoobs (?), 19:18, 12/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
В квантовом кмопьютере время не будет вменяемым т.к. алгоритмы Гровера и Шора позволят сократить время перебора всего в около два раза каждый т.к. вместе они смогут коратить время перебора примерно раза в три.
| |
4.50, Аноним (49), 20:03, 12/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
До квантового компа ещё ой как далеко, ещё неизвестно даже, можно ли построить достаточно большой квантовый компьютер. Да и как сказали другие комментаторы, квантовик тут особо не помогает
| |
|
5.51, BigBoobs (?), 20:11, 12/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Уже просторили таковой с 4000 кубитами, чего более чем достаточно для взлома криптографии. Только пользы от него ноль из-за высокой зашумлённости т.е. он нормально вообще не работает, но построить можно.
| |
|
6.55, Аноним (55), 21:24, 12/01/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
Строить устройства, которые вот-вот cкоро уже точно заработают, можно бесконечно.
| |
6.67, Аноним (49), 01:42, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Вот именно, кто знает, может они так и останутся шумными, или ещё какое ограничение всплывет
| |
6.93, Аноним (93), 13:42, 13/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Уже просторили таковой с 4000 кубитами, чего более чем достаточно для взлома
> криптографии. Только пользы от него ноль из-за высокой зашумлённости т.е. он
> нормально вообще не работает, но построить можно.
Вечные двигатели в позапрошлом веке тоже строили. Правда, ни один так и не заработал в результате.
| |
|
7.102, BigBoobs (?), 15:13, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Зато уже давно придумали и реализовали холодный термоядерный синтез и как следствие вечный двигатель не нужен посколько процесс термоядерного синтеза идёт с использованием таких широкодоступных материалов, как никель и т.п., что исключает всякую радиацию полностью.
Кому интересно гуглите - холодный термоядерный синтез Андреа Росси
| |
|
|
|
|
|
12.140, Аноним (-), 18:52, 14/01/2020 [^] [^^] [^^^] [ответить] | +1 +/– | Ну например затем что климат перекашивает, и если подогреть планету еще на пару ... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
12.148, Аноним (148), 06:16, 15/01/2020 [^] [^^] [^^^] [ответить] | +/– | Вот это то как раз и странно Не характерно для ядерных реакций Более того - ес... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
4.83, Аноним (83), 11:19, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> какой жаргон? коллизии есть и точка. а время скажем на квантовом компе
> будет вменяемым
Летят Шерлок Холмс и Доктор Ватсон на воздушном шаре, приземляются в неизвестном месте и видят человека.
— Сэр, — говорит Холмс. — Не могли бы вы сказать нам, где мы находимся?
— Могу, сэр, — отвечает тот. — Вы находитесь в корзине воздушного шара.
Тут шар опять поднимается, Холмс подумал и говорит:
— Перед нами типичный теоретик!
— Поразительно, Холмс! — восклицает Ватсон. — Как вы догадались?
— Элементарно, Ватсон, по его ответу. Ответ был абсолютно точен, но никому ненужен.
| |
|
|
|
1.48, Аноним (-), 19:42, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
Стилистически статья никакая.
Научная составляющая слабая и, видимо, написана неспециалистом.
Поэтому заминусованный товарищ прав.
| |
1.60, Случайный прохожий (?), 23:22, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Молодцы ребята) Каждый раз когда читаю такие новости, становится немножко грустно от осознания того, насколько далеко ушли некоторые люди в плане интелекта, а ты плетешься где в хвосте человечества и догнать лучших его представитеоей вряд ли когда-то сможешь: так уже закостенел и исчерпал свой потенциал - не быть тебе ни выдающимся учёным, ни великим математиком. Обычный пользователь, не творец.
| |
|
2.81, Аноним (81), 10:48, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Это только так кажется. Я вот тоже могу взять CRC-32, масштабировать его до 256 бит и заявить, что в моём алгоритме нет коллизий. А производительность в сотни раз выше любых других хешей. Ну в CRC-32 их ведь никто не нашёл за все эти годы, значит их там нет.
| |
|
3.84, Аноним (83), 11:34, 13/01/2020 [^] [^^] [^^^] [ответить] | +1 +/– | code include stdio h unsigned long c,c2,p2,pol 0xEDB88320 long n,k main ... большой текст свёрнут, показать | |
|
|
5.123, Stax (ok), 10:37, 14/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
И тем не менее, есть задачи, где важен сверхбыстрый хэш, и не стоит вопрос злоумышленника, надо только защититься от ошибок данных. Те же ethernet-фреймы с crc32, и tcp/ip.. Или zfs с его fletcher по-умолчанию, который еще быстрее, чем crc.. И переключение на надежный хэш типа sha256 дает ощутимый удар по производительности.
Да что там, даже для iSCSI (где рекомендуют включать свой протокольный CRC, т.к. CRC от TCP/IP недостаточно надежен для этого применения - внутренний более умный и отдельно считается для заголовков и данных) включение CRC дает до 30% оверхед использования проца (https://pdfs.semanticscholar.org/7208/722a1e84efe097d802c59a52e353ad715533.pdf). И это при том, что уже есть CRC в TCP/IP и Ethernet (впрочем, эту парочку нынче обычно считает сама сетевуха).
Вот любопытно, BLAKE3 с его производительностью может заменить CRC/fletcher/adler для их текущих применений? Или они все еще несравнимо быстрее?
| |
|
6.130, Аноним (-), 13:05, 14/01/2020 [^] [^^] [^^^] [ответить] | +/– | А кто с этим спорил По поводу чего есть куча быстрых хэшей без гарантии криптос... большой текст свёрнут, показать | |
|
|
|
|
|
1.62, Ivan_83 (ok), 01:27, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"Основные отличия BLAKE3 от BLAKE2: Три режима работы: хэширование, хеширование с ключом (HMAC) и формирование ключа (KDF)." -
ВРАНЬЁ!
HMAC, KDF - функции работающие поверх любой хэш функции.
| |
|
2.73, funny.falcon (?), 07:02, 13/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
HMAC приведен как пример того, что можно заменить функцией BLAKE3.
HMAC придуман для того, чтобы приспособить функцию хеширования, не имеющая параметр "ключ", доя хеширования "с ключом". Blake3 имеет параметр "ключ", а значит он может быть использован в таком режиме без использования конструкции HMAC.
Конечно, вас ни кто не останавливает от использования HMAC, просто это будет лишним.
Аналогично KDF придуман чтобы функцию с ограниченным размером результата превратить в функцию с условно неограниченным размером. Но BLAKE3 имеет режим генерации условно неограниченного результата, и потому может применяться без использования конструкции KDF.
| |
|
3.85, Ivan_83 (ok), 11:47, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Только вот HMAC усиливает хэш функцию настолько, что HMAC-MD5 считается до сих пор секурным.
| |
|
4.114, funny.falcon (?), 19:04, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Только вот BLAKE3 настолько силен, что его не нужно усиливать.
Ну и HMAC то особо не усиливает. Он лечит некоторые болезни, это правда. Но не усиливает.
| |
|
|
6.119, funny.falcon (?), 21:25, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Md5 и sha1 как минимум были подвержены length extension. Собственно, потому HMAC и сделан таким, каким сделан. То, что HMAC вдруг смог замаскировать выявленные потом другие болячки, это получилось случайно.
Md5 и SHA1/SHA256 не имеют встроенной возможности подмешать ключ. Т.е. они не являются MAC. Потому и потребовались схемы адаптеры (HMAC, NMAC).
BLAKE3 имеет такой режим. Т.е. он уже является MAC.
| |
|
|
4.156, Аноним (156), 15:45, 16/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Только вот HMAC усиливает хэш функцию настолько, что HMAC-MD5 считается до сих пор секурным
Это исправят переходом на BLAKE3
| |
|
5.158, Ivan_83 (ok), 22:48, 16/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Иди расскажи это ведндорам, чтобы они его встроили вместо md5/hmac-md5 во все протоколы, типа поп3, радиус и прочих.
| |
|
|
|
|
1.65, Ivan_83 (ok), 01:34, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
То что blake3 быстрее на мелких блоках чем другие говорит только об одном: у него быстрая инициализация и быстрая финализация.
У md5/sha1/sha2 инициализация быстрая - просто залить константы, а последний шаг нет, там помнится 2-3 раза вызывается transform для блока, те на коротких входных данных они имеют заметный оверхэд.
| |
1.77, PnD (??), 10:26, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ага, появился шанс привернуть поблочные хэши к ФС "общего" назначения.
Т.к. и не "это же медленно" (sha*), и не "отстой" (crc32,md4…5).
| |
|
2.95, Аноним (93), 13:45, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Ага, появился шанс привернуть поблочные хэши к ФС "общего" назначения.
> Т.к. и не "это же медленно" (sha*), и не "отстой" (crc32,md4…5).
Ага, блин, с реализацией на расте... к редокс осу какому. Много там файловых систем?
| |
|
3.96, Аноним84701 (ok), 14:50, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Ага, блин, с реализацией на расте... к редокс осу какому. Много там
> файловых систем?
Хм. Интересно, где используются оригинальные (эталонные) реализации SHA, MD, <длинный список> и что мешает реализовать BLAKE3 хоть на брейнфаке?
| |
|
4.103, Аноним (-), 16:28, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ну понятно что в кернелы оно в таком виде не попадет. И в любом случае для чексумм это малость оверкилл, а для защиты от подмены одного только хэша маловато.
| |
|
5.106, Аноним84701 (ok), 17:48, 13/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> И в любом случае для чексумм это малость оверкилл,
Емнип, в том же ZFS крипто-хеши(sha) именно в таком качестве [чексуммы] используют при dedup или nop-write.
| |
|
6.131, Аноним (131), 13:10, 14/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Емнип, в том же ZFS крипто-хеши(sha) именно в таком качестве [чексуммы] используют
> при dedup или nop-write.
Если не ошибаюсь, sha там один из вариантов чексумм, на случай если кому флетчера кажется мало. В btrfs тоже недавно какие-то из sha туда прикрутили. Вместе с blake2b и xxhash - смотря кому чего в приоритете.
Ну и да, чексум блока можно и при дедупе поюзать. Если у блоков заявлен одинаковый чексум, есть основания подозревать что блоки одинаковые. Не знаю за zfs а btrfs таки проверяет фактическую идентичность до того как дедупануть. Если и правда совпало - ок, блок заменяется ссылкой.
| |
|
7.155, пох. (?), 13:26, 15/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Если не ошибаюсь, sha там один из вариантов чексумм, на случай если
практически никем вменяемым не используемый - потому что есть edonr (но он у кого надо есть, freebsd ниасилили) и skein. Первый на порядок, второй в разы быстрее.
> Ну и да, чексум блока можно и при дедупе поюзать. Если у
> блоков заявлен одинаковый чексум, есть основания подозревать что блоки одинаковые. Не
> знаю за zfs а btrfs таки проверяет фактическую идентичность до того
в случае zfs свято верующие в криптохэши (вероятно, это какая-то подсекта верующих в реализуемость архиватора del) могут эту проверку выключать - что существенно улучшает жизнь дедупликов, с некоторым риском что их котики превратятся таки в ротики.
Ибо криптохэши ни разу не гарантируют что блоки таки одинаковые. Они гарантируют невозможность намеренно подобрать такой блок.
В отличие от обычных хэшей, задача которых - гарантировать _существенные_ отличия на _похожих_ исходных данных (то есть защищать от битфлипов, а не сознательных подмен)
| |
|
|
|
|
|
|
|