Hallo!

Ich lese gerade einige Dinge über Kryptografie und Kryptoanalyse und mir stellt sich eine Frage:

In allen Beiträgen, die ich bisher gefunden habe, ist das Vorgehen des Kryptoanalytikers, also desjenigen, der eine Verschlüsselung brechen will, daß er bestimmte Voraussetzungen für seine Versuche annimmt.
Zum Beispiel:
- Es handelt sich um einen verschlüsselten Text
- Der Text ist in der Sprache xyz verfaßt
- Es handelt sich wahrscheinlich um die Verschlüsselung abc
- usw.
Von diesen Annahmen ausgehend folgen dann z.B. Häufigkeitsanalyse und weitere Schritte.
Wenn keinerlei solche Annahmen gemacht werden können, bleibt wohl nur Brute Force übrig (Voraussetzung: der Verschlüsselungsalgorithmus ist bekannt).

Bei Brute Force (und nun kommen wir endlich zur Frage) werden mögliche Schlüssel eingesetzt und das "entschlüsselte" Ergebnis auf Richtigkeit geprüft. Das ist bei einem Text bestimmt möglich, aber wenn die Klartextinformation keine erkennbaren Muster beinhaltet, wie würde ein Brute Force Angriff denn feststellen, daß ein geprüfter Schlüssel der richtige ist?

Einfaches Beispiel: Klartextinformation (z.B. Text) wird zuerst komprimiert (z.B. gezippt), was jegliche Redundanzen entfernt, danach verschlüsselt.

Wie könnte jemals ein Brute Force Angriff den richtigen Schlüssel finden?

Oder mache ich hier Denkfehler?

Danke!
Holger

Nein, das ist kein Denkfehler.

Deshalb werden oft zufällige Sessionkeys zur Verschlüsselung der eigentlichen Nachricht verwendet. Nur der Sessionkey wird dann mit dem eigentlichen Schlüssel verschlüsselt und weitergegeben.

Da der Sessionkey zufällig ist und nur einmal verwendet wird, hat der Angreifer selbst dann keine Möglichkeit, Rückschlüsse auf den eigentlichen Schlüssel zu ziehen, wenn es ihm gelingt, einen ihm bekannten Text verschlüsseln zu lassen.

Hallo,

@wdbee: Aber das hieße ja, daß jede Verschlüsselung, die normalerweise nur mit Brute Force zu brechen ist, 100% sicher wäre, wenn man nur dafür sorgt, daß die zu verschlüsselnden Daten ausreichend zufällig sind (also z.B. komprimiert)?
Das würde doch jede weitere Diskussion über nicht zuverlässige Verschlüsselungen erübrigen.

Also konkret: Wenn ich meinen "Text" erst komprimieren und dann z.B. mit AES verschlüsseln würde, könnte das niemals geknackt werden. Im Moment habe ich meine Probleme, das zu glauben

Holger

Es gibt da das Kerckhoffsche Prinzip. Das besagt, dass die Sicherheit eines Verschlüsselungsverfahrens nur auf der Geheimhaltung des Schlüssels basieren sollte, nicht auf der Geheimhaltung des Verfahrens. Wenn das Verfahren also darin besteht, den Text erst zu zippen und dann (wie auch immer) zu verschlüsseln, mag das auf den ersten Blick etwas sicherer sein.
Wenn man aber weiß, das der Text erst gezippt und dann verschlüsselt wurde, sucht man halt per Brute-Force nach einem gültigen Zip-File, welches entpackt einen sinnvollen Text ergibt. Ich denke also, dass du einen Denkfehler machst

Zur Häufigkeitsanalyse: Es ist afaik durchaus gängige Praxis (gewesen), bei Translationsverfahren Rechtschreibfehler und Zusatzbuchstaben in den Klartext einzufügen, damit z.B. der Angriff über Häufigkeitsanalysen unwirksam wird.

Bei modernen Verfahren wie RSA bringt eine Häufigkeitsanalyse dagegen gar nichts. Da liegen die Angriffspunkte darin, aus dem Public-Key (den jeder kennt, und mit dem verschlüsselt wird) den Private-Key (der zum Entschlüsseln benötigt wird) zu ermitteln. Im Falle von RSA läuft das auf die Priomfaktorzerlegung einer riesigen Zahl hinaus. Wenn die Primzahlen zu Beginn "schlecht gewählt wurden", kann man mit geeigneten Methoden die Zahl u.U. leichter faktorisieren.

Hallo,

@Gausi: Richtig, das Kerckhoffsche Prinzip. Das sollte der Denkfehler sein

Aber mal einen Schritt weitergedacht: Was kümmert mich das Kerckhoffsche Prinzip, wenn ich nur darauf aus bin, wichtige Daten so zu verschlüsseln, daß niemand sie ermitteln kann? Wenn das Ziel also nicht ist, den allertollsten Verschlüsselungsalgorithmus für jedermann zu basteln, sondern nur die Datensicherheit? Wo keine Anhaltspunkte sind, wegen fehlendem Wissen um den Algorithmus, da kann der "Codebrecher" doch endlos suchen...

Holger

Ein ZIP-Archiv hat eine bekannte Struktur und liefert dem Angreifer damit Hinweise, die er bei der Kryptoanalyse auswerten kann.

Ein Sessionkey ist ein rein zufälliger Schlüssel. Hier hat der Angreifer keinen Anhaltspunkt.
Verschiedene Nachrichten werden mit verschiedenen Sessionkeys verschlüsselt. Damit kann auch aus einer bekannten Nachricht nicht auf den eigentlichen Schlüssel geschlossen werden, mit dem die Sessionkeys verschlüsselt werden.

Natürlich kannst du dir irgendein tolles Verfahren ausdenken, wie du deine Daten verschlüsselst. Du kannst dir z.B. deine Texte von einem Navajo-Indianer übersetzen lassen (das wurde im zweiten Weltkrieg gemacht - der Code wurde nicht geknackt). Das Problem ist, dass dein Verfahren evtl. komplett für die Katz ist, wenn dein böser Nachbar mitbekommt, dass du häufiger mit jemandem die Friedenspfeife rauchst...
Wenn du aber ein Verfahren verwendest, dass dem Kerkhoff gefällt, dann darf dein Nachbar das Verfahren ruhig kennen, nur darf er den Schlüssel nicht bekommen. Wenn man dann Sessionkeys verwendet (keine Ahnung, was das ist, und wofür die verwendet werden, aber das kann wdbee bestimmt näher erläutern), dann hat der Nachbar keine Chance...

Mal angenommen, du musst Personaldaten verschlüsseln und es ist (z.B. wegen des Betriebsrates) bekannt, welche Daten in einem solchen verschlüsselten Paket enthalten sind. Dann kennt jeder Mitarbeiter für den eigenen Fall beides, den unverschlüsselten Inhalt und den verschlüsselten Datensatz.

Würde man alle Datensätze mit demselben Schlüssel verschlüsseln, wäre dieser schon kompromitiert, denn es könnte durch die Kryptoanalyse auf den Schlüssel geschlossen werden.

Deshalb wird jeder Datensatz mit einem eigenen rein zufällig generierten Schlüssel verschlüsselt.
Damit man dann den Datensatz auch wieder entschlüsseln kann, muss der generierte Schlüssel aufgehoben werden.
Dazu wird der dann mit dem eigentlichen Schlüssel verschlüsselt und abgelegt.

Da die Sessionkeys kurz und tatsächlich relativ zufällig sind, reicht die verfügbare Datenmenge in der Praxis nicht aus, um mit statistischen Verfahren auf den eigentlichen Schlüssel schließen zu können.

Es gibt tatsächlich absolut sichere Verfahren. Oder anders ausgedrückt: Es gibt Schlüssel, die von Natur aus nicht geknackt werden können.

Hier ein Beispiel für einen "absolut sicheren Schlüssel":
Person A und B vereinbaren geheim einen beliebig langen Zufallsschlüssel. Ich setze nun voraus, dass es den beiden Personen gelingt, den Schlüssel geheim zu halten. (Das wird ja bei jeder Überlegung vorausgesetzt. Und nur unter dieser Voraussetzung ist der Schlüssel absolut sicher).

Wenn Person A nun z.B. einen Text über eine unsichere Stecke an Person B versenden will, so verrechnet sie jeweils ein Zeichen des Textes mit einem unterschiedlichen Zeichen des Schüssels. Der Schlüssel sollte also mindestens die Länge des Textes haben.
Person B nimmt nun den empfangenen Text und kehrt die Verrechnung mit dem Schlüssel Zeichen für Zeichen um. Dadurch erhält sie den Ausgangstext.

Den Text können ausschließlich Personen lesen, die über den langen Schlüssel verfügen. Sonst niemand, auch kein Brute-Force-Angreifer.

Nennt sich OneTimePad (siehe Wiki)

Vorteil: Ja, es ist 100% sicher (vorrausgesetzt Schlüssel ist geheim geblieben)
Nachteil: Wenn man 1 TB an Daten transferieren will, brauch man 1 TB an Schlüssel. Generier mal ne 1 Milliarden Zeichen lange Zufallsfolge aus 0en und 1en

MfG

Hallo,

Sorry dass ich einen soo alten Thread wieder aus der Versenkung hole, aber über genau dem Problem sitze ich grade auch.

Ich hab mal irgendwo gehört, dass eine Verschlüsselung nur sicher ist, wenn ein Informationsverlust stattfindet. Wenn also durch die Verschlüsselung die Daten größer werden, ist die Verschlüsselung "schlecht". Warum?

Außerdem hab ich eine (sehr) einfache Verschl. mit Passwort und Keyfile entwickelt. Es wird also aus 3 Datenmengen(Passwort,Keyfile,Daten) eine (Ausgabedaten) gemacht. Dabei sind Passwort und Keyfile mit Algorithmen verbunden, da der Passwort-Hash das Keyfile zur Berechnung mit einbezieht. Wie ist diese Technik zu bewerten?

Grüße,
Martok

Nichts zu deiner Technik, aber was den Informationsverlust betrifft: Der Hash einer 1 MB großen Datei ist wie groß? weniger als ein KB oder? Kenn mich mit Hashs nich aus. Haben die nich ne feste Größe? Nun was ich sagen will: Du kommst vom Hash nicht mehr WIRKLICH auf die Originaldatei, weil Daten verloren gegangen sind. Es gibt mehrere Dateien, die 1 MB groß sind, die den selben Hash erzeugen! (oder? ) Also kannst du nicht sicher sagen: Die Datei, die ich eben erzeugt hab, liefert den selben Hash, also ist es eine exakte Kopie der Originaldatei.

Martok hat folgendes geschrieben:

Wie ist diese Technik zu bewerten?

Hallo Martok!

Das hängt ganz davon ab, welche Technik (Verfahren) du verwendest. Mit einem geeigneten Verfahren kann durch die Verrechnung dreier Daten nach meiner Einschätzung sehr sicher sein.
Um dein Verfahren beurteilen zu können, fehlen aber weitere Informationen.

Gruß, Aristoteles

Kompromitierung durch Komprimierung geht nicht..
Ich empfehle dazu folgende Lektüre:

Beutelspacher, Albrecht
Kryptologie
ISi: 3-8348-0014-7