devilmike 0 1 августа, 2019 Опубликовано 1 августа, 2019 (изменено) · Жалоба On 7/25/2019 at 12:44 PM, Doka said: ок. условия: у меня есть набор данных каждый длиной 512бит от каждого набора надо считать хеш (наборы независимы) темп поступления набора - раз в такт темп снятия результата - раз в такт реализовывал подобную задачу когда делал eth коммутатор на fpga. Была возможность тестировать разные типы функции на провайдерах. Хочу сказать, что "условий" для того чтобы дать совет недостаточно :) Если хеш функция нужна при построении таблицы для хранения данных, то достаточно комбинации полином+память, если для крипто, то придется делать честно:) Я исследовал вариант полином+память - практически идеально получилось на двойном преобразовании и минимумом ресурсов. Изменено 1 августа, 2019 пользователем devilmike Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Doka 1 1 августа, 2019 Опубликовано 1 августа, 2019 · Жалоба 2 hours ago, devilmike said: Хочу сказать, что "условий" для того чтобы дать совет недостаточно :) Если хеш функция нужна при построении таблицы для хранения данных, то достаточно комбинации полином+память, если для крипто, то придется делать честно:) мой сценарий использования вполне вписывается в парадигму "поточное шифрование" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nice_vladi 1 2 августа, 2019 Опубликовано 2 августа, 2019 · Жалоба 19 hours ago, devilmike said: реализовывал подобную задачу когда делал eth коммутатор на fpga. Была возможность тестировать разные типы функции на провайдерах. Хочу сказать, что "условий" для того чтобы дать совет недостаточно :) Если хеш функция нужна при построении таблицы для хранения данных, то достаточно комбинации полином+память, если для крипто, то придется делать честно:) Я исследовал вариант полином+память - практически идеально получилось на двойном преобразовании и минимумом ресурсов. оффтоп. А можно, пожалуйста, чуть подробнее про полином+память и двойное преобразование? Можно прямо в ЛС. Ну, или хотя бы, ссылку, где можно просветиться на счет этих алгоритмов расчета хэша. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
devilmike 0 5 августа, 2019 Опубликовано 5 августа, 2019 · Жалоба On 8/2/2019 at 5:56 AM, nice_vladi said: оффтоп. А можно, пожалуйста, чуть подробнее про полином+память и двойное преобразование? Можно прямо в ЛС. Ну, или хотя бы, ссылку, где можно просветиться на счет этих алгоритмов расчета хэша. это просто мои исследования хеш-функции - при минимальных затратах получился приемлемый результат. - в начале использовал для расчета хеш полином - быстро понял, что это плохо. (это понятно?) - Результат стал лучше, когда после первого полинома использовал второй с другими коэффициентами. - третий и четвертый полином прогресса не дали. - Сгенерил ROM(1М20К) c псевдослучайными данными и подставил их в качестве начальной константы для полинома (это понятно?) - результат стал очень хорошим( ~98% от теоретического идеала) В дальнейшем оказалось удобнее загонять в хеш данные по очереди. Например, если только на первом шаге обработки используешь МАК, то после этого шага их хешируешь и забываешь. Особенно это помогает при работе с IPv6. PS: прочитал, ничего не понял = не умею я объяснять :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nice_vladi 1 6 августа, 2019 Опубликовано 6 августа, 2019 · Жалоба Более-менее понятно, но есть пара вопросов: > - в начале использовал для расчета хеш полином - быстро понял, что это плохо. (это понятно?) Просто полином = большая вероятность коллизии, думаю, что понятно. > - Результат стал лучше, когда после первого полинома использовал второй с другими коэффициентами. Как выбирались "другие" коэффициенты? Проверяли ли ортогональность этих полиномов? > - Сгенерил ROM(1М20К) c псевдослучайными данными и подставил их в качестве начальной константы для полинома (это понятно?) - результат стал очень хорошим( ~98% от теоретического идеала) Не понял. Зачем целый ROM с ПСП делать? Начальный блок имеет разрядность полинома, либо я что-то не так понял? > В дальнейшем оказалось удобнее загонять в хеш данные по очереди. Например, если только на первом шаге обработки используешь МАК, то после этого шага их хешируешь и забываешь. Особенно это помогает при работе с IPv6. "данные по очереди" - подразумевается, что сначала считается хэш MAC адреса, затем все сбрасывается и считается хэш других данных (например IP)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
devilmike 0 28 августа, 2019 Опубликовано 28 августа, 2019 (изменено) · Жалоба 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)? нет, я про другое... если в обработке используем только проверку на совпадение(например мак адрес), то не надо хранить его полное значение в хеш таблице - достаточно построить для него второй, короткий хеш и использовать его вместо реального мак адреса. Изменено 28 августа, 2019 пользователем devilmike Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
