kleine theorie: komprimierung durch MD5 möglich?
-
ok, hast ja recht. geht ja gar nicht, für doppelt so viele strings unterschiedliche hashs zu bekommen.
aber, neue unsinnige idee: wenn man dazu noch ein anderes hash-system verwendet? als z.b. MD5 + CRC32 (oder was besseres, neueres) ???
-
Mal ne andere Frage:
Ich dachte einen Hash kann man nicht rückwärts rechnen, was hab ich also davon? Ich könnte die Daten ja garnichtmehr entpacken, oder?
-
hash --> lookuptable --> wert.
würde vermutlich pro hash mehr als 1 möglicher wert existieren.
gepaart mit nem 2. hash (z.b. CRC32) KÖNNTE es sein dass sich von allen möglichen werten dann der echte rausfinden liesse.
der lookuptable wird einfach gebaut indem man von (0) bis (maximum) hashes errechnet und eben abspeichert....
-
loki1985 schrieb:
also: ist diese idee vollkommen idiotisch und weltfremd, oder vielleicht doch ein klitzekleines bisschen interessant?
Völlig unsinnig. Hast du dich schonmal ansatzweise damit befasst, was Packverfahren tun, und warum das funktioniert?
-
loki1985 schrieb:
der lookuptable wird einfach gebaut indem man von (0) bis (maximum) hashes errechnet und eben abspeichert....
und wenn man, so wie er's vorschlägt, eine lookup table für alle kombinationen von 32bytes braucht, dann ist die mal eben 256^32 etwa 1.2*10^77 einträge gross
-
Dann doch lieber ungepackt als so einen Packer
-
mensch, es geht dabei doch einzig und alleine um die theorie, ob es möglich wäre etc.....
-
loki1985 schrieb:
mensch, es geht dabei doch einzig und alleine um die theorie, ob es möglich wäre etc.....
Hmmm, wenns normale Ascii Zeichen sind würde es gehen, sobald du Unicode hast müssen rein rechnerisch doch gleiche Hashes für unterschiedliche Strings rauskommen. Ganz davon ab, dass so eine Lookup Tabelle unmöglich wäre
-
the_alien schrieb:
davon ab, dass so eine Lookup Tabelle unmöglich wäre
... du hast es nur nicht richtig verstanden
-
Ich glaube eher DU hast nicht verstanden.... Siehe Bashars posting...
-
ich kann nur sagen dass ich mich bereits mit der theorie von huffman und dem Lempel-Ziv-Algorythmus beschäftigt habe....
und dann soll er mir einfach begründen, weshalb ein derartiger lookup-table unmöglich wäre. er wäre zwar lahm, aber schneller als das on-the-fly-berechnen via MD5.
-
loki1985 schrieb:
ich kann nur sagen dass ich mich bereits mit der theorie von huffman und dem Lempel-Ziv-Algorythmus beschäftigt habe....
Aber nicht mit der Theorie hinter dem Packen allgemein. Warum man überhaupt aus einer Bitsequenz eine kürzere machen kann, ohne Informationen zu verlieren. Welche Voraussetzungen dafür gegeben sind usw. Mach mal folgendes Gedankenexperiment: Du nimmst deinen Packer und wendest ihn iterativ auf sein eigenes Ergebnis an. Wenn er jedesmal die Daten auf die Hälfte komprimiert, hast du irgendwann nur noch 1 Bit. Dass man das nicht wieder entpacken kann liegt auf der Hand. Folgerung: Kein Packer kann beliebige Daten komprimieren.
-
exakt. diese erkenntnis ist mir auch schon gekommen (wäre trotzdem cool, einen film auf 1,44"-diskette zu kriegen
)aber meine überlegung ist ja auch keine regulärer ansatz zum komprimieren.
zudem in heutiger zeit fernab von nützlich, da man so für ein paar hundert byte vermutlich tage zum dekomprimieren bräuchte.die frage ob sich ein eindeutiges und einzig richtiges ergebnis "entpacken" lässt ist hier eben die frage und bin ich mir nicht im geringsten sicher...
daher die idee, für einen datenarray oder mehr technisch verschiedene hashs zu speichern....
lohnt sich nur wenn die daten grösser sind als alle hashs zusammen, aber je grösser die daten desto höher die gefahr, ein falsches ergebnis zu erhalten (glaube ich mal zumindest).../ADD: ich glaube absolut nicht dass meine überlegung tatsächlich funktioniert, denn sonst hätte sie schon irgendjemand präsentiert.
wie gesagt, ist nur so eine gedankliche spielerei.
-
loki1985 schrieb:
aber meine überlegung ist ja auch keine regulärer ansatz zum komprimieren.
Doch, in der Beziehung schon. Der Ausgang des Gedankenexperiments hängt ja nicht davon ab, ob der Packer in irgendeiner Art und Weise regulär ist.
-
Und mal ganz davon abgesehen, es sollte jedem mit gesundem Menschenverstand auffallen, dass kein Algorithmus aus allen 232 Kombinationen verschiedene Werte errechnen soll, die er auf 216 Möglichkeiten abbildet.
-
ness schrieb:
Und mal ganz davon abgesehen, es sollte jedem mit gesundem Menschenverstand auffallen, dass kein Algorithmus aus allen 232 Kombinationen verschiedene Werte errechnen soll, die er auf 216 Möglichkeiten abbildet.
eben, daher auch die idee mit mindestens 2 "technisch" unterschiedlichen algorythmen, z.b. MD5 UND CRC32 (wobei ich mal denke dass CRC32 schon zu alt und "billig" ist)....
-
loki1985 schrieb:
eben, daher auch die idee mit mindestens 2 "technisch" unterschiedlichen algorythmen, z.b. MD5 UND CRC32 (wobei ich mal denke dass CRC32 schon zu alt und "billig" ist)....
crc ist nicht billig. das ist auf speed ausgelegt. anders als md5 wo's darum geht möglichst wenig mehrdeutigkeiten zu haben
-
ok, ich habe da nicht so den durchblick. nur eben bräuchte mann für so einen test ein system welches auf möglichst wenige gleiche hashes ausgelegt ist....
-
loki1985 schrieb:
ok, ich habe da nicht so den durchblick. nur eben bräuchte mann für so einen test ein system welches auf möglichst wenige gleiche hashes ausgelegt ist....
Das ist jeder vernünftige Hash-Algorithmus. Aber möglichst wenig heißt in deinem Fall immer noch 2^128 auf eins.
Ehrlich gesagt machst du ungefähr den Eindruck von einem, der ein Perpetuum Mobile bauen will.
-
Bashar schrieb:
Ehrlich gesagt machst du ungefähr den Eindruck von einem, der ein Perpetuum Mobile bauen will.
ich weiss. aber manchmal gönne ich es mir einfach, etwas rumzuspinnen
nur bei dem PM bin ich schneller darauf gekommen, dass es nicht möglich ist (oder doch
)