---

Geschrieben von Genie am 06.08.2014 um 16:06:

  idealer Hash-Algorithmus

Meine Frage:
Hallo,
Meine Frage wäre was könnte man mit einem idealen Hash-Algorithmus alles anstellen. Ich habe schon einen ziemlich einfachen Hash-Algorithmus entwickelt der alle Eingaben eindeutig einer Zahl zuordnet und darauf ein Patent angemeldet.

Das Problem ist nur dass der Speicher nahezu unendlich groß sein muss um alle möglichen Buchstabenkombinationen zu adressieren.

Meine Ideen:
- Speicheradressierung
- Datenverschlüsselung

---

Geschrieben von Julius am 06.08.2014 um 17:46:

 

Ein großer Vorteil einer perfekten Hashfunktion ist die konstant schnelle Zugriffszeit. Ein weites Einsatzgebiet finden sie in der Kryptographie (Integrität, Signaturen usw.). Hashing und Verschlüsselung sind aber zwei Paar Schuhe!

Neben der Bildmengengröße spielt auch die Berechnungszeit in der Praxis eine große Rolle. Deshalb werden traditionelle Algorithmen häufig bevorzugt.

---

Geschrieben von ed209 am 06.08.2014 um 23:53:

  RE: idealer Hash-Algorithmus

Zitat:

Ich habe schon einen ziemlich einfachen Hash-Algorithmus entwickelt der alle Eingaben eindeutig einer Zahl zuordnet und darauf ein Patent angemeldet.

---

Geschrieben von Genie am 07.08.2014 um 14:35:

  RE: idealer Hash-Algorithmus

Wie könnte man einen idealen Hash-Algorithmus am besten Vermarkten?

---

Geschrieben von Karlito am 07.08.2014 um 15:36:

 

Wieso denkst du denn, dass dein Hash-Algo besser ist als all die anderen?

Gruß,

Karlito

---

Geschrieben von Genie am 07.08.2014 um 17:46:

 

Weil er definitiv kollisionsfrei hasht

---

Geschrieben von Karlito am 07.08.2014 um 20:18:

 

Ah, OK. Damit ist es keine Hashfunktion. Eine größere Menge auf eine kleinere Menge (Definition einer Hashfunktion) ohne Kollisionen abzubilden ist nicht möglich.

Du hast also irgendetwas erfunden, was jedoch keine Hashfunktion ist.

Gruß,

Karlito

---

Geschrieben von Genie am 07.08.2014 um 21:28:

 

Könnte man meinen Algorithmus irgendwie vermarkten. Man könnte den doch für digitale Signaturen verwenden oder zur Verschlüsselung von Dokumenten.
Der Algorithmus kann definitiv ein Dokument in einen Zahl mit einer rießigen Anzahl von Stellen verwandeln.

---

Geschrieben von Karlito am 07.08.2014 um 22:47:

 

Ich glaube nicht. Mit solch grundlegenden Dingen beschäftigen sich so viele kluge Leute, dass ich bezweifle, dass dir da etwas Bahnbrechendes gelungen ist. Das heißt nicht, dass Du aufgeben solltest, aber offensichtlich musst du deine Kenntnisse stark vertiefen.

Gruß,

Karlito

---

Geschrieben von Genie am 10.08.2014 um 16:00:

 

Hallo Karlito,

Jetzt hätte ich eine Idee wozu man den Algorithmus verwenden kann. Wenn man nur einen bestimmten Logarithmus dieser gewonnenen Zahl abspeichert könnte man damit Daten komprimieren.

Was ist deine Meinung dazu?

---

Geschrieben von eulerscheZahl am 10.08.2014 um 18:44:

 

Kannst du die Daten denn auch wieder dekomprimieren?
Bei Hashes - zumindest im Kryptobereich - soll ja genau das nicht gehen.

---

Geschrieben von Genie am 10.08.2014 um 19:04:

 

Die Datei kann man ohne weiteres wieder dekomprimieren, so dass die alte Datei wieder vollständig dasteht. Ich weis nur nicht ob es ein Problem darstellt dass die zu logarithmierende Zahl mehrere millionen stellen hat.

Ich habe schon ein kleines Programm geschrieben, der ULLONG_MAX ist aber die Grenze dass sind vl 30 Zeichen, also 30 Byte, die man komprimieren kann auf 8 Byte

---

Geschrieben von eulerscheZahl am 10.08.2014 um 19:18:

 

Ich fasse mal zusammen, was ich verstanden habe:
Du kannst aus 30 Byte 8 Byte machen - und zwar als eindeutige Zuordnung.
Für 30 Byte gibt es aber 256^30 verschiedene Möglichkeiten, für 8 Byte nur 256^8. Das kann gar nicht funktionieren.
Kompressionsprogramme arbeiten so, dass sie Zeichen umkodieren. z.B. kommt der Buchstabe 'e' in Texten häufig vor, da wäre es also ratsam, keine 8 Bit zu verwenden, sondern nur 3 oder 4. Bei kaum verwendeten Sonderzeichen kann man dagegen auch mal mehr als 8 Bit spendieren. Wenn du aber einen Film mit zip/rar/tar.gz/7zip/... komprimieren willst, wird die Datei nicht kleiner werden - die Bitfolge ist einfach zu unregelmäßig, um da etwas optimieren zu können.

---

Geschrieben von Genie am 10.08.2014 um 19:39:

 

Mann muss ja die zahl die 8byte hat wieder exponieren dann ergibt sich wieder die Hauptzahl. Die Hauptzahl (ULLONG_MAX-Grenze) entspricht dem String mit 30Byte und aus dieser Hauptzahl wird das Gesamte Dokument zurückberechnet. auf jeden fall funktionierts. Ich kann zwar kein größeres Dokument komprimieren da ich nicht weis wie man über die ULLONG_MAX Grenze kommt aber kleinen Strings funktionierts. Mein Algorithmus macht aus einem Dokument nur eine einzige Zahl, die dann abgespeichert wird.

---

Geschrieben von eulerscheZahl am 11.08.2014 um 06:55:

 

Ok, versuche mal folgendes:
Du zerlegst die gesamte zu komprimierende Datei im Gruppen von je 30 Byte, komprimierst die alle einzeln auf 8 Byte. Das kannst du auch gerne rekursiv machen, also das komprimierte nochmal komprimieren, bis du am Ende eine Datei von 8 Byte hast.
Spiele damit ein wenig herum, komprimiere einige Dateien und versuche, daraus wieder den originalen Inhalt wiederherzustellen. Dann wirst du schon merken, dass das nicht funktioniert. Mit 30 Byte kannst du eben einfach mehr Informationen speichern, als mit 8, daran ist nicht zu rütteln.