The OpenNET Project / Index page

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

Доступна криптографическая хеш-функция BLAKE3, работающая в 10 раз быстрее SHA-2

12.01.2020 09:26

Опубликована финальная реализация алгоритма BLAKE3, предлагающего криптографическую хеш-функцию, рассчитанную на такие применения, как проверка целостности файлов, аутентификация сообщений и формирование данных для криптографических цифровых подписей. BLAKE3 не предназначена для хеширования паролей (для паролей рекомендуется использовать медленные хеш-функции yescrypt, bcrypt, scrypt или Argon2), так как нацелена на максимально быстрое вычисление хешей. Рассматриваемая хеш-функция нечувствительна к размеру хешируемых данных и защищена от атак по подбору коллизий и нахождению прообраза. Эталонная реализация BLAKE3 опубликована под двойной лицензией - общественное достояние (CC0) и Apache 2.0.

Ключевым отличием новой хеш-функции является очень высокая производительность вычисления хеша при сохранении надёжности на уровне SHA-3. По умолчанию размер результирующего хеша в BLAKE3 составляет 32 байта (256 бит), но он может быть расширен до произвольных значений. В тесте на генерацию хеша для файла, размером 16 КБ, BLAKE3 опережает SHA3-256 в 15 раз, SHA-256 - в 12 раз, SHA-512 - в 8 раз, SHA-1 - в 6 раз, а BLAKE2b - в 4 раза. Значительный отрыв сохраняется и при обработке очень больших объёмов данных, например, BLAKE3 оказался быстрее SHA-256 в 8 раз при вычислении хеша для 1ГБ случайных данных.

Алгоритм разработан известными специалистами по криптографии (Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O'Hearn) и продолжает развитие алгоритма BLAKE2 и применяет для кодирования дерева цепочек блоков механизм Bao. В отличие от BLAKE2 (BLAKE2b, BLAKE2s), в BLAKE3 для всех платформ предложен единый алгоритм, не привязанный к разрядности и размеру хеша.

Повышения производительности удалось добиться благодаря сокращению числа раундов с 10 до 7 и раздельному хешированию блоков кусочками по 1 Кб. По заявлению создателей, они нашли убедительное математическое доказательство, что можно обойтись 7 раундами вместо 10 при сохранении того же уровня надёжности (для наглядности можно привести пример с перемешиванием фруктов в миксере - через 7 секунд фрукты уже полностью перемешаны, и дополнительные 3 секунды не скажутся на консистенции смеси). При этом некоторые исследователи выражают сомнение, полагая, что даже если в настоящее время 7 раундов достаточно для противостояния всем известным атакам на хеши, то дополнительные 3 раунда могут оказаться полезны в случае выявления новых атак в будущем.

Что касается разделения на блоки, то в BLAKE3 поток разбивается на кусочки по 1 Кб и каждый кусочек хешируется независимо. На основе хешей кусочков на базе бинарного дерева Меркла формируется один большой хеш. Указанное разделение позволяет решить проблему с распараллеливанием обработки данных при вычислении хеша - например, можно использовать 4-поточные SIMD-инструкции для одновременного вычисления хешей 4 блоков. Традиционные хеш-функции SHA-* обрабатывают данные последовательно.

Особенности BLAKE3:

  • Высокая производительность;
  • Безопасность, в том числе стойкость к атаке удлинением сообщения, которой подвержен SHA-2;
  • Обеспечение распараллеливания вычислений на любое число потоков и SIMD-каналов;
  • Возможность инкрементального обновления и верифицированной обработки потоков;
  • Применение в режимах PRF, MAC, KDF, XOF и как обычный хеш;
  • Единый алгоритм для всех архитектур, быстрый как на системах x86-64, так и на 32-разрядных процессорах ARM.

Основные отличия BLAKE3 от BLAKE2:

  • Использование бинарной древовидной структуры, позволяющей добиться неограниченного параллелизма при вычислении хеша.
  • Сокращение числа раундов с 10 до 7.
  • Три режима работы: хеширование, хеширование с ключом (HMAC) и формирование ключа (KDF).
  • Отсутствие дополнительных накладных расходов при хешировании с ключом за счёт использования области, ранее занимаемой блоком параметров ключа.
  • Встроенный механизм работы в форме функции с удлиняемым результатом (XOF, Extendable Output Function), допускающей распараллеливание и позиционирование (seek).


  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Представлена хеш-функция BLAKE2, претендующая на роль высокопроизводительной замены MD5 и SHA1
  3. OpenNews: Компания Google открыла код набора хэш-функций FarmHash
  4. OpenNews: Предложен метод определения коллизий в SHA-1, пригодный для атаки на PGP
  5. OpenNews: Выбран финальный алгоритм для SHA-3
  6. OpenNews: Генератор псевдослучайных чисел на основе GPS
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/52173-blake
Ключевые слова: blake, hash, sha
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (153) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, анонимус12345 (?), 10:59, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –35 +/
    >можно обойтись 7 раундами вместо 10 при сохранении того же уровня надёжности (для наглядности приводится пример с перемешиванием фруктов в миксере - через 7 секунд фрукты уже полностью перемешаны и дополнительные 3 секунды не скажутся на консистенции смеси).

    доказательство от бога, пусть и "для наглядности", но сравнение конечно замечательное, домохозяйкам понравится

     
     
  • 2.2, funny.falcon (?), 11:04, 12/01/2020 [^] [^^] [^^^] [ответить]  
  • +27 +/
    Это не доказательство, а объяснение. Аргументация в публикации про функцию, доказательства в публикациях, на которые она ссылается.
     
  • 2.19, Аноним (19), 13:40, 12/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну тебе то понравилось?
     
     
  • 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.82, Dennis (??), 10:49, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    © Antoine de Saint-Exupery
     
  • 5.162, jt3k (ok), 19:10, 29/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Перевод не забываем добавлять:

    "Совершенство заключается не в том, когда нечего добавить, а в том, когда нечего удалить (девиз какого-нибудь удалителя из Википедии). "

     
  • 2.45, BigBoobs (?), 19:07, 12/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что мешает в исходниках поменять 7 на 10 или 20?
     
     
  • 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 уже.

    Главное, что криптостойкость не уменьшится. И весьма вероятно возрастёт.

     
     
  • 5.109, анон (?), 18:04, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    а вот єто ооооочень не факт, что не уменьшится!
     
     
  • 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.104, Аноним (104), 16:48, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Генетиков тоже в блендер.
     
  • 5.122, Y (??), 04:43, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Генетики восстановят вид и вкус фрукта, но не смогут создать "побитную" копию.
     
     
  • 6.125, Аноним (124), 11:27, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это уже не их прероатива.
     
  • 5.134, None (??), 15:54, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если на 7 раунде фрукты оказались порезаны на сахара и аминокислоты, генетики могут отдыхать.
     
     
  • 6.136, Аноним (-), 18:25, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нифига у вас блендер...
     

  • 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 +/
    > И каким же образом гарантируется отсутствие коллизий?

    Гарантия два года.

     
     
  • 3.145, KonstantinB (??), 21:47, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    По закону о защите прав потребителей.
     
  • 2.86, KonstantinB (??), 13:17, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Приведите пример хэш-функции, которая гаранирует отсутствие коллизий.
     
     
  • 3.137, Аноним (-), 18:27, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    f(x) = x :)
     
     
  • 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. То есть на каких-то данных так и будет, но сделать это специально (залить в установщик дистрибутива эксплоит таким образом, чтобы хеш-суммы сошлись) слишком трудоемко.
     

  • 1.5, Аноним (5), 11:48, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > 32-разрядных процессорах ARM.

    А на aarch64 замедляется?

     
     
  • 2.7, funny.falcon (?), 12:01, 12/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Алгоритм предусматривает использование векторных инструкций для параллелизации вычислений. Собственно, они и объясняют, что использование векторных инструкций даёт больший выигрыш в сравнении с аналогичной конструкцией над 64битными словами т.к стейт в два раза меньше и для его перемешивания требуется меньше раундов.

    Если векторные инструкции задействовать не получается, то больший стейт над 64 битными словами и с блоком в два раза большего размера будет эффективнее. Но aarch64 имеет векторные инструкции.

     

  • 1.8, InuYasha (?), 12:02, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Для фулл-драйв-ынкрипшын сгодится?
     
     
  • 2.9, Аноним (9), 12:13, 12/01/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Лучше crc8 возьми.
     
     
  • 3.87, Аноним (-), 13:34, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше crc8 возьми.

    Лучше bloom filter, из соседней новости.

     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    >Можно, опять-таки, воспользоваться недавно изобретённой конструкцией, когда блок разбивается на неравные части: маленькую и большую.

    Что это там недавно изобрели? поподробнее

     
     
  • 4.111, funny.falcon (?), 18:48, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    http://www.opennet.ru/opennews/art.shtml?num=50123
     
  • 2.110, анон (?), 18:06, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    єто не ынкрыпшын это хеш функция для ХЕШИРОВАНИЯ!
     

  • 1.10, Аноним (10), 12:14, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Это чтобы ускорить поиск коллизий?
     
     
  • 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.25, Аноним (15), 14:20, 12/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Тонко.
     
  • 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 человека, если допускать совпадения для любых двух персон)

    Ваш КО.

     
     
  • 8.160, funny.falcon (?), 00:05, 18/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Но атак на криптографическую функцию сформулировано несколько Одна из них прос... текст свёрнут, показать
     
  • 7.147, хотел спросить (?), 04:44, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Я про дни рождения знаю Но так и не было озвучено почем... большой текст свёрнут, показать
     

  • 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 +/
    Так понимаю, прекрасно подойдёт для контроля целостности оффлайн-архивов?
     
  • 1.23, Конь Благородный (?), 14:08, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В WinRar при сохранении и проверке данных можно использовать BLAKE2 (скоро и 3), что я успешно и делаю.
     
     
  • 2.24, Аноним (15), 14:15, 12/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, нельзя. Целлостность подразумевает защиту от вредоносного изменения. В рар5 они только как контрольные суммы используются. Для защиты от вредоносного изменения нужен MAC или цифровая подпись.
     

  • 1.26, Ilya Indigo (ok), 14:46, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Надеюсь сабжем никто не додумается хешировать пароли...
     
     
  • 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.69, АнонАнон (?), 04:25, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мало где можно использовать 60 символов в пароле Часто видел потолок в 12-22 си... текст свёрнут, показать
     
  • 8.76, пох. (?), 09:39, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    придумывать - можно Запомнить - опять же нет ну то есть одну ты запомнишь, есл... текст свёрнут, показать
     
     
  • 9.89, Аноним (-), 13:37, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Загугли про correct battery staple horse ... текст свёрнут, показать
     
     
  • 10.100, Аноним84701 (ok), 15:09, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если делать привязку к ресурсу, то энтропия там будет далека от 2 44 Если не де... текст свёрнут, показать
     
     
  • 11.153, пох. (?), 12:12, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    его просто запомнить - проблема Не набор бессвязных слов, а какой именно из нег... текст свёрнут, показать
     
  • 10.152, пох. (?), 12:10, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    чего гуглить - попробуй вспомнить тот пароль А теперь представь, что таких бред... текст свёрнут, показать
     
  • 8.78, КО (?), 10:43, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И при этом нужна хеш функция у которой не будет коллизии для этих 60 символов с ... текст свёрнут, показать
     
  • 8.105, Аноним (105), 17:12, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Лукьяненко и его Фальшивые зеркала Один из героев в качестве пароля использов... текст свёрнут, показать
     
     
  • 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. Здесь уже не требуется медленная хэшфункция, т.к. пространство ключей уже очень большое, и все тормоза на подбор были спрятаны на первом этапе преобразования исходного ключа с помощью аргона.

     

     ....большая нить свёрнута, показать (18)

  • 1.28, Аноним (28), 15:12, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Эталонная реализация написана на языке Rust.
    В эталонной реализации присутствует код на Си с интересными комментариями, что парни писавшие код на Си не писали на нем с колледжа и не рекомендуют использовать код на Си в своих проектах.
     
     
  • 2.29, Аноним (34), 15:27, 12/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это будущее, сынок, привыкай. На место одних языков приходят другие.
     
     
  • 3.31, Адекват (ok), 15:55, 12/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да-да, когда-то СИ рулил, щас питон и php. Спрос и предложение.
     
     
  • 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% на Си

     
  • 2.63, Ivan_83 (ok), 01:28, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да хоть на вижалбейсике пусть пишут.
     
     
  • 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 надо в мои алгоримы пихать :)
    Меня эти детские фобии вокруг крипты уже достали, если чесно.
     
  • 2.127, Аноним (127), 11:35, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    https://crates.io/crates/blake3
     

  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Зато уже давно придумали и реализовали холодный термоядерный синтез и как следствие вечный двигатель не нужен посколько процесс термоядерного синтеза идёт с использованием таких широкодоступных материалов, как никель и т.п., что исключает всякую радиацию полностью.
    Кому интересно гуглите - холодный термоядерный синтез Андреа Росси
     
     
  • 8.118, Аноним84701 (ok), 20:45, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Поправил, не благодарите ... текст свёрнут, показать
     
     
  • 9.120, BigBoobs (?), 22:50, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Для ретраградов вот ссылка https zoom cnews ru rnd article item v_rossii_povto... текст свёрнут, показать
     
     
  • 10.129, Аноним (-), 12:58, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ссылка 2015 года NASA кстати вроде с 2011 года чем-то таким развлекалось но ... текст свёрнут, показать
     
     
  • 11.133, BigBoobs (?), 15:26, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем результаты сейчас если США вложили столько бабла в сланцевый бум и начинаю... текст свёрнут, показать
     
     
  • 12.140, Аноним (-), 18:52, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну например затем что климат перекашивает, и если подогреть планету еще на пару ... большой текст свёрнут, показать
     
  • 8.128, Аноним (128), 12:54, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Почти-вечный двигатель в центре Солнечной системы висит Присылает море энергии ... текст свёрнут, показать
     
     
  • 9.132, BigBoobs (?), 15:23, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Во первый солнце просуществует несколько милилардов лет, а затем взорвётся, но п... текст свёрнут, показать
     
     
  • 10.135, Аноним84701 (ok), 16:19, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    рукалицо вебп Спасибо за столь подробное разъяснение -- вопросов больше нет К... текст свёрнут, показать
     
     
  • 11.138, BigBoobs (?), 18:29, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я так понимаю, что тебе ущербность не известно, что уже давно можно в реакторе с... текст свёрнут, показать
     
     
  • 12.141, Аноним84701 (ok), 18:55, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я так понимаю, что аргументы у знатока неплохо продемонстрировавшего свой уро... текст свёрнут, показать
     
  • 12.148, Аноним (148), 06:16, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вот это то как раз и странно Не характерно для ядерных реакций Более того - ес... большой текст свёрнут, показать
     
  • 10.143, Аноним (-), 19:50, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Поэтому и почти У меня чайник разве что яйца не клал пока я ионообмен не сдел... большой текст свёрнут, показать
     
  • 6.117, Совершенно другой аноним (?), 20:03, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    сорри, за оффтопик, но почти как в анекдоте про машинистку:

    А я могу набирать 2000 символов в минуту - такая фигня получается! (с)

     
  • 4.83, Аноним (83), 11:19, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > какой жаргон? коллизии есть и точка. а время скажем на квантовом компе
    > будет вменяемым

        Летят Шерлок Холмс и Доктор Ватсон на воздушном шаре, приземляются в неизвестном месте и видят человека.
        — Сэр, — говорит Холмс. — Не могли бы вы сказать нам, где мы находимся?
        — Могу, сэр, — отвечает тот. — Вы находитесь в корзине воздушного шара.
        Тут шар опять поднимается, Холмс подумал и говорит:
        — Перед нами типичный теоретик!
        — Поразительно, Холмс! — восклицает Ватсон. — Как вы догадались?
        — Элементарно, Ватсон, по его ответу. Ответ был абсолютно точен, но никому ненужен.

     

     ....большая нить свёрнута, показать (24)

  • 1.42, Аноним (42), 17:29, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    O'Connor ...Будущее уже близко...
     
  • 1.48, Аноним (-), 19:42, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Стилистически статья никакая.
    Научная составляющая слабая и, видимо, написана неспециалистом.

    Поэтому заминусованный товарищ прав.

     
     
  • 2.149, Аноним (-), 08:58, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так напиши лучше. Там есть чудная кнопка - "исправить". Жми!
     

  • 1.53, Аноним (53), 20:40, 12/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А с коллизиями что?
     
     
  • 2.58, JL2001 (ok), 22:10, 12/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А с коллизиями что?

    https://www.opennet.ru/openforum/vsluhforumID3/119467.html#38

     

  • 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 ... большой текст свёрнут, показать
     
     
  • 4.94, Аноним (93), 13:44, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ммм... лаконично. Достойный ответ всяким пихтонрасам.
     
     
  • 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 то особо не усиливает. Он лечит некоторые болезни, это правда. Но не усиливает.

     
     
  • 5.116, Ivan_83 (ok), 19:08, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    md5/sha1 тоже не надо было "усиливать", но время показало обратное.
     
     
  • 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) могут эту проверку выключать - что существенно улучшает жизнь дедупликов, с некоторым риском что их котики превратятся таки в ротики.

    Ибо криптохэши ни разу не гарантируют что блоки таки одинаковые. Они гарантируют невозможность намеренно подобрать такой блок.

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

     

  • 1.146, Аноним (146), 23:03, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ждем в IPSec и OpenVPN
     
     
  • 2.150, Аноним (-), 09:00, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Им это не поможет.
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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