Jump to content

    
Sign in to follow this  
Lixlex

Хеш-функция ГОСТ 34.11-2012 (Стрибог) оптимизация по утилизации

Recommended Posts

On 7/25/2019 at 12:44 PM, Doka said:

ок.   условия:

  • у меня есть набор данных каждый длиной 512бит
  • от каждого набора надо считать хеш (наборы независимы)
  • темп поступления набора - раз в такт
  • темп снятия результата - раз в такт

реализовывал подобную задачу когда делал eth коммутатор на fpga. Была возможность тестировать разные типы функции на провайдерах.

Хочу сказать, что "условий" для того чтобы дать совет недостаточно :)

Если хеш функция нужна при построении таблицы для хранения данных, то достаточно комбинации полином+память, если для крипто, то придется делать честно:)

Я исследовал вариант полином+память - практически идеально получилось на двойном преобразовании и минимумом ресурсов.

Edited by devilmike

Share this post


Link to post
Share on other sites
2 hours ago, devilmike said:

Хочу сказать, что "условий" для того чтобы дать совет недостаточно :)

Если хеш функция нужна при построении таблицы для хранения данных, то достаточно комбинации полином+память, если для крипто, то придется делать честно:)

мой сценарий использования вполне вписывается в парадигму "поточное шифрование" :dirol:

Share this post


Link to post
Share on other sites
19 hours ago, devilmike said:

реализовывал подобную задачу когда делал eth коммутатор на fpga. Была возможность тестировать разные типы функции на провайдерах.

Хочу сказать, что "условий" для того чтобы дать совет недостаточно :)

Если хеш функция нужна при построении таблицы для хранения данных, то достаточно комбинации полином+память, если для крипто, то придется делать честно:)

Я исследовал вариант полином+память - практически идеально получилось на двойном преобразовании и минимумом ресурсов.

оффтоп.

А можно, пожалуйста, чуть подробнее про полином+память и двойное преобразование? Можно прямо в ЛС. Ну, или хотя бы, ссылку, где можно просветиться на счет этих алгоритмов расчета хэша.

Share this post


Link to post
Share on other sites
On 8/2/2019 at 5:56 AM, nice_vladi said:

оффтоп.

А можно, пожалуйста, чуть подробнее про полином+память и двойное преобразование? Можно прямо в ЛС. Ну, или хотя бы, ссылку, где можно просветиться на счет этих алгоритмов расчета хэша.

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

 - в начале использовал для расчета хеш  полином - быстро понял, что это плохо. (это понятно?)

 - Результат стал лучше, когда после первого полинома использовал второй с другими коэффициентами.

 - третий и четвертый полином прогресса не дали.

 - Сгенерил ROM(1М20К) c псевдослучайными данными и подставил их в качестве начальной константы для полинома (это понятно?) - результат стал очень хорошим( ~98% от теоретического идеала)

В дальнейшем оказалось удобнее загонять в хеш данные по очереди. Например, если только на первом шаге обработки используешь МАК, то после этого шага их хешируешь и забываешь. Особенно это помогает при работе с IPv6.

PS: прочитал, ничего не понял = не умею я объяснять :(

Share this post


Link to post
Share on other sites

Более-менее понятно, но есть пара вопросов:

 

> - в начале использовал для расчета хеш  полином - быстро понял, что это плохо. (это понятно?)

Просто полином = большая вероятность коллизии, думаю, что понятно.

>  - Результат стал лучше, когда после первого полинома использовал второй с другими коэффициентами.

Как выбирались "другие" коэффициенты? Проверяли ли ортогональность этих полиномов?

> - Сгенерил ROM(1М20К) c псевдослучайными данными и подставил их в качестве начальной константы для полинома (это понятно?) - результат стал очень хорошим( ~98% от теоретического идеала)

Не понял. Зачем целый ROM с ПСП делать? Начальный блок имеет разрядность полинома, либо я что-то не так понял?

> В дальнейшем оказалось удобнее загонять в хеш данные по очереди. Например, если только на первом шаге обработки используешь МАК, то после этого шага их хешируешь и забываешь. Особенно это помогает при работе с IPv6.

"данные по очереди" - подразумевается, что сначала считается хэш MAC адреса, затем все сбрасывается и считается хэш других данных (например IP)?

Share this post


Link to post
Share on other sites
On 8/6/2019 at 5:21 AM, nice_vladi said:

Более-менее понятно, но есть пара вопросов:

> - Сгенерил ROM(1М20К) c псевдослучайными данными и подставил их в качестве начальной константы для полинома (это понятно?) - результат стал очень хорошим( ~98% от теоретического идеала)

Не понял. Зачем целый ROM с ПСП делать? Начальный блок имеет разрядность полинома, либо я что-то не так понял?

Была нужна скорость вычисления, ну и итоговый результат очень понравился. А что такое M20K - капля в море :)

On 8/6/2019 at 5:21 AM, nice_vladi said:

> В дальнейшем оказалось удобнее загонять в хеш данные по очереди. Например, если только на первом шаге обработки используешь МАК, то после этого шага их хешируешь и забываешь. Особенно это помогает при работе с IPv6.

"данные по очереди" - подразумевается, что сначала считается хэш MAC адреса, затем все сбрасывается и считается хэш других данных (например IP)? 

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

Edited by devilmike

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this