Hash-Funktion

[HugoHase]

Einen schönen guten Tag an alle.

Ich hoffe Ihr wisst alle was eine Hash-Funktion ist. Für alle die es nicht wissen gibt es diesen Link.
Genau dieses Thema behandel ich in meiner BLL(Facharbeit fürs Abitur).
Und da ich wie ich meine ein weinig kreativ war, ist bei der ganzen Sache auch etwas entstanden:

FP32 - das ist meine eigene Hash-Funktion.
Sie gibt einen 32 Zeichen langen String aus und benutzt folgendes 91 Zeichen langes Ausgabe-Alphabet:
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvw xyz0123456789!"§$%&/()=?_-[]{}+*~#<>:,.|;\"
Im Anhang an dieses Thema werdet ihr die Datei uFP32.dcu finden welche diese Funktion beihaltet.
Quellcode kann ich euch aus sicherheitstechnischen Gründen noch nicht geben, verspreche aber nach der Abgabe
meiner Facharbeit diesen zu posten.
Was ich von euch jetzt möchte, ist das ihr versucht Kollisionen zu finden und mir diese bitte zu melden.
Ansosnten denke ich, dass die Hash-Funktion durchaus geeignet ist um sie in ein kleines privates Projekt
einzubinden, um eventuell eine Passwort abfrage ohne Klartext zu tätigen.

In diesem Sinne viel Spaß damit

Gruß HugoHase

[Xong]

Zitat:

Zitat von HugoHase

FP32 - das ist meine eigene Hash-Funktion.
Sie gibt einen 32 Zeichen langen String aus und benutzt folgendes 91 Zeichen langes Ausgabe-Alphabet:
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvw xyz0123456789!"§$%&/()=?_-[]{}+*~#<>:,.|;\"

Eine Hash-Funktion gibt keine Zeichen aus, sondern eine Bitfolge. Diese Bitfolge kann als hexadezimale Zahl interpretiert werden. Das wären die Zeichen 0-9 und A-F.

Wenn du Hilfe möchtest, solltest du den Algorithmus darlegen.

Zitat:

Zitat von HugoHase

Quellcode kann ich euch aus sicherheitstechnischen Gründen noch nicht geben, verspreche aber nach der Abgabe meiner Facharbeit diesen zu posten

Du siehst mich mit Unverständnis dreinblicken.
Was versprichst du dir von der Geheimhaltung?

LG,
Xong

[Meflin]

Zitat:

Zitat von Xong

Du siehst mich mit Unverständnis dreinblicken.
Was versprichst du dir von der Geheimhaltung?

Er kriegt drauf ne Note. Wäre er ja schön blöd, wenn er den code hier veröffentlicht und dann wegen Abschreibens 0 Punkte bekommt ;)

[HugoHase]

Danke für die Antwort:

Zitat:

Was versprichst du dir von der Geheimhaltung?

Am 18.12. Ist der Abgabe Termin meiner Arbeit.
Und da dieser Algorithmus ein Hauptbestandteil der Arbeit ist, die noch benotet wird möchte ich diesen nicht preisgeben bis die Arbeit in den Händen des Korektors ist. Ich bitte um Verständnis.

Zitat:

Eine Hash-Funktion gibt keine Zeichen aus, sondern eine Bitfolge. Diese Bitfolge kann als hexadezimale Zahl interpretiert werden. Das wären die Zeichen 0-9 und A-F.

Es ist doch egal ob die Ausgabe nun als String oder Bitfolge geschiet.

Gruß

[sx2008]

Zitat:

Zitat von HugoHase

Sie gibt einen 32 Zeichen langen String aus und benutzt folgendes 91 Zeichen langes Ausgabe-Alphabet

Das wären 91^32 = 4,89e+62 verschiedene Möglichkeiten.
Im Vergleich dazu hat MD4 oder MD5 ungefähr 3,40e+38 Möglichkeiten.
Ich denke mal, durch Brute Force lässt sich bei deiner Hash-Funktion keine Kollision finden.
Da aber deine Hashfunktion 10 Trilliarden (!) mehr Möglichkeiten als MD4 oder MD5 hat ist das völlig aussichtslos.
Nur wenn der Algorithmus bekannt wäre könnte man rückwärts rechnen und Hinweise auf eine schwache Implementierung finden.

[HugoHase]

Dann guck bitte am besten noch mal am 18. oder 19. Dezember rein wenn ich den Quelltext poste ;)

[Xong]

Zitat:

Zitat von HugoHase

Danke für die Antwort:

Zitat:

Eine Hash-Funktion gibt keine Zeichen aus, sondern eine Bitfolge. Diese Bitfolge kann als hexadezimale Zahl interpretiert werden. Das wären die Zeichen 0-9 und A-F.

Es ist doch egal ob die Ausgabe nun als String oder Bitfolge geschiet.

Naja, einige Bits bleiben bei dir halt ungenutzt.
Das ist ineffizient.

Letztendlich hast du recht: Für die Funktionsweise einer Hashfunktion ist das irrelevant. Allerdings solltest du darauf in deiner Arbeit hinweisen.

[sx2008]

Zitat:

Zitat von Xong

Naja, einige Bits bleiben bei dir halt ungenutzt. Das ist ineffizient.

Es kommt auf den Zweck an.
Bei vielen Dateien (vorallem Programme und ISO-Images) werden ja MD5 und SHA1-Prüfsummen als Hexstring angegeben,
damit derjenige, der die Dateien runtergeladen hat prüfen kann ob die Dateien unverfälscht sind.
Beispiel: http://ftp.uni-kl.de/pub/linux/knoppix/
In drei Jahren wird es nur "HugoHaseHash" geben; auch bekannt als Tripple-H. :mrgreen:

[HugoHase]

Zitat:

Naja, einige Bits bleiben bei dir halt ungenutzt.
Das ist ineffizient.

Danke ich mus die Auswertung noch schreiben.
Dein Kommentar wird sich also darin wieder finden ;)
Wenn man den Hash als Zufallswert nutzt ist es auf jeden Fall ineffizient.
Solange man sich jedoch auf das vergleichen der Strings konzentriert,
ist das denke ich mal irrelevant.
Aber auch der Speicher für den Hash wird nicht optimal ausgenutzt,
da man ja für jeden Char ein Byte(256Bits) speicher aber nur 91 Bits benutzt.

Gruß ;)

[HugoHase]

Zitat:

In drei Jahren wird es nur "HugoHaseHash" geben; auch bekannt als Tripple-H.

Tripple-H ist genial ich lag flach als ich es laß, xD
aber ich kann in meiner Facharbeit schlecht erklären,
dass mein Internet-Pseudonym HugoHase ist und ich die Funktion deshalb so nenne,
was mich irgendwie ärgert. :cry:

Gruß

[HugoHase]

Zitat:

Das wären 91^32 = 4,89e+62 verschiedene Möglichkeiten.

Da fällt ir ja grad was auf ... es sind 32^91 = 10^137 (also 137 Stellen im Dezimalsystem) = 2^455 mögliche Ergebnisse
Gruß HugoHase

[gammatester]

Zitat:

Zitat von HugoHase

Zitat:

Das wären 91^32 = 4,89e+62 verschiedene Möglichkeiten.

Da fällt ir ja grad was auf ... es sind 32^91 = 10^137 (also 137 Stellen im Dezimalsystem) = 2^455 mögliche Ergebnisse
Gruß HugoHase

Nö, 91^32 ist richtig :? . 1 Stelle = 91 Möglichkeiten, 2 Stellen 91^2 etc. Sonst hättest Du ja auch bei einer zweistellen Dezimalzahl 2^10 = 1024 Möglichkeiten!!! :shock:

Gammatester

[Xong]

Zitat:

Zitat von HugoHase

Solange man sich jedoch auf das vergleichen der Strings konzentriert,
ist das denke ich mal irrelevant.

Hashes werden effizient (also z. B. in DBMS) nicht über ihre Stringerscheinungen verglichen.

Ein XOR Vergleich ist wesentlich schneller.

Wie genau bei einem DBMS der Hashwert beim Suchen im AVL-Baum verglichen wird, weiß ich nicht, aber auf jeden Fall werden dafür nicht mehr als 4 Assemblerbefehle verschwendet:

Code:

Load ZAHL1
Load ZAHL2
Sub
JumpSigned (Sprung, wenn negativ)

Zitat:

Zitat von sx2008

Zitat:

Zitat von Xong

Bei vielen Dateien (vorallem Programme und ISO-Images) werden ja MD5 und SHA1-Prüfsummen als Hexstring angegeben, damit derjenige, der die Dateien runtergeladen hat prüfen kann ob die Dateien unverfälscht sind.

Das ist bei HugoHases Hash auch ohne Probleme möglich.
Er hat 32 8-Bit-Zeichen. Das wären also 64 Hexwerte.
Dabei sieht man dann auch recht schnell, dass bestimmte Hexwertpaare gar nicht vorkommen werden. Ich könnte auf Anhieb mehr als 1000 solcher Paare nennen. Das meint ich mit der ineffizienten Bitauslastung.

Letztendlich hat Hugo nur 91 (oder 92?) Zeichen, die er verwendet. Konsequent wäre, 128 oder 64 Zeichen zu verwenden und eine entsprechende Kodierung dafür zu nutzen. Alle Bits würden gleich oft vorkommen.
Ein Beispiel für eine 64-Zeichen-Kodierung wäre Base64 (A-Za-z0-9_-).
Im Moment verschwendet er 256-91=165 weitere mögliche Zeichen, nutzt also noch nicht mal die Hälfte aller möglichen Zeichen.

LG,
Xong

[HugoHase]

Ok gib mir nen bisschen Zeit du hast mich überzeugt, Xong
;)
Ich hätte das hier füher posten sollen -.-
Vielen Dank an alle

[HugoHase]

Also nun die überarbeitete Version der FP32 aka Tripple-H Funktion:
Wenn ich mich jetzt nicht irre hat sie nun 16^64 mögliche Ergebnisse.
Im Anhang findet ihr wieder die uFP32.dcu und das kleine Test-Programm.
MfG HugoHase

[cherry]

und wo bleibt jetzt der code? ;-)

[QuickAndDirty]

Jetzt ist der Code Firmen Geheimnis von CompuGlobalHyperMegaNet dem Internet Start up.


@Hugo Hase
Are you bitchchecker?

[cherry]

Zitat:

Zitat von HugoHase

Dann guck bitte am besten noch mal am 18. oder 19. Dezember rein wenn ich den Quelltext poste ;)

so viel zu dem !!!

[Florian H]

Zitat:

Zitat von cherry

Zitat:

Zitat von HugoHase

Dann guck bitte am besten noch mal am 18. oder 19. Dezember rein wenn ich den Quelltext poste ;)

so viel zu dem !!!

Friede sei mit dir ... der Thread wurde heute erst wieder ausgegraben, vielleicht hat er einfach nicht dran gedacht.

[HugoHase]

Nein ich hab in nicht vergessen wollte nur noch etwas Zeit verstreichen lassen.
Hier wie versprochen der Quelltext:

[himitsu]

erstmal nur was zum Code

die "globalen" Variablen sind etwas verwirrend (beim Codeverstehn, da man nicht so direkt nachvollziehen kann wie die wohin übergeben und verwendet werden)

Delphi-Quellcode:

var schluessel: byte; //primär Schlüssel
    high, low: byte;
    vz, laenge, sS : integer;
    ch : boolean;

dann wäre es nicht nötig gewesen intern je eine Funktion für String und ByteArra zu machen.
(doppelter Code)

mit String hast'e unter D2009 einige Probleme, da dieses dort standardmäig ein UnicodeString ist (2 Byte pro Char) ... wär wohl besser AnsiString zu verwenden

ist dir aufgefallen, daß String und ByteArray eine unterschiedliche Indizierung der Elemente verwenden?
(so auf dn ersen blick sieht es so aus, als wenn du immer von 1 bis Length-1) arbeitest, aber
ByteArray: 0 bis Length-1
String: 1 bis Length
was doch eigentlich in 'ner fehlerhaften/unterschiedlichen Berechnung resultieren dürfte (noch nicht getestet)

nja und auf ein/zwei Optimierungen geh ich erstmal nicht ein, da es hier wohl mehr nur auf das Prinzip (die Berechnung) ankommt



[add]
im Anhang mal die Unit ohne mehrfachen Code für String und ByteArray (jetzt geben beide Hash-Funktionen auch auf jedenfall das Selbe Ergebnis aus)

es sollte aber zusätzlich dennoch die Sache mit den "globalen" Variablen reguliert werden!

Dieses hier (siehe folgender Code) liefert mit deinem Original-Quellcode unterschiedliche Hashs,
obwohl die übergebenen Daten den selben Inhalt aufweisen und es sollte doch keinen Unterschied machen, ob die Daten in einer "Datei" (TByteM) oder einem "Text" (String) vorliegen :warn:

Delphi-Quellcode:

var S: String;
    B: TByteM;
begin
  S := '123456789';
  SetLength(B, Length(S));
  Move(S[1], B[0], Length(S));
  Edit1.Text := hash(S);
  Edit2.Text := hash(B);
end;

Code:

Edit1: 8C131659DD81F2174918ECE7A386C19C0215B56C5C838A21BB127EF1158053A6
Edit2: 25CFAF1DA1ADD7457F9B158B637943B33B5781F1313BAF1F0913DD5DF709118B