idealer Hash-Algorithmus |
| 06.08.2014, 16:06 | Auf diesen Beitrag antworten » | ||
| Genie | 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 |
||
|
|
|||
| 06.08.2014, 17:46 | Auf diesen Beitrag antworten » | ||
| Julius | 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. |
||
| 06.08.2014, 23:53 | Auf diesen Beitrag antworten » | ||
| ed209 | RE: idealer Hash-Algorithmus
|
||
| 07.08.2014, 14:35 | Auf diesen Beitrag antworten » | ||
| Genie | RE: idealer Hash-Algorithmus Wie könnte man einen idealen Hash-Algorithmus am besten Vermarkten? |
||
| Anzeige | |||
|
|
|||
| 07.08.2014, 15:36 | Auf diesen Beitrag antworten » | ||
| Karlito | Wieso denkst du denn, dass dein Hash-Algo besser ist als all die anderen? Gruß, Karlito |
||
| 07.08.2014, 17:46 | Auf diesen Beitrag antworten » | ||
| Genie | Weil er definitiv kollisionsfrei hasht |
||
| 07.08.2014, 20:18 | Auf diesen Beitrag antworten » | ||
| Karlito | 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 |
||
| 07.08.2014, 21:28 | Auf diesen Beitrag antworten » | ||
| Genie | 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. |
||
| 07.08.2014, 22:47 | Auf diesen Beitrag antworten » | ||
| Karlito | 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 |
||
| 10.08.2014, 16:00 | Auf diesen Beitrag antworten » | ||
| Genie | 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? |
||
| 10.08.2014, 18:44 | Auf diesen Beitrag antworten » | ||
| eulerscheZahl | Kannst du die Daten denn auch wieder dekomprimieren? Bei Hashes - zumindest im Kryptobereich - soll ja genau das nicht gehen. |
||
| 10.08.2014, 19:04 | Auf diesen Beitrag antworten » | ||
| Genie | 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 |
||
| 10.08.2014, 19:18 | Auf diesen Beitrag antworten » | ||
| eulerscheZahl | 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. |
||
| 10.08.2014, 19:39 | Auf diesen Beitrag antworten » | ||
| Genie | 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. |
||
| 11.08.2014, 06:55 | Auf diesen Beitrag antworten » | ||
| eulerscheZahl | 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. |
||
| 11.08.2014, 16:29 | Auf diesen Beitrag antworten » | ||
| Genie | Hattest recht. Hab einen Überlauf übersehen. jetzt ist die Zahl an bytes genauso groß wie die Zeichenfolge. |
||
|
|
Verwandte Themen
| Die Beliebtesten » |
|
| Die Größten » |
| Die Neuesten » |
