SHA-3 von Wolfang Ehrhardt

[Uwe Raabe]

Zitat von samso:

Ich kann weiterhin nicht glauben, dass size=Length(Bytes) gilt. Wieso soll die Länge des Strings nach der Umkodierung die Größe (in Bytes) des Strings vor der Umkodierung sein? Kann mir das jemand erklären?

Du hast vollkommen Recht: Length(bytes) wäre hier korrekt. Je nach Encoding ist die Länge der Bytes in der Regel kürzer als die vorher berechnete Size. Demnach haben wir hier einen klassischen Buffer-Overrun, wie er bei Pointer-Programmierung leider sehr häufig vorkommt. Damit werden auch unbestimmte Bytes mit in den Hash eingerechnet, die in den TBytes gar nicht vorkommen, sondern zufällig im Speicher dahinter liegen (deshalb auch der Unterschied zwischen der Verwendung von Size und Length(Bytes)). Bei Size ist das Ergebnis daher auch nicht deterministisch.

Eine aktuelle Implementierung würde vermutlich gleich auf TBytes aufsetzen und wäre damit auf die Angabe der Puffergröße gar nicht angewiesen.

[gammatester]

Zitat von Uwe Raabe:

Eine aktuelle Implementierung würde vermutlich gleich auf TBytes aufsetzen und wäre damit auf die Angabe der Puffergröße gar nicht angewiesen.

Ich sehe nicht wie das mit BP7 oder VP21 kompatibel sein soll. Außerdem habe ich keine Lust und Zeit, für alle möglichen Eingabetypen separate Funktionen zu schreiben. Im übrigen ist die Form Init/Update/Final mit Pointern ziemlich verbreitet bei Hash-Implementationen (wahrscheinlich durch C beeinflußt).

[Uwe Raabe]

Zitat von gammatester:

Ich sehe nicht wie das mit BP7 oder VP21 kompatibel sein soll.

Soll es ja auch gar nicht.

Zitat von gammatester:

Außerdem habe ich keine Lust und Zeit, für alle möglichen Eingabetypen separate Funktionen zu schreiben.

Das ist ja auch dein gutes Recht.

Zitat von gammatester:

Im übrigen ist die Form Init/Update/Final mit Pointern ziemlich verbreitet bei Hash-Implementationen (wahrscheinlich durch C beeinflußt).

Eine weite Verbreitung ist aber nicht wirklich ein Qualitätsmerkmal. Der oben angesprochene Fehler ist doch ein ziemlich eindeutiges Indiz.

[gammatester]

Zitat von Uwe Raabe:

Zitat von gammatester:

Ich sehe nicht wie das mit BP7 oder VP21 kompatibel sein soll.

Soll es ja auch gar nicht.

Aber sicher soll es das. Die meisten direkten Rückmeldungen und Optimierunsvorschläge erhalte ich übrigens für VP21, Delphi3 und TP6(!) Vielleicht auch bedingt dadurch, daß die Funktionen praktisch für alle Kompiler nutzbar sind.

Zitat von Uwe Raabe:

Zitat von gammatester:

Im übrigen ist die Form Init/Update/Final mit Pointern ziemlich verbreitet bei Hash-Implementationen (wahrscheinlich durch C beeinflußt).

Eine weite Verbreitung ist aber nicht wirklich ein Qualitätsmerkmal. Der oben angesprochene Fehler ist doch ein ziemlich eindeutiges Indiz.

Der oben angesprochene Fehler ist mM ein Resultat der undurchsichtigen Kompiler-Magie: wenn man nicht verschleiern würde das TBytes kein Array sondern ein Pointer auf ein Array ist, wäre der Fehler offensichtlich.

[Uwe Raabe]

Zitat von gammatester:

Aber sicher soll es das. Die meisten direkten Rückmeldungen und Optimierunsvorschläge erhalte ich übrigens für VP21, Delphi3 und TP6(!) Vielleicht auch bedingt dadurch, daß die Funktionen praktisch für alle Kompiler nutzbar sind.[/QUOTE]

.. oder weil die Benutzung durch neue Compiler unnötig umständlich ist?

Ich habe ja nicht behauptet, daß die bestehenden Methoden durch neue ersetzt werden sollen. Vielmehr hatte ich an overloaded-Versionen für TBytes als Alternative gedacht. So diese denn unter bestimmten Compilern nicht unterstütz werden, kann man die ja durch conditional defines ausblenden.

Allerdings habe ich jetzt auch keine Lust, über den Sinn oder Unsinn von alten oder anderen Compilern zu diskutieren. Insofern steht es dir natürlich frei, deine Routinen so zu gestalten wie du es für richtig hältst.

[Ghostwalker]

Zitat von Uwe Raabe:

Der oben angesprochene Fehler ist doch ein ziemlich eindeutiges Indiz.

Der Fehler hat eher was mit Wäldern und Bäumen zu tun, als mit irgend etwas anderem

Das in der Bibleothek ein Pointer und die Größe erwartet wird, ist völlig normal. Die Bibleothek soll
ja ein möglichst breites Publikum ansprechend und das bedingt verschiedene Comiler und Compilerversionen.

Btw. hier nun der entgültige Code, der, soweit ich das im Moment beurteilen kann, auch korrekt läuft.

Delphi-Quellcode:

  if (length(trim(ftoHash)) = 0) then exit;
  SHA3_512Init(fcontext);
  fbytes := TEncoding.GetEncoding('UTF-16').GetBytes(fToHash);
  fSize := TEncoding.GetEncoding('UTF-16').GetByteCount(fToHash);
  SHA3_512Update(fcontext,@fbytes[0],fsize);
  SHA3_512Final(fcontext,fdigist);
  fHash := Base64Str(@fdigist,sizeof(fdigist));

[gammatester]

Zitat von Ghostwalker:

Btw. hier nun der entgültige Code, der, soweit ich das im Moment beurteilen kann, auch korrekt läuft.

Wie schon gesagt: Sicherheitshalber solltest Du SHA3_512UpdateXL benutzen.

[Uwe Raabe]

Das ist aber doch unnötig kompliziert, oder? (auch eine Art von Code-Obfuscation)

Delphi-Quellcode:

  fbytes := TEncoding.GetEncoding('UTF-16').GetBytes(fToHash);
  fSize := TEncoding.GetEncoding('UTF-16').GetByteCount(fToHash);

Warum nicht gleich so?

Delphi-Quellcode:

  
  fbytes := TEncoding.GetEncoding('UTF-16').GetBytes(fToHash);
  fSize := Length(fBytes);

Oder so?

Delphi-Quellcode:

  
  fbytes := TEncoding.Unicode.GetBytes(fToHash);
  fSize := Length(fBytes);

Wobei der ByteCount von Unicode auch wieder nur CharCount * SizeOf(Char) ist. TEncoding.Default ist von den aktuellen Windows-Einstellungen abhängig, also eher ungünstig. Etwas sparsamer und trotzdem allgemein gültig wäre da noch UTF8:

Delphi-Quellcode:

  
  fbytes := TEncoding.UTF8.GetBytes(fToHash);
  fSize := Length(fBytes);

Wenn die Hashes auch anderweitig verwendet werden, muss sowieso das Encoding bekannt gemacht werden. Sonst kann niemand was damit anfangen.