Über Hash und Datenlänge Dateien bilden...
-
ich hatte mal vor einer weile so eine idee
man nähme 4 bytes hashe sie,
dann probiert man per bruteforce aus wie viele koliesionen man überspringen muss um zu orginal wert zu kommen
abspeichern tut man dann den hash und die anzahl der kolisionendas problem dabei ist wenn der hash 1 byte groß ist, gibt es 0xFFF mögliche kolisonen d.h. man spart damit kein speicher platz ein
die idee ist "verlustbehafte text komprimierung", man speicher nur den hash und der algo am ende findet von alleine heraus welcher text es sein sollte, anhand rechtschreibung und gramatik, wenn dabei was schief wirds unterm tisch fallen gelassen
der komprimierer kann aber auch schon mal ein dekomprimieren durchspielen und dann extra informationen einbauen wo er merkt das es beim dekomprimieren unsicherheiten geben wird
-
ich behaupte mal ganz dreist, dass jedes andere "echte" kompressionsverfahren besser sein wird
-
Vor allem schneller beim Dekomprimieren
-
und weniger fehleranfaellig.
Aber ganz uninteressant ist die idee ja nicht.. fuer kleine Datenmengen waere es durchaus lustig sowas zu basteln..
Man ueberlege sich einfach, dass man eine Datei hat, die aus 1ern und nullen besteht, was dann also 2^(laenge der 1/0er Kette) waere. Haette man jetzt also den Hash der Kette sowie die Laenge der Kette koennte man im BF verfahren wahrscheinlihc die originaldaten wiederhestellen koennen, da man ja bei ketten bis 2^80 laenge theoretisch nur eine uebereinstimmung finden duerfte..
Keine ahnung ob das geht oder in irgendeiner Form perfomant ist - interessant waere es auf jeden fall.. denke aber, dass Aufwand > Nutzen ist.
-
Nachtwind schrieb:
Man ueberlege sich einfach, dass man eine Datei hat, die aus 1ern und nullen besteht, was dann also 2^(laenge der 1/0er Kette) waere. Haette man jetzt also den Hash der Kette sowie die Laenge der Kette koennte man im BF verfahren wahrscheinlihc die originaldaten wiederhestellen koennen, da man ja bei ketten bis 2^80 laenge theoretisch nur eine uebereinstimmung finden duerfte..
Wie kommst du auf diese Zahl, 2^80?
-
Hatte noch von irgendwann im schaedel, dass es eine chance von 1 zu 2^80 gibt einen 'Treffer' zu landen, wenn man randomisierte strings hasht
*edit* Falls falsch lasse ich mich gerne aufklaeren ;0) Komme absolut nicht mehr drauf wann ich das aufgeschnappt hab - die Informatik lingt zu lange zurueck *G*
-
@RobthaR:
ich will nicht rumflamen, aber dein Posting grenzt an ... naja, lassen wir das. Daher die Vermutung dass DU hier nur blöd rumspammen/-trollen willst.Dass dein Programm zu lange läuft ist klar, es will ja auch 2^136 Durchläufe machen (wenn du die Schleifenbedingung korrigierst bzw. einfach ints statt bytes verwendest). Und selbst mit Rechnern die eine Million mal schneller wären als das schnellste was uns heute an Computern zur Verfügung steht (Cluster, Supercomputer - was du willst) würde das immer noch milliarden Jahre dauern (was noch eine gewaltige Untertreibung ist).
Und um rauszubekommen wieviele mögliche Kollisionen eine Abbildung Daten -> Hash im Schnitt hat musst du auch nicht so eine Schleife laufen lassen, du musst nur die Länge des Hash mit der Länge der Daten vergleichen.
z.B. 800 Bit Daten (100 Byte) und 128 Bit Hash (16 Byte, z.B. MD5) ergibt im Schnitt 2^(800-128) also 2^672, also VIELE.Das ist auch keine höhere Mathematik, das sind grundlegendste Grundlagen.
-
Nachtwind schrieb:
und weniger fehleranfaellig.
Aber ganz uninteressant ist die idee ja nicht.. fuer kleine Datenmengen waere es durchaus lustig sowas zu basteln..
Man ueberlege sich einfach, dass man eine Datei hat, die aus 1ern und nullen besteht, was dann also 2^(laenge der 1/0er Kette) waere. Haette man jetzt also den Hash der Kette sowie die Laenge der Kette koennte man im BF verfahren wahrscheinlihc die originaldaten wiederhestellen koennen, da man ja bei ketten bis 2^80 laenge theoretisch nur eine uebereinstimmung finden duerfte..
Keine ahnung ob das geht oder in irgendeiner Form perfomant ist - interessant waere es auf jeden fall.. denke aber, dass Aufwand > Nutzen ist.Nein es geht nicht, und nein es wäre nicht performant.
BTW: wäre die Chance immer 1 zu 2^80 eine Kollision zu bekommen, dann könnte man auch maximal 80 Bit lange Daten nehmen, nicht 2^80. Grosser unterschied.
Und bei 80 Bit aka 10 Byte ... naja, jeder normale Hashcode ist länger.
Und Hashcodes wo die Chance eine Kollision zu bekommen 1 zu 2^80 ist sind normalerweise auch 80 Bit lange. Sowas, hm?
-
Ich weiss net was du willst, es war eine berechtigte Frage, und nur weil dus besser weisst, sagst du ich würd Spannen oder Trollen, is ja wohl net der Sinn eines Formums, denk ma drüber nach
Begründe erst mal deine Behauptung, ich würd Spammen/Trollen
-
RobthaR schrieb:
...
Begründe erst mal deine Behauptung, ich würd Spammen/TrollenBegründung: So blöd kann man garnicht sein.
Sorry, du hast danach gefragt.
