Macht nicht ganz einfach eine doppelte Verschlüsselung einen Brute Force Angriff komplett nutzlos?
Bei einem Brute Force Angriff muss die Angreifersoftware doch irgendwie feststellen ob mit dem Schlüssel etwas sinnvolles entschlüsselt wird. Verschlüsselt man doppelt kann die Angreifersoftware das doch gar nicht mehr leisten oder? Wer kennt sich aus?
5 Antworten
Es gibt nur dann eine praktische Sicherheitssteigerung, wenn beide Verschlüsselungsalgorithmen für sich genommen unabhängig voneinander für eine umfassende Suche anfällig wären, d. H. Durch Verwendung eines zu kleinen Schlüssels. Das wäre das Hauptproblem, und es ist besser das zu beheben.
Es gibt gute Gründe, warum ein 128-Bit-Schlüssel solchen Versuchen widerstehen würde. Wenn du also einen anständigen Verschlüsselungsalgorithmus verwendest, müsstest du ihn nicht "verdoppeln".
In früheren Zeiten wurden Verdopplungs- oder Verdreifachungsalgorithmen verwendet, um frühere Algorithmen wiederzuverwenden, die für sich genommen definitiv zu schwach waren.
Das beste Beispiel ist Triple-DES (3DES), das über dem vorherigen DES aufgebaut ist. DES und sein 56-Bit-Schlüsselraum sind anfällig für eine umfassende Suche. Das verdoppeln wäre das Geld nicht wert: double-DES würde einen 112-bit-Schlüssel verwenden, aber keine 112-Bit-Sicherheit bieten.
Kurz gesagt, für Double-DES würde der Angreifer den bekannten Klartext mit dem ersten DES und allen möglichen Schlüsseln s1 (2^56 Möglichkeiten) verschlüsseln und auch den bekannten Chiffretext mit allen möglichen Schlüsseln s2 (erneut 2^56 Möglichkeiten) entschlüsseln und dann nachsehen ob es eine Übereinstimmung in den beiden Sätzen von 2^56 "Zwischenwerten" gibt. Übereinstimmungen kosten ungefähr 2 · 56 · 2^56, d. H. Ungefähr 2^63 (das sind die Kosten für das Sortieren der beiden Sätze, so dass Übereinstimmungen bei einer linearen Suche erkannt werden). Bei einer Zusammenführungssortierung erfordern die Sortier- und Übereinstimmungsschritte nur einen linearen Zugriff und sind daher mit Festplatten kompatibel. Wir sprechen hier von 2^57 128-Bit-Werten (zwei bekannte Klartextblöcke, damit die Schlüssel nicht mehrdeutig sind), auch bekannt als 2^61 Bytes, also 2 Millionen Terabyte.
Eine Million Festplatten sind teuer ... aber im Gegensatz zu einer umfassenden Schlüsselsuche nach 2^112 technisch machbar.
Daher bringen Verdopplungsalgorithmen keinen so großen Vorteil. Das Verdreifachen erhöht die Sicherheit, wenn mit schwachen Algorithmen begonnen wird (zumindest wenn die Schwäche nur die Schlüsselgröße betrifft), aber auch hier nicht so viel wie der investierte Aufwand (mit 3DES haben Sie 168 Schlüsselbits, aber der Widerstand ist "nur"). bis 2^112). Verdreifachen bedeutet natürlich auch, die Leistung durch drei zu teilen, was in einem bestimmten Kontext tolerierbar sein kann oder nicht. Durch Verdreifachen, Vervierfachen ... werden andere Probleme nicht behoben, z. B. zu kleine Blöcke (3DES verwendet weiterhin die 64-Bit-DES-Blöcke, was bedeutet, dass beim Verschlüsseln von Daten im Wert von 2^32 Blöcken mit einem bestimmten Schlüssel schwerwiegende Probleme auftreten. dh ungefähr 32 Gigabyte, was nach heutigen Maßstäben nicht viel ist).
Es ist viel besser, mit einem Verschlüsselungsalgorithmus (wie AES) zu beginnen, der zunächst keine umfassenden Suchprobleme aufweist und das Verdoppeln oder Verdreifachen nicht nötig macht.
kurz gesagt, nein das funktioniert nicht so bei den gängigen Verschlüsseungstechniken, es ist eher Schlüssel und Schloss prinzip.
Aber es gibt die XOR Verschlüsselung, da würde es durchaus möglich sein und vermutlich geht deine Rechnung auf. Aber bei XOR muss man einiges beachten damit es sicher bleibt, was das ganze extrem unpraktikabel macht...
ergo, der beste Schutz dagegen ist ein starker Algorithmus und ein starkes Passwort
O. k., kann man so sehen. Ich habe es eher als logische Verknüpfung gesehen, aber man kann damit auch verschlüsseln.
Das Stromchiffreverfahren RC4 basiert meines Wissens auch auf der XOR-Verknüpfung.
ja aber das passwort muss genau so lange sein wie der zu verschlüsselte Inhalt, also eher für kürzere Texte
Wenn bei passendem Schlüssel aber nur Kauderwelsch herauskommt, ist es schwierig zu erkennen, dass der Schlüssel passt.
doch, wenn der Schlüssel passt in das entschlüsselte Kaudelwelsch auch korrekt.
wenn du einen falschen Schlüssel bei der Verschlüsselung(zB AES) verwendest kann nichts entschlüsselt werden. nur ein korrekter Schlüssel liefert ein Entschlüsselungsergebnis.
ja aber das passwort
Nein. Es geht nicht um ein Passwort. Bei einem Stromchiffre hast Du einen Schlüsselstrom. Der wird kontinuierlich generiert. RC4 haben wir lange bei WEP, WPA und WPA2 sowie auch bei SSL und TLS verwendet.
nur ein korrekter Schlüssel liefert ein Entschlüsselungsergebnis.
Wie erkennst Du, dass eine Zeichenfolge ein Entschlüsselungsergebnis ist oder nicht? Ver- und Entschlüsselung ist pure Mathematik. Wenn ich den Text "1234567890" mit dem Schlüssel "ABC" verschlüssele, kann ich den Chiffretext auch mit dem Schlüssel "DEF" entschlüsseln. Es kommt halt nur nicht der Originaltext heraus. Aber wie unterscheidet der Angreifer das?
Übrigens funktioniert 3DES genau so: Verschlüsseln mit Schlüssel 1, entschlüsselm mit Schlüssel 2, verschlüsseln mit Schlüssel 1 oder 3.
Wie erkennst Du, dass eine Zeichenfolge ein Entschlüsselungsergebnis ist oder nicht?
ich garnicht, aber die Verschlüsselung. Zumindest bei den gängigen wie AES gibt es einen Schlüsselprüfwert der auch verschlüsselt wird. beim entschlüsselt wird also gleich erkannt ob es der richtige key war und daher der restliche Inhalt nur bei einem richtigen key entschlüsselt.
wenn ich also in meiner Anwendung etwas entschlüssel muss, dann muss die Anwendung das Ergebnis nicht extra auf Richtigkeit prüfen,also ob es korrekt entschlüsselt wurde, ich muss mich nicht damit aussernandersetzten ob jetzt der Entschlüsselte Inhalt ein jpg ist oder ein pfd oder ein comipielierter Programmcode, oder sonstwas, mir ist das alles egal...
die Verschlüsselungsimplementierung übernimmt dies alles durch den Schlüsselprüfwert. Stell Dir vor was passieren würde wenn man versucht mit einem falschen PW eine 100GB Datei zu entschlüsseln, man müsste lange warten bevor man dann nochmal das PW eingibt... aber die Entschlüsselung liefert hier sofort ein Fehlermeldung.
Im Prinzip richtig gedacht und wird auch praktiziert, z.B. serpent-aes oder twofish-aes.
Im Prinzip erkenne ich eine erfolgreiche Schlüsselsuche dann nur noch für den Fall, daß beide Schlüssel gefunden wurden. Die Kombination hat noch einen Vorteil ggü. einer Verlängerung des Schlüssel, höhere Robustheit ggü. Schwächen im Algorithmus.
Nicht zuletzt, weil Schwächungen eben nicht absolut sondern oft relativ sind.
was meinst du mit doppelt . erst das eine verfahren und dann das andere verfahren .
aber das problem ist schon wenn du das selbe verfahren mehrmals anwendest .
aber zum ziel .
du nimmst ja nicht irgendeine datei und brute forced den inhalt . sondern du hast eine datei und weißt mindestens was irgendwie rauskommen muss . sonst ist nämlich sichtkontrolle angesagt und das wird ewig dauern :) textdatei bleibt textdatei :) musste jede prüfen .
ergo wenn du automatisiert irgendwas entschlüsseln willst, brauchst du mindestens etwas equivalentes um zu testen ob du schon was brauchbares gefunden hast .
genau so hat es turing auch bei der enigma gemacht.
Ja genau, wenn man zweimal verschlüsselt kommt ja beim ersten Brute Fore nichts sinnvolles raus und da kann man sogar zweimal mit demselben Algorithmus und Passwort verschlüsseln und das alleine würde schon helfen. Allerdings könnte einer dann einen Doppelbruteforce Angriff starten und deshalb sollte man wohl eher zwei verschiedene Algorithmen und Passwörter verwenden.
machen kann jeder alles , es geht hier aber um knacken
und bruteforce ist wirklich , das letzte mittel , die aktuellen korrekten verschlüsselungen wirste auch mit bruteforce nicht schaffen .
Du hast das nicht zu Ende gedacht ;) Wenn ich etwas schon verschlüsseltes noch einmal verschlüssle, dann bekommt das Programm nicht direkt nach dem Entschlüsseln irgend einen Datenwust. Die für die Verschlüsselung verwendete Berechnung der ersten Verschlüsselung würde zuerst aufgehen, also weiß ein Programm, dass die Entschlüsselung erfolgreich war. Das weiß auch ein Brute-Force-Programm. Woher sollte sonst ein Programm, das berechtigt versucht, den Inhalt zu entschlüsseln wissen, dass z.B. dein Passwort richtig war?
Eine doppelte Verschlüsselung würde einen Brute Force Angriff nur verlängern, weil das Prozedere zwei mal laufen muss.
ohne inhalt zu kennen weiss man eh nicht ob irgendwas ein erfolg hatte . sonst hätte turing das einfacher gehabt :) aber auch er suchte nach logisch vorkommenden wörtern/mustern in den nachrichten und erst dann brute force .
Das ist richtig. Deswegen haben ja viele verschlüsselte Dateiformate entsprechende Marker, mit denen das Programm selbst weiß, dass es richtig entschlüsselt hat. Wäre ziemlich nervig, wenn 7zip jedes Mal versuchen würde, eine Datei mit dem falschen Hash komplett zu entpacken und dann nur Gobbledigook rauskäme.
Ein Indikator kann ja schon ein bloßes Dateiformat sein.
Bei Text wäre ja das bloße Vorhandensein von echten Wörtern aus einem Wörterbuch eine Referenz.
Wenn wir von Dateien ausgehen, die nicht komplett verschlüsselt sind (also ein Dateiformat und -Attribute haben) ist es für den Bruteforcer ja sehr leicht, zu erkennen, wenn etwas entschlüsselt ist. Eine doppelte Verschlüsselung ändert da dran nicht viel. Die liegen ja über einander, dementsprechend reicht es, wenn z.B. das "Last Edited" Attribut der Datei auf einmal ein Datum wird, weil das ja nur mit der 2. Verschlüsselung erfasst wurde, nachdem die Datei ja vorher so nicht existiert hat.
Dementsprechend macht eine 2. Verschlüsselung Brute Forcer nicht nutzlos.
In der Theorie und bei reinem Text ohne alles ja, in der Praxis nein.
Mal davon abgesehen, dass ein Bruteforcer sowieso keine Freude macht bei ner AES-Verschlüsselung.
Warum weiß das Programm das? Man könnte sehr einfach ein Programm entwickeln das vollkommen auf solche Schlüsselerkennungsmechanismen, die angreifbar sind, verzichtet und schon hat man eine Verschlüsselung die 100% sicher ist, denn dann weiß auch das Brute Force Programm schlicht nicht mehr ob ein Schlüssel richtig oder falsch ist, mit dem falschen Schlüssel würde man dann schlicht nur Unsinn entschlüsseln und ggf. die Datei zerstören wenn sie überschrieben wird. Ich frage mich nur warum das niemand macht, es ist doch einfach.
Ein Programm basteln, das alle Hinweise auf Format, alle Dateiattribute, etc. entfernt und dann 2x verschlüsselt?
Klar könnte man, gibt's bestimmt auch an der einen oder anderen Ecke.
Du überschätzt aber die Bedeutung von Brute Force Attacken. Die sind schon lange lange lange kein effektives Mittel mehr. Bei einer AES256 Verschlüsselung muss ein Bruteforcer 256Bit lange Hashes exakt rauskriegen. Das dauert einfach viel zu lange, selbst wenn man eine Referenz hat, an der man erkennt, dass man erfolgreich war. Der überwiegende Großteil der Daten ist das schlicht nicht wert. Stattdessen versucht man ja, mittels Exploits oder durch das Abfangen von Passwörtern etc. an Daten ran zu kommen. Verschlüsselungen knacken lohnt schon lange nicht mehr.
Wenn bei passendem Schlüssel aber nur Kauderwelsch herauskommt, ist es schwierig zu erkennen, dass der Schlüssel passt.
XOR ist keine Verschlüsselung.