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

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

и md5
класс RLedgerTurnoverParamHashKey
метод getHash
и традиционная паранойя не дает покоя с традиционными вопросами почему? и что лучше?

ЗЫ Хэш функции ессно вещь замечательная и соблазнительная и хочется научится их готовить правильно

[Ivanhoe]

Может, потому что второе делала локализация, а первое - центр?

Quote:

Originally Posted by Ivanhoe

Может, потому что второе делала локализация, а первое - центр?

И кого правильнее клеймить позором а кому честь и слава в веках? Индусов или локализаторов?

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

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

[gl00mie]

Quote:

Originally Posted by axm2013

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

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

Quote:

Originally Posted by axm2013

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

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

Quote:

Originally Posted by axm2013

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

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

Quote:

Originally Posted by gl00mie

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

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

Quote:

Originally Posted by gl00mie

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

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

Quote:

Originally Posted by gl00mie

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

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

Quote:

Originally Posted by gl00mie

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

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

[gl00mie]

Quote:

Originally Posted by axm2013

Quote:

Originally Posted by gl00mie

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

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

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

Quote:

Originally Posted by axm2013

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

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

Quote:

Originally Posted by axm2013

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

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

Quote:

Originally Posted by gl00mie

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

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

Quote:

Originally Posted by gl00mie

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

Дело в том что

Quote:

Originally Posted by gl00mie

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

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

Quote:

Originally Posted by gl00mie

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

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

Quote:

Originally Posted by gl00mie

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

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

[gl00mie]

Quote:

Originally Posted by axm2013

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

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

[Logger]

Quote:

Originally Posted by gl00mie

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

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

[Logger]

Quote:

Originally Posted by axm2013

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

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

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

[gl00mie]

Quote:

Originally Posted by Logger

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

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

Quote:

Originally Posted by Logger

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

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

[gl00mie]

Quote:

Originally Posted by axm2013

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

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

Quote:

Originally Posted by gl00mie

В действительности все с точностью до наоборот...

Я смеюсь вам в лицо или что там у вас
добрым смехом веселой гиены
(стихи по мотивам)

Внезапно тесты:

SHA1 35
MD5 62

MD5 62
SHA1 39

Меня мало волнуют тесты от индусов MS, когда могу проверить и самостоятельно.

[Logger]

Ну а как вы тестировали ?
Кстати, тестировать имеет смысл на небольшой длине ключа (порядка килобайта) - так как именно на такой длине вычисляется хеш для inventDim

[George Nordic]

Quote:

Originally Posted by axm2013

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

Тогда лишитесь возможности поиска по данным полям.

С Уважением,
Георгий

Quote:

Originally Posted by Logger

Ну а как вы тестировали ?
Кстати, тестировать имеет смысл на небольшой длине ключа (порядка килобайта) - так как именно на такой длине вычисляется хеш для inventDim

Перебирал 10 000 строк с выработкой хэша вызовом указанных выше функций.

А при чем тут InventDim? У меня другая задача в любом случае строки не мега длины де факто.

Quote:

Originally Posted by George Nordic

Тогда лишитесь возможности поиска по данным полям.

Почему?

1. взял значение полей
2. сгенерил хэш
3 осуществил поиск
4 вуаля

[Logger]

Quote:

Originally Posted by axm2013

Перебирал 10 000 строк с выработкой хэша вызовом указанных выше функций.

Интересно.
А код как работал ?
p-code ?
CIL ?

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

см.
http://blogs.msdn.com/b/mfp/archive/...the-metal.aspx

[gl00mie]

Quote:

Originally Posted by axm2013

Внезапно тесты:
SHA1 35
MD5 62
MD5 62
SHA1 39

- axm2013, тесты!
- 45!
- что 45?
- а что тесты?
(по мотивам известного анекдота).
Без описания методики тестирования это - внезапно мусор в теме, а не внезапно тесты.

Quote:

Originally Posted by gl00mie

...
Без описания методики тестирования это - внезапно мусор в теме, а не внезапно тесты.

Методика см выше. Функции так же можно заметить наверху.

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