![]() |
Hash-Funktion
Liste der Anhänge anzeigen (Anzahl: 2)
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 ![]() 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 |
Re: Hash-Funktion
Zitat:
Wenn du Hilfe möchtest, solltest du den Algorithmus darlegen. Zitat:
Was versprichst du dir von der Geheimhaltung? LG, Xong |
Re: Hash-Funktion
Zitat:
|
Re: Hash-Funktion
Danke für die Antwort:
Zitat:
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:
Gruß |
Re: Hash-Funktion
Zitat:
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. |
Re: Hash-Funktion
Dann guck bitte am besten noch mal am 18. oder 19. Dezember rein wenn ich den Quelltext poste ;)
|
Re: Hash-Funktion
Zitat:
Das ist ineffizient. Letztendlich hast du recht: Für die Funktionsweise einer Hashfunktion ist das irrelevant. Allerdings solltest du darauf in deiner Arbeit hinweisen. |
Re: Hash-Funktion
Zitat:
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: ![]() In drei Jahren wird es nur "HugoHaseHash" geben; auch bekannt als Tripple-H. :mrgreen: |
Re: Hash-Funktion
Zitat:
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ß ;) |
Re: Hash-Funktion
Zitat:
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ß |
Re: Hash-Funktion
Zitat:
Gruß HugoHase |
Re: Hash-Funktion
Zitat:
Gammatester |
Re: Hash-Funktion
Zitat:
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:
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 |
Re: Hash-Funktion
Ok gib mir nen bisschen Zeit du hast mich überzeugt, Xong
;) Ich hätte das hier füher posten sollen -.- Vielen Dank an alle |
Re: Hash-Funktion
Liste der Anhänge anzeigen (Anzahl: 2)
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 |
Re: Hash-Funktion
und wo bleibt jetzt der code? ;-)
|
Re: Hash-Funktion
Jetzt ist der Code Firmen Geheimnis von CompuGlobalHyperMegaNet dem Internet Start up.
@Hugo Hase Are you bitchchecker? |
Re: Hash-Funktion
Zitat:
|
Re: Hash-Funktion
Zitat:
|
Re: Hash-Funktion
Liste der Anhänge anzeigen (Anzahl: 2)
Nein ich hab in nicht vergessen wollte nur noch etwas Zeit verstreichen lassen.
Hier wie versprochen der Quelltext: |
Re: Hash-Funktion
Liste der Anhänge anzeigen (Anzahl: 1)
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:
dann wäre es nicht nötig gewesen intern je eine Funktion für String und ByteArra zu machen.
var schluessel: byte; //primär Schlüssel
high, low: byte; vz, laenge, sS : integer; ch : boolean; (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 |
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:46 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz