DEC 5.2 String hashen?

[a.def]

Eher hashen. Den Originalinhalt brauche ich danach nicht mehr.
Dabei stellt sich mir die Frage: MD5, SHA-XYZ oder BobJenkins. Oder etwas ganz anderes vielleicht.

[nahpets]

Was hast Du denn vor?

EXE gegen Manipulation per HEX-Editor ... schützen?

Da sollte MD5 für 'nen Selbsttest ausreichen.

[a.def]

Im Prinzip ja. Aber auch andere Spielereien. Ich stelle mir grundsätzlich nur die Frage welchen Hash man benutzen könnte ohne ihm direkt anzusehen welcher Algorithmus es ist.

[nahpets]

Die Antwort ist doch ganz einfach: Ein eigener.

Erfüllt zwei Bedingungen:

Es ist ein (lehrreiche) Spielerei.
Kein anderer kann ihn erkennen.

@Michael II
Klasse Erklärung

[a.def]

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

Dumme Frage:
ist eine Hash-Funktion nicht anderes als ein wildes herumschupsen von Zeichen?

[nahpets]

Zitat von a.def:

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

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.

[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 bytes := TEncoding.UTF8.GetBytes(str); und str := TEncoding.UTF8.GetString(bytes); aber das funktioniert nicht wie gewollt.

[himitsu]

Zitat:

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

Die größeren Hashs machen eher etwa sowas, aber vom Prinzip her ändert sich dabei nichts.
i := i xor (Ord(s[k]) * 12145612) mod 456413);
oder 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.
Und auch bei älteren Delphis sieht es in einem deutschen Windows anders aus, als in einem russischen Windows. (andere CodePages)

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