AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.11.2015, 15:59   #1  
axm2013
Гость
 
n/a
Хэш функции Why?
Вопрос all?
В 12 используются как минимум два алгоритма hash функций:
sha1
класс DimensionAttributeValueSetStorage
метод getHash

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

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

Последний раз редактировалось axm2013; 24.11.2015 в 16:02.
Старый 24.11.2015, 16:02   #2  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Может, потому что второе делала локализация, а первое - центр?
__________________
Ivanhoe as is..
Старый 24.11.2015, 16:06   #3  
axm2013
Гость
 
n/a
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Может, потому что второе делала локализация, а первое - центр?
И кого правильнее клеймить позором а кому честь и слава в веках? Индусов или локализаторов?

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

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

Последний раз редактировалось axm2013; 24.11.2015 в 17:15.
За это сообщение автора поблагодарили: mazzy (2).
Старый 25.11.2015, 09:47   #4  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от 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-й нормальной формы. Используйте числовые коды вместо строк с низкой энтропией, если хотите сэкономить и повысить производительность.
За это сообщение автора поблагодарили: mazzy (2), macklakov (1), ZVV (1), Logger (3), AP-1055D (1).
Старый 25.11.2015, 10:41   #5  
axm2013
Гость
 
n/a
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Думаю, люди как раз не заморачивались, а взяли то, что на слуху, - SHA1.
В том то и дело что заморачивались. Создали свою отдельно, не используя стандартные возможности от MS.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
. Никто ведь не кричит о том, что uniqueidentifier в T-SQL, используемый в тысячах промышленных баз данных, на самом деле не такой уж unique.
Так как вероятность совпадения ... В то же время с хэш функциями не все так же просто.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Это нарушение 1-й нормальной формы.
.
Второй тогда уж: но это не принципиально так как нормализация не является необходимым условием щастья.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Используйте числовые коды вместо строк с низкой энтропией, если хотите сэкономить и повысить производительность.
Нет мне нужно именно эквивалент хэш функции так как данные возможно будут перезаливать. Идеальная хэш функция была бы в самый раз.
Старый 25.11.2015, 12:16   #6  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от axm2013 Посмотреть сообщение
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Думаю, люди как раз не заморачивались, а взяли то, что на слуху, - SHA1.
В том то и дело что заморачивались. Создали свою отдельно, не используя стандартные возможности от MS.
Если вы думаете, что под AX 2012 кто-то озаботился разработкой нового алгоритма криптографической хеш-функции, то глубоко заблуждаетесь - погуглите, алгоритму SHA1 уже 20 лет Кроме того, к разработке алгоритма MD5 Microsoft также не имеет никакого отношения.
Цитата:
Сообщение от axm2013 Посмотреть сообщение
Так как вероятность совпадения ... В то же время с хэш функциями не все так же просто.
"Паранойя - профессиональное заболевание специалистов по безопасности, но любители могут в этой области зайти гораздо дальше" (с) Банки десятилетиями доверяли электронной подписи, использующей в т.ч. алгоритм MD5, миллиардные транзакции, а тут - вы со своими текстовыми полями...
Цитата:
Сообщение от axm2013 Посмотреть сообщение
Нет мне нужно именно эквивалент хэш функции так как данные возможно будут перезаливать. Идеальная хэш функция была бы в самый раз.
Не бывает идеальных хеш-функций, другое дело, что под ваши конкретные условия может за глаза хватить того или иного алгоритма. Посмотрите в сторону TextBuffer::strHashKey(), если почему-то считаете, что она вам не подходит, - возьмите ту же MD5.
Старый 25.11.2015, 12:35   #7  
axm2013
Гость
 
n/a
Цитата:
Сообщение от 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 и прочее типа того что в системе реализовано. Но сделал так...

Последний раз редактировалось axm2013; 25.11.2015 в 12:41.
Старый 25.11.2015, 13:09   #8  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от axm2013 Посмотреть сообщение
Я как бэ в курсе. Но реализация идет Microsoft.Dynamics.AX.Fim.Dimensions.Hash::ComputeSHA1Hash т.е. сделали свою вместо использования System.Security.Cryptography.SHA1
Это просто обертка для удобства вызова:
За это сообщение автора поблагодарили: Kabardian (2).
Старый 25.11.2015, 13:36   #9  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Посмотрите в сторону TextBuffer::strHashKey(), если почему-то считаете, что она вам не подходит, - возьмите ту же MD5.
Интересно, а что использует TextBuffer::strHashKey() ?
Легко может оказаться, что вариант еще какой-нить криптографической функции.
Старый 25.11.2015, 13:39   #10  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от axm2013 Посмотреть сообщение
Это понятно, так в общем то и сделал +- но почему от нее отказались в одном из случаев в Dynamics Ax?
Может они что то знали?
Наверняка в MS тот кто делал SHA1 был в курсе про MD5 и прочее типа того что в системе реализовано. Но сделал так...
Может быть эти функции по разному едят процессорное время ?

Я например недавно узнал, что оказывается генерация гуида может занимать существенное время в винде (до микро-миллисекунд), поэтому если идет интенсивная вставка в БД с обязательной генерацией гуида, то это может здорово просадить производительность по сравнению с использованием обычных целочисленных счетчиков.
За это сообщение автора поблагодарили:  (1).
Старый 25.11.2015, 15:18   #11  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Logger Посмотреть сообщение
Интересно, а что использует TextBuffer::strHashKey() ? Легко может оказаться, что вариант еще какой-нить криптографической функции.
Я думаю, все проще, и там считается какой-нить CRC32.
Старый 26.11.2015, 11:51   #12  
axm2013
Гость
 
n/a
Цитата:
Сообщение от Logger Посмотреть сообщение
Может быть эти функции по разному едят процессорное время ?
Да видимо в этом дело имхо.
Тест показал что реализация с MD5 проигрывает SHA1 по скорости
Старый 27.02.2016, 22:28   #13  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от axm2013 Посмотреть сообщение
Да видимо в этом дело имхо. Тест показал что реализация с MD5 проигрывает SHA1 по скорости
В действительности все с точностью до наоборот В тестах Microsoft MD5 вычисляется примерно на 43% быстрее SHA1 на объемах данных от 1 Мб, а на меньших объемах данных - примерно одинаково быстро (но SHA1 отстает).
За это сообщение автора поблагодарили: Logger (3).
Старый 29.02.2016, 09:38   #14  
axm2013
Гость
 
n/a
Цитата:
Сообщение от gl00mie Посмотреть сообщение
В действительности все с точностью до наоборот...
Я смеюсь вам в лицо или что там у вас
добрым смехом веселой гиены

(стихи по мотивам)

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

SHA1 35
MD5 62

MD5 62
SHA1 39


Меня мало волнуют тесты от индусов MS, когда могу проверить и самостоятельно.
Старый 29.02.2016, 09:43   #15  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Ну а как вы тестировали ?
Кстати, тестировать имеет смысл на небольшой длине ключа (порядка килобайта) - так как именно на такой длине вычисляется хеш для inventDim
Старый 29.02.2016, 09:53   #16  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от axm2013 Посмотреть сообщение
Просто есть некие текстовые поля набор которых на вид хорошо бы представить одним полем и по идее обычную строчку с низкой энтропией можно упаковать без особых потерь.
Тогда лишитесь возможности поиска по данным полям.

С Уважением,
Георгий
Старый 29.02.2016, 10:03   #17  
axm2013
Гость
 
n/a
Цитата:
Сообщение от Logger Посмотреть сообщение
Ну а как вы тестировали ?
Кстати, тестировать имеет смысл на небольшой длине ключа (порядка килобайта) - так как именно на такой длине вычисляется хеш для inventDim
Перебирал 10 000 строк с выработкой хэша вызовом указанных выше функций.

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

Цитата:
Сообщение от George Nordic
Тогда лишитесь возможности поиска по данным полям.
Почему?

1. взял значение полей
2. сгенерил хэш
3 осуществил поиск
4 вуаля
Старый 29.02.2016, 10:09   #18  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от axm2013 Посмотреть сообщение
Перебирал 10 000 строк с выработкой хэша вызовом указанных выше функций.
Интересно.
А код как работал ?
p-code ?
CIL ?

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

см.
http://blogs.msdn.com/b/mfp/archive/...the-metal.aspx
Старый 29.02.2016, 10:12   #19  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от axm2013 Посмотреть сообщение
Внезапно тесты:
SHA1 35
MD5 62
MD5 62
SHA1 39
- axm2013, тесты!
- 45!
- что 45?
- а что тесты?
(по мотивам известного анекдота).
Без описания методики тестирования это - внезапно мусор в теме, а не внезапно тесты.
Старый 29.02.2016, 10:19   #20  
axm2013
Гость
 
n/a
Цитата:
Сообщение от gl00mie Посмотреть сообщение
...
Без описания методики тестирования это - внезапно мусор в теме, а не внезапно тесты.
Методика см выше. Функции так же можно заметить наверху.

Мусор - это приводить непонятные тесты непонятных реализаций собратьев по разуму из солнечной Индии.
За это сообщение автора поблагодарили: Logger (0).
Теги
hash, md5, sha1, хэш

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Неправильный тип аргумента функции преобразования S.Kuskov DAX: Программирование 3 07.02.2020 10:49
AX 2012 R2: ошибка в функции "Операции для аналитик" Kabardian DAX: Функционал 2 09.04.2014 23:56
Групповые функции в дизайнере Query Morpheus DAX: Программирование 3 28.01.2011 13:13
Advanced query range value expressions: поле таблицы - имя вcтроенной функции year(). ATimTim DAX: Программирование 12 27.03.2009 18:16
имя функции программно Alkozeltzer DAX: Программирование 2 25.07.2005 19:03
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 11:11.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.