DEC 5.2 String hashen?

[himitsu]

BobJenkins ist klein (32 Bit, ähnlich CRC32) und schnell.

MD5 ist größer (128 Bit) und langsamer, aber dafür eben auch "genauer".

SHA1 = 512 Bit


Kommt drauf an, was man erreichen will, wie sehr sich der Hash dann bei "kleineren" Änderungen ändert, wie Manupulationssicher es sein soll und wie schnell es gehn soll.

z.B. XOR, da ändert man zwei Mal das selbe Bit in verschiedenen Bytes und dennoch bleibt der Hash unverändert.
$F8 xor $8F = $77
$E8 xor $9F = $77
$8F xor $F8 = $77

[a.def]

Heißt also je genauer, desto weniger Kollisionen UND desto eher ändert sich der Hash bei Änderungen des Inputs?

Demnach ist XOR also sehr ungenau?

[himitsu]

Jupp.

im gegensatz zu MD5/SHA1 bringen kleine Eingangsänderungen eine große Ausgangsänderung.
Daher ist es schwerer eine "Kollision" zu erreichen.
1 Bit im Input ändern, ändert nahezu alle Bits im Ausgang.

Aber bei XOR ändert es eben nur dieses eine Bit und man kann das mit einem anderen Bit wieder zurückändern.
Da hier auch alle bytes gleich behandelt werden, ist es da auch egal in welchem Byte man das macht.



PS: Kreuzsummen kannst du als Hash-Beispiel missbrauchen.
Einfach alle Bytes ordinal addieren und dann dividieren.
(1 + 3 + 5 + 79 + 19 + 36) mod 16 = ein Hash mit 4 Bit
Wenn ich dir jetzt den Hash 15 gebe, dann hast du aber keine Chance das wieder auf die Ursprungszahlen zurückzurechnen.
Es könnte ja auch
(1 + 3 + 6 + 78 + 19 + 36)
oder
(1 + 3 + 5 + 78 + 19 + 36 + 1)
oder sonstwas sein.



Wie schon erwähnt, gibt es aber immer mehrere Inputs, die den selben Outpout haben.
Somit gibt es bei jedem Hash auch eine "alternative" Lösung.
Jemand hasht dein Passwort, ich erfahre den Hash, rechne zurück oder nutze z.b. eine vorberechnete RainbowTables und besorg mir einfach ein anderes Passwort, was passt.
Es könnte sogar dein eigenes Passort sein, aber das wäre sehr unwahscheinlich und wenn doch, dann wüsste ich es eh nicht, ob es wirklich Deines ist.

[nahpets]

Zitat:

Zitat von a.def (Beitrag 1369825)

Die Erklärung ist echt der Wahnsinn das stimmt.
Ein eigener Hash? Klingt lustig, würde ich aber niemals hinbekommen :P

Warum nicht?

Delphi-Quellcode:

function KomischerHash(s : String; iHashLen : Integer) : String;
var
   i : Cardinal;
   k : Integer;
begin
  i := 0;
  for k := 1 to Length(s) do begin
    i := i + Ord(s[k]);
    if i > MaxLongInt then i := i mod MaxLongInt;
  end;
  Result := '';
  s := IntToStr(i);
  for k := 1 to Length(s) do Result := Result + IntToHex(Ord(s[k]),2);
  while Length(Result) < iHashLen do Result := Result + ReverseString(Result);
  Result := Copy(Result,1,iHashLen);
end;

Statt 'nem String kann man auch 'nen Stream nehmen und den byteweise durchgehen. (Wäre für 'ne EXE sicherlich sinnvoller.)
Eigentlich ist nur Phantasie gefordert.
Und unterschiedliche Eingaben sollten (wenn möglich) zu unterschiedlichen Ergebnissen führen. (Der Hash sollte nicht immer 42 sein ;-))
Vom Ergebnis muss / darf kein Rückschluss auf die Eingabe möglich sein.
Und die Ergebnisse müssen reproduzierbar sein.

Betrachte doch einfach mal diverse Prüfziffern (ISBN, Personalausweisnummer, IBAN ...)
Mehrere dieser "Zeichenfolgen" haben die gleiche Prüfziffer. Aus der Prüfziffer kann man aber nicht auf die "Zeichenfolge" zurückschließen.
Aber wenn Du den Algorithmus kennst, kannst Du jederzeit die Prüfziffer neu berechnen und bei fehlender Übereinstimmung auf eine Manipulation der "Zeichenfolge" schließen.

[Aviator]

Zitat:

Zitat von Michael II (Beitrag 1369816)

[...] (alles :))

:thumb: :thumb: :thumb:

[a.def]

Ich guck mir das später mal genauer an. Das mit TBytes verstehe ich noch nicht genau. Würde super gerne alles auf TBytes umstellen aber naja.
Internet sagt dazu

Delphi-Quellcode:

bytes := TEncoding.UTF8.GetBytes(str);

und

Delphi-Quellcode:

str := TEncoding.UTF8.GetString(bytes);

aber das funktioniert nicht wie gewollt.

[himitsu]

Zitat:

Delphi-Quellcode:

i := i + Ord(s[k]);

Die größeren Hashs machen eher etwa sowas, aber vom Prinzip her ändert sich dabei nichts.

Delphi-Quellcode:

i := i xor (Ord(s[k]) * 12145612) mod 456413);

oder

Delphi-Quellcode:

i := (Ord(s[k]) * 12145612 + i) mod 456413);

ABER: string
Man sollte immer einen "definierten" Input verwenden.
Hier würde ich UTF-8 oder Unicode empfehlen (notfalls auch ANSI, aber besser zukunftsicher, als oldtyle).
Denn solange nur ASCII in den String rein kommt, ändert sich nichts, aber wenn ab Delphi 2009 der "String" ein UnicodeString und kein AnsiString mehr ist, dann ist das Erbebnis der Berechnungen schnell mal ein Anderes. :stupid:
Und auch bei älteren Delphis sieht es in einem deutschen Windows anders aus, als in einem russischen Windows. (andere CodePages)

[nahpets]

Sagen wir mal so:

Ein String als Eingabe für 'nen Hash eher suboptimal.

Byteweise durch 'nen Stream oder ein ByteArray sollte hier sinnvoller sein.

Und es dürfen natürlich keine (wie auch immer gearteten) Abhängigkeiten zu irgendwelchen Systemeinstellungen oder sonstige Konfigurationen bestehen.

Sprich: Es muss immer ein reproduzierbares Ergebnis rauskommen.

Egal auf welchem Rechner, egal unter welchem Betriebssystem ...

[p80286]

Wer bildet den über char einen Hash, das ist doch "stille Post"

Gruß
K-H

[a.def]

---