SHA-3 von Wolfang Ehrhardt

[Ghostwalker]

Zitat von TiGü:

Ich kenne die Biblothek nicht, aber müsste es nicht eher so lauten?

SHA3_512Update(Context,@Bytes, Length(Bytes));

Hmm...sollte aufs gleiche rauskommen. Habs grad mal geprüft, das verhalten ändert sich nicht.
Bei jedem Programmstart bekomm ich unterschiedliche Hashes.

[TiGü]

Hast du kontrolliert, ob Bytes immer gleich ist?
Vielleicht ergibt sich da schon die Abweichung?

[Ghostwalker]

Die Bytes die rein gehen sind immer die gleichen. Das was raus kommt (digist ist auch ein Byte-Array) ist immer anders.

[Ghostwalker]

Autsch.....

das
SHA3_512Update(Context,@bytes,size); muss
SHA3_512Update(Context,@bytes[0],size); sein.

Er braucht die Adresse des 1. Bytes im Array, nicht die Adresse der Array-Variable.

Trotzdem Danke

[gammatester]

Du bist ein Opfer der Compiler-Magie gewerden. Nach der Deklaration Bytes : TBytes; ist Bytes (natürlich?) ein Pointer und mit @bytes berechnest Du nicht den Hash von Bytes sondern den Hash des Pointers (und der ändert sich in der Regel, weil ja die Speicheraddresse sich je nach Allokation ändert).

Mit der korrigierten Version

Delphi-Quellcode:

program t_dp_ex;
uses
  system.hash, system.sysutils,
  btypes, mem_util, hash, sha3_512;

{$i std.inc}

{$ifdef APPCONS}
  {$apptype console}
{$endif}

{-----------------------------------------}
function CreateHash(aString:string):string;
var
  Context : THashContext;
  Digist : TSHA3_512Digest;
  //bytes : Array of Byte;
  size : Integer;
  Bytes : TBytes;

begin
  SHA3_512Init(Context);
  size := aString.Length * SizeOf(Char);
  Bytes := TEncoding.Default.GetBytes(aString);
  SHA3_512Update(Context,bytes,size);
  SHA3_512Final(Context,Digist);
  result := Base64Str(@Digist,sizeof(Digist));
end;

begin
  writeln(CreateHash('abc1234'));
end.

Code:

erhalte ich immer das gleiche Ergebnis:
G:\CRC_HASH>t_dp_ex.exe
Zzvn3sQanFpmGDltaWoEMPBRm4tEtBzAP22pOKoe3X1TCY4VN5K8a0cFNWBDOYo8oNInfUYU/tNJWDFf
XXftyA==

G:\CRC_HASH>t_dp_ex.exe
Zzvn3sQanFpmGDltaWoEMPBRm4tEtBzAP22pOKoe3X1TCY4VN5K8a0cFNWBDOYo8oNInfUYU/tNJWDFf
XXftyA==

G:\CRC_HASH>t_dp_ex.exe
Zzvn3sQanFpmGDltaWoEMPBRm4tEtBzAP22pOKoe3X1TCY4VN5K8a0cFNWBDOYo8oNInfUYU/tNJWDFf
XXftyA==

Gruß Gammatester

[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?

Edit:
Ah, jetzt ist der Groschen gefallen. Ich dachte, da wird nach Ansi umkodiert. Anscheinen wird aber wohl nur kopiert.
Edit2: Unsinn: Doch, TEncoding.Default.GetBytes wandelt nach Ansi um.

[gammatester]

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?

Edit:
Ah, jetzt ist der Groschen gefallen. Ich dachte, da wird nach Ansi umkodiert. Anscheinen wird aber wohl nur kopiert.

Wie auch immer: Falls nicht gewährleistet ist, daß Bytes weniger als 64 K groß ist, sollten das Hashen mit SHA3_512UpdateXL durchgeführt werden.

Mit length(Bytes) erhalte ich übrigens auch ein anderes Ergebnis für meinen Teststring.

[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.