Хэш функции Why?

[gl00mie]

Цитата:

Сообщение от axm2013

В 12 используются как минимум два алгоритма hash функций: sha1 \Classes\DimensionAttributeValueSetStorage\getHash
и md5 \Classes\RLedgerTurnoverParamHashKey\getHash
что лучше?

По идее лучше та хэш-функция, которая при прочих равных дает меньше коллизий, а это, как правило, коррелирует с мощностью множества значений функции. С этой точки зрения 128-битное значение MD5 смотрится несколько менее надежным, чем 160-битное значение SHA1. С другой стороны, MD5 до недавнего времени широко использовалась в качестве криптографической хеш-функции, так что для данных в Аксапте ее должно быть более чем достаточно.

Цитата:

Сообщение от axm2013

Ну и конечно SHА1 оно вроде как надежнее, но значит ли это что MD5 дает больше коллизий и реально не стоит даже думать о ней? Ведь люди зачем то заморачивались и явно не спроста.

Думаю, люди как раз не заморачивались, а взяли то, что на слуху, - SHA1. У MD5 есть одно огромное преимущество перед SHA1: длина ее значения совпадает с длиной GUID, поэтому его очень удобно хранить в поле типа GUID, наглядно видеть его значение и фильтроваться по нему, в т.ч. в прямых SQL-запросах, потому что GUID - это "родной" тип данных для SQL Server, в T-SQL называющийся uniqueidentifier. Никто ведь не кричит о том, что uniqueidentifier в T-SQL, используемый в тысячах промышленных баз данных, на самом деле не такой уж unique.
На мой взгляд, использование MD5 в Аксапте более чем оправдано: ожидать коллизий на таких смешных для криптографической хеш-функции объемах данных (тысячи наборов финансовых аналитик, миллионы комбинаций складских аналитик) не стоит, а удобство использования типа GUID для хранения значений MD5 подчас бесценно.

Цитата:

Сообщение от axm2013

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

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

Цитата:

Сообщение от gl00mie

Думаю, люди как раз не заморачивались, а взяли то, что на слуху, - SHA1.

В том то и дело что заморачивались. Создали свою отдельно, не используя стандартные возможности от MS.

Цитата:

Сообщение от gl00mie

. Никто ведь не кричит о том, что uniqueidentifier в T-SQL, используемый в тысячах промышленных баз данных, на самом деле не такой уж unique.

Так как вероятность совпадения ... В то же время с хэш функциями не все так же просто.

Цитата:

Сообщение от gl00mie

Это нарушение 1-й нормальной формы.
.

Второй тогда уж: но это не принципиально так как нормализация не является необходимым условием щастья.

Цитата:

Сообщение от gl00mie

Используйте числовые коды вместо строк с низкой энтропией, если хотите сэкономить и повысить производительность.

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

[gl00mie]

Цитата:

Сообщение от axm2013

Цитата:

Сообщение от gl00mie

Думаю, люди как раз не заморачивались, а взяли то, что на слуху, - SHA1.

В том то и дело что заморачивались. Создали свою отдельно, не используя стандартные возможности от MS.

Если вы думаете, что под AX 2012 кто-то озаботился разработкой нового алгоритма криптографической хеш-функции, то глубоко заблуждаетесь - погуглите, алгоритму SHA1 уже 20 лет Кроме того, к разработке алгоритма MD5 Microsoft также не имеет никакого отношения.

Цитата:

Сообщение от axm2013

Так как вероятность совпадения ... В то же время с хэш функциями не все так же просто.

"Паранойя - профессиональное заболевание специалистов по безопасности, но любители могут в этой области зайти гораздо дальше" (с) Банки десятилетиями доверяли электронной подписи, использующей в т.ч. алгоритм MD5, миллиардные транзакции, а тут - вы со своими текстовыми полями...

Цитата:

Сообщение от axm2013

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

Не бывает идеальных хеш-функций, другое дело, что под ваши конкретные условия может за глаза хватить того или иного алгоритма. Посмотрите в сторону TextBuffer::strHashKey(), если почему-то считаете, что она вам не подходит, - возьмите ту же MD5.

Цитата:

Сообщение от gl00mie

Если вы думаете, что под AX 2012 кто-то озаботился разработкой нового алгоритма криптографической хеш-функции, то глубоко заблуждаетесь - погуглите, алгоритму SHA1 уже 20 лет

Я как бэ в курсе. Но реализация идет Microsoft.Dynamics.AX.Fim.Dimensions.Hash::ComputeSHA1Hash
т.е. сделали свою вместо использования
System.Security.Cryptography.SHA1

Цитата:

Сообщение от gl00mie

а тут - вы со своими текстовыми полями...

Дело в том что

Цитата:

Сообщение от gl00mie

Не бывает идеальных хеш-функций,

В теории да (для произвольного множества), на практике при определенных допущениях (например при фиксации размеров словаря) бывают.

Цитата:

Сообщение от gl00mie

TextBuffer::strHashKey(), если почему-то считаете, что она вам не подходит,

она не подходит по причине что не видел внятного описания что там. Играться с черным ящиком отвечая за последствия его работы страшно.

Цитата:

Сообщение от gl00mie

- возьмите ту же MD5.

Это понятно, так в общем то и сделал +- но почему от нее отказались в одном из случаев в Dynamics Ax?
Может они что то знали?
Наверняка в MS тот кто делал SHA1 был в курсе про MD5 и прочее типа того что в системе реализовано. Но сделал так...

[gl00mie]

Цитата:

Сообщение от axm2013

Я как бэ в курсе. Но реализация идет Microsoft.Dynamics.AX.Fim.Dimensions.Hash::ComputeSHA1Hash т.е. сделали свою вместо использования System.Security.Cryptography.SHA1

Это просто обертка для удобства вызова:

[Logger]

Цитата:

Сообщение от axm2013

Это понятно, так в общем то и сделал +- но почему от нее отказались в одном из случаев в Dynamics Ax?
Может они что то знали?
Наверняка в MS тот кто делал SHA1 был в курсе про MD5 и прочее типа того что в системе реализовано. Но сделал так...

Может быть эти функции по разному едят процессорное время ?

Я например недавно узнал, что оказывается генерация гуида может занимать существенное время в винде (до микро-миллисекунд), поэтому если идет интенсивная вставка в БД с обязательной генерацией гуида, то это может здорово просадить производительность по сравнению с использованием обычных целочисленных счетчиков.

Цитата:

Сообщение от Logger

Может быть эти функции по разному едят процессорное время ?

Да видимо в этом дело имхо.
Тест показал что реализация с MD5 проигрывает SHA1 по скорости

[gl00mie]

Цитата:

Сообщение от axm2013

Да видимо в этом дело имхо. Тест показал что реализация с MD5 проигрывает SHA1 по скорости

В действительности все с точностью до наоборот В тестах Microsoft MD5 вычисляется примерно на 43% быстрее SHA1 на объемах данных от 1 Мб, а на меньших объемах данных - примерно одинаково быстро (но SHA1 отстает).

[Logger]

Цитата:

Сообщение от gl00mie

Посмотрите в сторону TextBuffer::strHashKey(), если почему-то считаете, что она вам не подходит, - возьмите ту же MD5.

Интересно, а что использует TextBuffer::strHashKey() ?
Легко может оказаться, что вариант еще какой-нить криптографической функции.

[gl00mie]

Цитата:

Сообщение от Logger

Интересно, а что использует TextBuffer::strHashKey() ? Легко может оказаться, что вариант еще какой-нить криптографической функции.

Я думаю, все проще, и там считается какой-нить CRC32.