Вибір правильного алгоритму у функції HashBytes

Для порівняння нам потрібно створити хеш-значення даних nvarchar. У T-SQL доступні кілька алгоритмів хешування, але який із них найкраще вибрати в цьому сценарії?

Ми хочемо забезпечити мінімальний ризик отримання повторюваного хеш-значення для двох різних значень nvarchar. На основі мого дослідження в Інтернеті MD5 здається найкращим. Це так? MSDN повідомляє нам (посилання нижче) про доступні алгоритми, але немає опису, на якому для яких умов?

HASHBYTES (Transact-SQL)

Нам потрібно з'єднати дві таблиці на двох колонках nvarchar (max). Як ви можете уявити, запит потребує часу для виконання. Ми думали, що буде краще зберігати хеш-значення кожного даних nvarchar (max) і робити з'єднання на хеш-значеннях, а не на nvarchar (max) значеннях, які є краплями. Питання полягає в тому, який алгоритм хешу надає унікальність, так що ми не ризикуємо мати одне хеш-значення більше одного nvarchar (max).

HASHBYTESФункція приймає тільки до 8000 байт в якості вхідних даних. Оскільки ваші входи потенційно більше, ніж це, дублікати в діапазоні поля, що хеширується , спричинить зіткнення, незалежно від обраного алгоритму. Уважно розгляньте коло даних, які ви плануєте хеш - використання перших 4000 символів - очевидний вибір, але може бути не найкращим вибором для ваших даних.

У будь-якому випадку, через те, що таке хеш-функція, навіть якщо входи складають 8000 байт або менше, єдиний спосіб забезпечити 100% правильність результатів - порівняти базові значення в якийсь момент (читайте: спочатку не обов’язково ). Період.

Бізнес буде диктувати, чи потрібно 100% точність. Це скаже вам , що або (а) порівняння базових значень потрібно , або (б) слід розглядати НЕ порівнюючи базові значення - скільки точність повинна бути торгуються від для підвищення продуктивності.

Хоча хеш-зіткнення можливі в унікальному наборі вводу, вони нескінченно рідкісні, незалежно від обраного алгоритму. Вся ідея використання хеш-значення в цьому сценарії полягає в тому, щоб ефективно звузити результати об'єднання до більш керованого набору, а не обов’язково одразу доходити до остаточного набору результатів. Знову ж таки, для 100% точності це не може бути завершальним кроком у процесі. Цей сценарій не використовує хешування для криптографії, тому алгоритм, такий як MD5, буде добре працювати.

Мені було б вкрай важко виправдати перехід до алгоритму SHA-x для цілей "точності", тому що якщо бізнес збирається врізатися з приводу мінімальних можливостей зіткнення MD5, швидше за все, вони також зроблять це алгоритми SHA-x також не є ідеальними. Вони або повинні змиритися з незначною неточністю, або вимагають, щоб запит був на 100% точним і жив з відповідними технічними наслідками. Я гадаю, якщо генеральний директор спить краще вночі, знаючи, що ви використовували SHA-x замість MD5, ну, добре; з технічної точки зору це все ще не означає багато.

Якщо говорити про ефективність, якщо таблиці здебільшого читаються, а результат з'єднання потрібен часто, розгляньте можливість застосування індексованого виду, щоб усунути необхідність обчислювати весь приєднання щоразу, коли це вимагається. Звичайно, ви торгуєте цим сховищем, але, можливо, варто його покращити, особливо якщо потрібна 100% точність.

Для подальшого читання щодо індексації значень довгих рядків я опублікував статтю , в якій описує приклад того, як це зробити для однієї таблиці, і подає речі, які слід враховувати при спробі повного сценарію в цьому питанні.

MD5 має бути добре, а вихід може зберігатися у двійковому (16). Ймовірність зіткнення (див. Парадокс від дня народження ) все ще дуже низька, навіть при великому фізичному розмірі вибірки. Вихід SHA-1 займає 20 байт, а вихід SHA-256 займає 32 байти. Якщо у вас немає такої великої кількості записів, що ймовірність зіткнення вашого дня народження стане значною (фізично неможливою або принаймні непрактичною з сучасними апаратними технологіями), ймовірно, це буде добре.

Я б пішов із SHA-1, це кращий з доступних алгоритмів і має найменшу тривалість зіткнення з усіх них (2 ^ 51 порівняно з MD5, що становить 2 ^ 20,96). Також було доведено, що MD5 вразливий до зіткнень у певних сценаріях.

Джерела:

http://en.wikipedia.org/wiki/SHA-1 http://en.wikipedia.org/wiki/Comppare_of_cryptographic_hash_functions#Cryptanalysis http://en.wikipedia.org/wiki/MD5

Я цього не бачив у відповідях, але за MSDN :

Починаючи з SQL Server 2016 (13.x), усі алгоритми, окрім SHA2_256 та SHA2_512, застаріли. Старі алгоритми (не рекомендується) продовжуватимуть працювати, але вони призведуть до погіршення події.

Я задав подібне запитання, тож вирішувати, чи хочете ви використовувати застарілу функцію, таку як MD5 (якщо ви на 2016+). Ви можете провести тестування, щоб побачити, наскільки різниця між зберіганням та продуктивністю між MD5 та SHA2.