it-swarm.com.de

Auswahl des richtigen Algorithmus in der HashBytes-Funktion

Zu Vergleichszwecken müssen wir einen Hashwert für nvarchar-Daten erstellen. In T-SQL stehen mehrere Hash-Algorithmen zur Verfügung. Welcher ist in diesem Szenario der beste?

Wir möchten sicherstellen, dass das Risiko eines doppelten Hashwerts für zwei verschiedene nvarchar-Werte minimal ist. Basierend auf meinen Recherchen im Internet scheint MD5 das beste zu sein. Ist das richtig? MSDN informiert uns (Link unten) über die verfügbaren Algorithmen, aber keine Beschreibung, für welche 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 zu verknüpfen, als die nvarchar (max) -Werte, die Blobs sind. Die Frage ist, welcher Hash-Algorithmus die Eindeutigkeit bietet, damit wir nicht das Risiko eingehen, einen Hash-Wert für mehr als einen nvarchar (max) zu haben.

22
Sky

Die Funktion HASHBYTES benötigt nur bis zu 8000 Bytes als Eingabe. Da Ihre Eingaben möglicherweise größer sind, verursachen Duplikate im Bereich des Feldes, das gehasht wirdwirdKollisionen verursachen, unabhängig vom gewählten Algorithmus. Überlegen Sie genau, welchen Datenbereich Sie hashen möchten. Die ersten 4000 Zeichen sind die Optionoffensichtlich, möglicherweise jedoch nicht die OptionbesteWahl für Ihre Daten.

In jedem Fall ist aufgrund der Hash-Funktion, selbst wenn die Eingaben 8000 Byte oder weniger betragen, die Methodeonly, um eine 100% ige Richtigkeit der Ergebnisse sicherzustellen, zu vergleichen die Basiswerte irgendwann (lesen: nicht unbedingtfirst). Zeitraum.

Das Unternehmen bestimmt, ob eine 100% ige Genauigkeit erforderlich ist oder nicht. Dies zeigt Ihnen, dass entweder (a) ein Vergleich der Basiswerte erforderlich ist oder (b) Sieberücksichtigen sollten nicht Vergleich der Basiswerte - wie viel Genauigkeit sollte gegen Leistung abgewogen werden.

Während Hash-Kollisionen in einem eindeutigen Eingabesatz möglich sind, sind sie unabhängig vom gewählten Algorithmus unendlich selten. Die gesamte Idee der Verwendung eines Hash-Werts in diesem Szenario besteht darin, die Verknüpfungsergebnisse effizient auf eine überschaubare Menge einzugrenzen und nicht unbedingt sofort zur endgültigen Menge von Ergebnissen zu gelangen. Für eine 100% ige Genauigkeit kann diesnichtder letzte Schritt in diesem Prozess sein. In diesem Szenario wird kein Hashing zum Zwecke der Kryptografie verwendet, sodass ein Algorithmus wie MD5 einwandfrei funktioniert.

Es wäre äußerst schwierig für mich, die Umstellung auf einen SHA-x-Algorithmus aus Gründen der "Genauigkeit" zu rechtfertigen, denn wenn das Unternehmen über die winzigen Kollisionsmöglichkeiten von MD5 ausflippen wird, werden sie dies wahrscheinlich auch ausflippen Auch die SHA-x-Algorithmen sind nicht perfekt. Sie müssen sich entweder mit der leichten Ungenauigkeit auseinandersetzen oder verlangen, dass die Abfrage 100% genau ist und die damit verbundenen technischen Auswirkungen erfüllt. Ich nehme an, wenn der CEO nachts besser schläft und weiß, dass Sie SHA-x anstelle von MD5 verwendet haben, ist das in Ordnung. Aus technischer Sicht bedeutet dies in diesem Fall immer noch nicht viel.

Apropos Leistung: Wenn die Tabellen meistens gelesen werden und das Join-Ergebnis häufig benötigt wird, sollten Sie eine indizierte Ansicht implementieren, um zu vermeiden, dass der gesamte Join bei jeder Anforderung berechnet werden muss. Natürlich tauschen Sie den Speicher dafür aus, aber es kann sich für die Leistungsverbesserung durchaus lohnen, insbesondere wenn eine 100% ige Genauigkeit erforderlich ist.

Weitere Informationen zum Indizieren langer Zeichenfolgenwerte finden Sie in I veröffentlicht in einem Artikel , in dem ein Beispiel für die Vorgehensweise für eine einzelne Tabelle erläutert wird und in dem das in dieser Frage beschriebene Szenario zu berücksichtigen ist.

19
Jon Seigel

MD5 sollte in Ordnung sein und die Ausgabe kann in einer Binärdatei (16) gespeichert werden. Die Wahrscheinlichkeit einer Kollision (siehe Geburtstagsparadoxon ) ist selbst bei einer großen physischen Stichprobengröße immer noch sehr gering. Die Ausgabe von SHA-1 dauert 20 Bytes und die Ausgabe von SHA-256 dauert 32 Bytes. Wenn Sie nicht über eine so große Anzahl von Datensätzen verfügen, dass Ihre Wahrscheinlichkeit einer Geburtstagskollision erheblich wird (physikalisch unmöglich oder mit aktuellen Hardwaretechnologien zumindest unpraktisch), 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). Es wurde auch nachgewiesen, dass MD5 in bestimmten Szenarien anfällig für Kollisionen ist.

Quellen:

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

4
Mr.Brownstone

Ich habe dies in den Antworten nicht 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. Es liegt also an Ihnen, ob Sie eine veraltete Funktion wie MD5 verwenden möchten (wenn Sie 2016+ sind). Sie können Tests durchführen, um festzustellen, wie groß der Unterschied in Speicher und Leistung zwischen MD5 und SHA2 ist.

0
Gabe