Auswahl des richtigen Algorithmus in der HashBytes-Funktion

Wir müssen zu Vergleichszwecken einen Hash-Wert für nvarchar-Daten erstellen. In T-SQL stehen mehrere Hash-Algorithmen zur Verfügung. Welche sind in diesem Szenario die besten?

Wir möchten sicherstellen, dass das Risiko von doppelten Hashwerten für zwei verschiedene nvarchar-Werte minimal ist. Aufgrund meiner Recherchen im Internet scheint MD5 das beste zu sein. Ist das richtig? MSDN sagt uns (Link unten) über die verfügbaren Algorithmen, aber keine Beschreibung, auf welcher für welche Bedingungen?

HASHBYTES (Transact-SQL)

Wir müssen zwei Tabellen in zwei nvarchar (max) -Spalten verbinden. Wie Sie sich vorstellen können, dauert die Ausführung der Abfrage einige Zeit. Wir dachten, es wäre besser, den Hash-Wert aller nvarchar (max) -Daten beizubehalten und die Hash-Werte anstelle der nvarchar (max) -Werte, die Blobs sind, zu verknüpfen. Die Frage ist, welcher Hash-Algorithmus die Eindeutigkeit bietet, damit wir nicht das Risiko eingehen, dass ein Hash-Wert für mehr als ein nvarchar (max) vorliegt.

Die HASHBYTESFunktion nimmt nur bis zu 8000 Bytes als Eingabe auf. Da Ihre Eingaben sind möglicherweise größer als das, Duplikate im Bereich des Feldes , das gehasht wird werden Kollisionen verursachen, unabhängig von dem gewählten Algorithmus. Überlegen Sie sorgfältig, welche Datenmenge Sie für den Hash planen - die Verwendung der ersten 4000 Zeichen ist die naheliegende Wahl, ist jedoch möglicherweise nicht die beste Wahl für Ihre Daten.

In jedem Fall besteht die einzige Möglichkeit, um eine 100% ige Richtigkeit der Ergebnisse zu gewährleisten , aufgrund der Hash-Funktion (nicht unbedingt zuerst ). Zeitraum.

Das Unternehmen wird vorschreiben, ob eine 100% ige Genauigkeit erforderlich ist oder nicht. Dies zeigt Ihnen, dass entweder (a) ein Vergleich der Basiswerte erforderlich ist oder (b) Sie in Betracht ziehen sollten , die Basiswerte nicht zu vergleichen - wie viel Genauigkeit für die Leistung abgewogen werden sollte.

Hash-Kollisionen sind in einem eindeutigen Eingabesatz zwar möglich, jedoch unabhängig vom gewählten Algorithmus unendlich selten. Die ganze Idee, in diesem Szenario einen Hash-Wert zu verwenden, besteht darin, die Verknüpfungsergebnisse effizient auf eine handlichere Menge einzugrenzen und nicht unbedingt sofort zur endgültigen Ergebnismenge zu gelangen. Auch dies kann für eine 100% ige Genauigkeit nicht der letzte Schritt in diesem Prozess sein. In diesem Szenario wird kein Hashing für die Kryptografie verwendet, sodass ein Algorithmus wie MD5 problemlos funktioniert.

Es wäre äußerst schwierig für mich, die Umstellung auf einen SHA-x-Algorithmus für "Genauigkeitszwecke" zu rechtfertigen, denn wenn das Unternehmen über die winzigen Kollisionsmöglichkeiten von MD5 ausflippen wird, ist es wahrscheinlich, dass sie dies auch ausflippen werden Auch die SHA-x-Algorithmen sind nicht perfekt. Entweder müssen sie sich mit der leichten Ungenauigkeit abfinden oder die Abfrage muss 100% genau sein und die damit verbundenen technischen Auswirkungen berücksichtigen. Ich nehme an, wenn der CEO nachts besser schläft, weil er weiß, dass Sie SHA-x anstelle von MD5 verwendet haben. es hat in diesem Fall aus technischer Sicht noch nicht viel zu bedeuten.

Apropos Leistung: Wenn die Tabellen meistens gelesen werden und das Verknüpfungsergebnis häufig benötigt wird, sollten Sie eine indizierte Ansicht implementieren, um zu vermeiden, dass die gesamte Verknüpfung bei jeder Anforderung berechnet werden muss. Natürlich müssen Sie dafür den Speicher austauschen, aber es lohnt sich möglicherweise für die Leistungsverbesserung, insbesondere wenn eine 100% ige Genauigkeit erforderlich ist.

Zum weiteren Lesen der Indizierung langer Zeichenfolgewerte habe ich einen Artikel veröffentlicht , in dem ein Beispiel für die Vorgehensweise für eine einzelne Tabelle aufgeführt ist. Außerdem werden einige Aspekte erläutert, die beim Versuch, das vollständige Szenario in dieser Frage auszuführen, zu berücksichtigen sind.

MD5 sollte in Ordnung sein und die Ausgabe kann in einer Binärdatei (16) gespeichert werden. Die Wahrscheinlichkeit einer Kollision (siehe Geburtstagsparadoxon ) ist auch bei einer großen physischen Stichprobe noch sehr gering. Die Ausgabe von SHA-1 dauert 20 Bytes und die Ausgabe von SHA-256 dauert 32 Bytes. Sofern Sie nicht über eine so große Anzahl von Datensätzen verfügen, dass Ihre Wahrscheinlichkeit einer Geburtstagskollision erheblich wird (physikalisch unmöglich oder zumindest mit den aktuellen Hardwaretechnologien nicht praktikabel), ist dies wahrscheinlich in Ordnung.

Ich würde mit SHA-1 gehen, es ist der bessere der verfügbaren Algorithmen und hat die geringste Kollisionserwartung von allen (2 ^ 51 im Vergleich zu MD5, das 2 ^ 20,96 ist). MD5 ist in bestimmten Szenarien auch nachweislich anfällig für Kollisionen.

Quellen:

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

Ich habe dies nicht in den Antworten erwähnt gesehen, aber per MSDN :

Ab SQL Server 2016 (13.x) sind alle Algorithmen außer SHA2_256 und SHA2_512 veraltet. Ältere Algorithmen (nicht empfohlen) funktionieren weiterhin, lösen jedoch ein Verfallsereignis aus.

Ich habe eine ähnliche Frage gestellt, daher liegt es an Ihnen, ob Sie eine veraltete Funktion wie MD5 verwenden möchten (wenn Sie 2016+ sind). Sie können testen, wie groß der Unterschied zwischen Speicher und Leistung zwischen MD5 und SHA2 ist.