Ansatz zur bruteforce-sicheren verschlüsselung

Hey, habe mir in letzter Zeit mal gedanken über Verschlüsslungen gemacht, das kam dabei raus:

1. Text verschleiern: 40 4-stellige zufallszahlen generieren, in keyfile schreiben
1.1. Für jede Zahl folgendes machen: Bsp: Zahl = 1824
Jeder 18. Buchstabe wird Mit jedem 24. getauscht.

2. Text verschlüsseln: Für jeden Buchstaben einzeln einen Key generieren
in keyfile schreiben, und weitermachen (Beispielsweise das Enigma verfahren
nutzen

So müsste ich ja, wenn ich in der Verschlüsselung alle Kleinbuchstaben und Zahlen erlaube (24+10)^Buchstabenanzahl möglichkeiten bekommen, bei denen alle einen Text zurückgeben, was heißt, ich müsste entweder nach Schlüsselwörtern in diesen Texten suchen, oder statistisch analysieren.
Da aber mein Originaltext unleserlich ist, dürfte ja beides fehlschlagen.

Wäre das ein Ansatz zur unbruteforcebaren verschlüsselung ?
 
Nicht wenn man das vermutet und deine Zufallszahlen auch bruteforcet oder?
 
1) und 2) gehören zusammen?
Wie würde dann der verschlüsselte Text aussehen?

Bsp:
unser erlaubtes Alphabet: {a, b, c}
generiere für jeden Buchtstaben eine 4 stellige Zahl:
a = 1000, b = 1001, c = 1002
(wann kommt der "Tausch"?)

Verschlüsselung:
Klartext: aabc
verschlüsselt: 1000 1000 1001 1002 ?

Bis dahin wäre es eine simple Substitution.

PS: "unbruteforcebar" gibt es nicht. Eher versucht man bei der Entwicklung (bzw. ist die Standardanforderung an den Algo), dass BF der einzige mögliche Angriff ist ;)
 
@CDW

Nein, du hast 1 missverstanden, im ersten Schritt wird der Ursprungstext so unleserlich gemacht, das man zum Beispiel ei der Such nach Schlüsselwörter im geknackten text nichts findet. 1. Funktioniert so:

- Ich generiere eine 4-stellige zahl (z.b. 1264)
- Ich zerteile diese Zahl 12|64
- Jetzt vertausche ich im Text den Buchstaben an Stelle 12 mit dem an Stelle 64.
- Das wiederhohle ich beliebig. (im anfangspost 40 mal [mit verschiedenen Zahlen])

@benediktbk
Die Tatsache, dass ich dann 34^Buchstabenanzahl*10000 möglichkeiten habe.
 
Zuletzt bearbeitet:
Und wie funktioniert dann die Entschlüsselung? Da wäre doch die Reihenfolge der generierten Zahlen wichtig.

D.h um das Beispiel anzupassen:
Klartext: aabc
unser erlaubtes Alphabet: {a, b, c}

generiere für jeden Buchtstaben eine 4 stellige Zahl:
a = 0103,
Text: baac
b = 0204,
Text: bcaa
c = 0104
Text: acab
Verschlüsselter Text:
acab =>
0103 0104 0103 0204

Entschlüsselung:
lese Keyfile "rückwärts" und vertausche, dann ersetze?

Wenn nicht, dann bitte doch ein bisschen mehr ins Detail gehen - schließlich möchtest Du andere Antworten als Kurze Chiffretexte knacken - Warum dein Bytestring für den Arsch ist haben ;)

Bis jetzt sehe ich immer noch haufenweise Angriffsmöglichkeiten, ganz abseits vom BF ;)

Angriff 1:
wenn der Text länger als 100 Buchstaben ist => Häufigkeitsanalyse auf den Rest, lesen *g*
Angriff 2: der übliche auf mono-substitution, jetzt hat man einen "Zahlensalat". Bleiben wir bei den 40 vierstelligen Zahlen:
jede Zahl kodiert eine Tauschoperation. Erstmal sehe ich hier nichts von 40^Buchstabenanzahl, sondern "nur" eine 40! (Fakultät), also schon mal deutlich kleiner als 40^40 ;)
Und das lässt sich imho weiterhin stark reduzieren.
 
Ja, der erste Schritt ist das Obfuscaten und diese Zahlen im Keyfile speichern, der 2. Schritt wäre mit einem Algo, wie z.b. dem Enigma alge jetzt wieder mit einem zufälligen schlüssel der auch ins keyfile kommt jeden einzelnen Buchstaben verschlüsseln. Das obfuscaten, um beim Brute-Force auf die Enigma verschlüsselung die Erkennung des richtigen Textes anhand von Schlüsselwörtern zu erschweren.
 
2. Text verschlüsseln: Für jeden Buchstaben einzeln einen Key generieren
in keyfile schreiben, und weitermachen (Beispielsweise das Enigma verfahren nutzen

Wenn du für jeden Buchstaben einen eigenen Key generierst, bist du in der Tat beim One Time Pad. Das ist das einzige Verschlüsselungsverfahren auf der Welt, von dem mathematisch bewiesen ist, dass es perfekte Sicherheit bietet.
Problem daran ist nur, dass es höchst unpraktikabel ist, weil der Schlüssel eben die gleiche Länge hat wie der Klartext.
Oder verstehe ich das immernoch falsch?

Die Enigma hat das Team Alan Turings übrigens schon vor 70 Jahren geknackt.
 
Moin

Nein

Es gibt kein Verfahren, das sich nicht per BruteForce knacken läßt.

Es gibt nur ein Verfahren, das durch BF alleine, nicht gebrochen werden kann (OTP).

Sentrax

Hö, doch klar, jedes Verfahren kann durch Bruteforce gebrochen werden. Das ist der Witz an dem Angriff: Funktioniert immer und ist grundsätzlich worst-case - Suche den ganzen Schlüsselraum ab.
 
Es gibt in der Kryptographie den Begriff der perfekten Sicherheit / der informationstheoretische Sicherheit.

Diese garantiert, dass ich aus dem Geheimtext keine Informationen über den Klartext ziehen kann, da die Verteilung der Geheimtexte stochastisch unabhänig von der Nachricht ist.

Shannon hat gezeigt, dass für jedes informationstheoretisch sichere Verfahren es gelten muss, dass die Schlüsselmenge mindestens so groß ist wie die Nachrichtenmenge. Ebenso hat er gezeigt, dass das One-Time-Pad entsprechend informationstheoretisch sicher ist.

Allerdings sind Verfahren wo der Schlüssel genauso groß ist wie die späteren Nachrichten sehr unpraktikabel: Möchte man eine 4 GB DVD verschlüsseln, dann müsste der Key ebenfalls mindestens 4 GB sein. Nicht so toll.


Es folgt dass für alle anderen Verfahren wo der Key kürzer ist als die Nachrichten, dass diese keine informationstheoretische Sicherheit erreichen können und somit auch per Brute Force angegriffen werden können.


@5830: Dein erster Schritt war bereits bei der Enigma auch so (bzw. sehr ähnlich) implementiert. Dort wurden über das Eingabeboard Buchstaben vertauscht. Hat man dort ein 'A' eingegeben, wurde dann an die Walzen z.B. ein 'T' zum Verschlüssel geschickt. Genutzt hat es nichts.

Denn bei dem Vertauschen in deinem 1. Schritt gibt es weiterhin einige Probleme:
1) Buchstabenhäufigkeiten bleiben erhalten. Dass heißt ich kann sehr wohl im 2. Schritt überprüfen ob ich richtig geraten habe indem ich schaue ob die Buchstabenhäufigkeit des Ergebnis mit der Buchstabenhäufigkeit der entsprechenden Sprache (Deutsch/Englisch...) übereinstimmt.

Ein weitere Problem:
Du generiert 4 stellige Zahlen, damit dürfen deine Nachrichten maximal 100 Zeichen lang sein. Nicht gerade pratikabel.
 
Zuletzt bearbeitet:
wobei OTP verfahren natürlich nach wie vor verwendung finden

natürlich ist es schlichtweg unpraktikabel - aber darauf kommt es in gewissen szenarien auch gar nicht an. beispielsweise könnte man auf sicherem weg einen datenträger mit dem OTP key zum empfänger transportieren und daraufhin (sofern dies gelungen ist) die eigentliche botschaft, mit diesem key verschlüsselt übertragen (diese übertragung müsste dann halt nichtmal mehr geheim sein)

sofern kein eindringen auf sender oder empfänger seite möglich ist, sondern lediglich ein abfangen, garantiert dies eine sichere übermittlung
 
Zuletzt bearbeitet:
Du generiert 4 stellige Zahlen, damit dürfen deine Nachrichten maximal 100 Zeichen lang sein. Nicht gerade pratikabel.
Zwei zwei-stellige, und die Erweiterung auf beliebig lange Texte ist offensichtlich. Das Verfahren hat ganz andere Probleme :)
 
Zurück
Oben