Frage zur Verschlüsselung

[Scien]

Kann man einen Text+Zahlen mit einer länge von sagen wir mal 100 Zeichen in einen alphanummerischen Code von ca. 20 Zeichen verschlüsseln? Ausserdem sollte der Verschlüsselungscode einmalig sein. Es darf also kein identischer Code bei unterschiedlichen Verschlüsselungstexten entstehen. Ist so etwas möglich?

Ich habe keine Ahnung von Kryptographie, daher ist es vielleicht eine komische Frage :confused:

[pruefer_gg]

Verschlüsseln: nein!

Hash: ja!

GG

[Crays]

Du wirst nie etwas verschlüsseln können, was nach der Verschlüsselung kleiner ist, als die Grunddaten.

Einzige Möglichkeit wäre tatsächlich die Bildung eines Hash-Wertes.

Diese haben aber die Eigenschaft, dass man sie nicht wieder ent-hashen kann.

In welchem Anwendungsgebiet willst du das denn einsetzen? Evtl kann man da eher abwägen, was besser wäre?

[Scien]

Du wirst nie etwas verschlüsseln können, was nach der Verschlüsselung kleiner ist, als die Grunddaten.

Einzige Möglichkeit wäre tatsächlich die Bildung eines Hash-Wertes.

Diese haben aber die Eigenschaft, dass man sie nicht wieder ent-hashen kann.

In welchem Anwendungsgebiet willst du das denn einsetzen? Evtl kann man da eher abwägen, was besser wäre?

Was meinst du mit ent-Hashen? Heisst das, dass man über den Hash nicht mehr an die ursprünglichen ungehashten Daten kommt?

[pruefer_gg]

Was meinst du mit ent-Hashen? Heisst das, dass man über den Hash nicht mehr an die ursprünglichen ungehashten Daten kommt?

Ja, meint er.

Hash ist nur eine Prüfsumme und unumkehrbar!

GG

[Fork]

..jedoch crackbar mit Rainbow Tables. Bei 100 Zeichen muss man sich da aber natürlich keine Sorgen mehr machen.

Warum sollte etwas Verschlüsseltes nicht kleiner sein können als das Original?

Macht man sich für die Verschlüsselung eine Liste, in der jede mögliche Kombination für z.b. 5 Zeichen einer Hexadezimalzahl zugeordnet ist, sollte sich die Anzahl der Zeichen doch bereits verringert haben. Oder habe ich gerade einen bösartigen Knick in der Logik?

[pruefer_gg]

..jedoch crackbar mit Rainbow Tables.

Es sei denn, man verwendet "salted-hashes". Dann geht auch das nicht!

Die Frage ist, was will der TO erreichen?!

GG

[Fork]

Salts erhöhen den Aufwand, machen es jedoch nicht unmöglich. Klar, die Tabellen werden gigantisch groß, selbst wenn man nur eine Wordlist für 8 Zeichen lange Strings erstellt, da man dann auch den Hash eines jeden Strings mit jedem möglichen Salt speichern muss. Ich bin mir aber sicher, dass dir bei "password" oder "12345" auch ein Salt keine 10 Sekunden Vorsprung gibt ^^

sry für OT.

[Crays]

Warum sollte etwas Verschlüsseltes nicht kleiner sein können als das Original?

Verschlüsselte Daten haben ja die Angewohnheit, dass man diese wieder entschlüsseln können soll.

D.H.: Es soll in den ursprünglichen Zustand hergestellt werden.

Gehen wir von einem Datum (singular für "Daten") mit 100kByte Größe aus, so sieht dies wie Folgt aus:

100kByte --verschlüsseln--> 100kByte + X --entschlüsseln--> 100kByte

Beim Verschlüsseln kommen also "irgendwelche" Daten hinzu, es wird demnach mehr Platz benötigt.

Auch wenn es hier vielleicht nicht ganz das Einsatzgebiet ist, das "Gesetz von der Erhaltung der Masse" greift auch hier.

Du kannst durch das Hinzufügen von Daten diese Daten nicht verkleinern - falls doch, lass mich bitte per PM wissen, wie das geht. Damit kannst du auch noch für die Enkel deiner Urenkel ein Leben ohne Arbeit ermöglichen

Bearbeitet 17. Mai 2011 von Crays

[Klotzkopp]

..jedoch crackbar mit Rainbow Tables.

Ein solcher Angriff auf einen Hash ist keine Umkehr, sondern das Suchen eines Wertes, das denselben Hash hat.

Um's nochmal klarzustellen: Ein Hash (egal ob mit Salt oder ohne) ist nicht umkehrbar, und ist daher auch keine Verschlüsselung.

Warum sollte etwas Verschlüsseltes nicht kleiner sein können als das Original?

Weil Informationen immer ihren Platz brauchen.

Macht man sich für die Verschlüsselung eine Liste, in der jede mögliche Kombination für z.b. 5 Zeichen einer Hexadezimalzahl zugeordnet ist, sollte sich die Anzahl der Zeichen doch bereits verringert haben.

Dann rechne doch mal aus, wie lang deine Liste ist, und wieviele Bits du brauchst, um eine Listenposition zu speichern. Ich kann es dir verraten: Es sind genau die 20 Bits, die du auch für die ursprünglichen 5 Hex-Ziffern brauchst.

Allenfalls kannst du ausnutzen, dass bestimmte Kombinationen häufiger auftreten, und diese durch kürzere Sequenzen codieren. So arbeiten verlustfreie Komprimierungsalgorithmen.

Oder habe ich gerade einen bösartigen Knick in der Logik?

So sieht's wohl aus.

[Fork]

Ohne das jetzt tatsächlich nachzurechnen glaube ich euch das. Nur eine Frage: Cäsar gilt doch als Verschlüsselung, oder? Afaik wird dort die Datenmenge nicht erhöht.

Und nochmal zurück zur eigentlichen Frage des Threaderstellers: Sind Hashes einmalig? Ich glaube zumindest mal über MD5-Hasches gelesen zu haben dass dort verschiedener Input zum gleichen Hash führen kann.

[Klotzkopp]

Cäsar gilt doch als Verschlüsselung, oder?

Ja.

Afaik wird dort die Datenmenge nicht erhöht.

Muss ja auch nicht.

Sind Hashes einmalig?

Nein. Deswegen kann man sie ja auch nicht umkehren.

[flashpixx]

Sind Hashes einmalig? Ich glaube zumindest mal über MD5-Hasches gelesen zu haben dass dort verschiedener Input zum gleichen Hash führen kann.

Nein Hashes sind nicht einmalig, das nennt sich dann "Kollision". Hashes sind surjektive, aber nicht injektive, Mengenabbildungen, damit ist klar, dass zu einem Hash mehrere Werte existieren können.

[pruefer_gg]

Und nochmal zurück zur eigentlichen Frage des Threaderstellers: Sind Hashes einmalig? Ich glaube zumindest mal über MD5-Hasches gelesen zu haben dass dort verschiedener Input zum gleichen Hash führen kann.

Der ideale Hash ist kollisionsfrei. Der reale Hash sollte kollisionssicher (noch besser: resistent) sein, d.h. man kann die Kollisionen nicht vorher sagen!

GG