7
Verschlüsselung zurück rechnen
Hallo,
ist es allgemein möglich, bei verschlüsselten Daten (insbesondere bei AES) den Code zu errechnen, wenn man den unverschlüsselten und den verschlüsselten Text hat?
Beispiel:
Ausgangstext: Hallo
Code: myCode
Verfahren: AES (ECB)
Ausgabe: f5 81 47 02 d1 4a d1 0f 50 5c 18 61 81 53 44 0a
Jetzt würde mich interessieren, ist es möglich anhand der Daten Ausgangstext, Verfahren und Ausgabe den verwendeten Code zu errechnen?
Und wieso bekomme ich auf http://aes.online-domain-tools.com/ eine hexadezimale Schreibweise als Ausgabe, die als Text ziemlich kryptische Zeichen hat? Würde ich das ganze in Visual Basic verschlüsseln, dann hätte man einen Code der mit == anfängt und nur geläufige Zeichen enthält.
Auf eine Antwort wäre ich euch sehr dankbar,
Chris Aicher
ist es allgemein möglich, bei verschlüsselten Daten (insbesondere bei AES) den Code zu errechnen, wenn man den unverschlüsselten und den verschlüsselten Text hat?
Beispiel:
Ausgangstext: Hallo
Code: myCode
Verfahren: AES (ECB)
Ausgabe: f5 81 47 02 d1 4a d1 0f 50 5c 18 61 81 53 44 0a
Jetzt würde mich interessieren, ist es möglich anhand der Daten Ausgangstext, Verfahren und Ausgabe den verwendeten Code zu errechnen?
Und wieso bekomme ich auf http://aes.online-domain-tools.com/ eine hexadezimale Schreibweise als Ausgabe, die als Text ziemlich kryptische Zeichen hat? Würde ich das ganze in Visual Basic verschlüsseln, dann hätte man einen Code der mit == anfängt und nur geläufige Zeichen enthält.
Auf eine Antwort wäre ich euch sehr dankbar,
Chris Aicher
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 292051
Url: https://administrator.de/forum/verschluesselung-zurueck-rechnen-292051.html
Ausgedruckt am: 22.12.2024 um 15:12 Uhr
7 Kommentare
Neuester Kommentar
Zitat von @Aicher1998:
ist es allgemein möglich, bei verschlüsselten Daten (insbesondere bei AES) den Code zu errechnen, wenn man den unverschlüsselten und den verschlüsselten Text hat?
ist es allgemein möglich, bei verschlüsselten Daten (insbesondere bei AES) den Code zu errechnen, wenn man den unverschlüsselten und den verschlüsselten Text hat?
Moin,
Nein, das geht bis dato mit AES nicht.
https://en.wikipedia.org/wiki/Known-plaintext_attack
VG,
Thomas
Zitat von @Th0mKa:
Moin,
Nein, das geht bis dato mit AES nicht.
https://en.wikipedia.org/wiki/Known-plaintext_attack
Zitat von @Aicher1998:
ist es allgemein möglich, bei verschlüsselten Daten (insbesondere bei AES) den Code zu errechnen, wenn man den unverschlüsselten und den verschlüsselten Text hat?
ist es allgemein möglich, bei verschlüsselten Daten (insbesondere bei AES) den Code zu errechnen, wenn man den unverschlüsselten und den verschlüsselten Text hat?
Moin,
Nein, das geht bis dato mit AES nicht.
https://en.wikipedia.org/wiki/Known-plaintext_attack
Ist es erweisen, dass es nicht geht? Oder vermutet man es?
Oder würde es mit unvorstellbarer Rechenleistung schaffen?
wie schaut es bei anderen Verschlüsselungsmethoden aus? Beim WLAN zum Beispiel?
Zitat von @Aicher1998:
Ist es erweisen, dass es nicht geht? Oder vermutet man es?
Oder würde es mit unvorstellbarer Rechenleistung schaffen?
Wer ist "man"? Bisher hat noch niemand gesagt das er es geschafft haette. Fuer alles weitere zum Thema empfehle ich Nutzung der Suchmaschinen deiner Wahl, selber lesen macht schlau.Ist es erweisen, dass es nicht geht? Oder vermutet man es?
Oder würde es mit unvorstellbarer Rechenleistung schaffen?
VG,
Thomas
Hallo,
das ist eine grundsätzliche Frage zu verschlüsselungssystemen.
Diese sind mathematisch sicher.
Es wurde also mathematisch bewiesen, dass ein zurückrechnen nicht möglich ist.
Es bleiben immer 2 Möglichkeiten.
1) Einfach alle Möglichkeiten der Reihe nach ausprobieren (Brute Force)
2) Nach Schwachstellen bei der Implementierung schauen (immer die gleiche Zufallszahl, etc).
Mit unendlicher Rechenleistung ist jede Verschlüsseung per Brute-Force zu knacken.
Was also heute noch sicher ist, ist es in 10 Jahren vermutlich nicht mehr aufgrund der gestiegenen Rechenleistung.
Die "Sicherheit" basiert darauf den Aufwand für Brute-Force so hoch wie notwendig und die benötigte Rechenleistung so gering wie möglich zu setzen.
Also wird mit der Zeit einfach die Datenmenge erhöht. von 1KBit über 2KBit zu jetzt 4KBit für z.B. Zertifikate.
In Zukunft dann halt 8KBit und 16KBit usw.
Mein Fazit: Eine Verschlüsselung bei der es unendlich viele Versuche gibt kann auf theoretischer Ebene nicht sicher sein.
Aber natürlich kann Sie im Jetzt und Hier sehr sicher sein.
Viele Grüße
Stefan
das ist eine grundsätzliche Frage zu verschlüsselungssystemen.
Diese sind mathematisch sicher.
Es wurde also mathematisch bewiesen, dass ein zurückrechnen nicht möglich ist.
Es bleiben immer 2 Möglichkeiten.
1) Einfach alle Möglichkeiten der Reihe nach ausprobieren (Brute Force)
2) Nach Schwachstellen bei der Implementierung schauen (immer die gleiche Zufallszahl, etc).
Mit unendlicher Rechenleistung ist jede Verschlüsseung per Brute-Force zu knacken.
Was also heute noch sicher ist, ist es in 10 Jahren vermutlich nicht mehr aufgrund der gestiegenen Rechenleistung.
Die "Sicherheit" basiert darauf den Aufwand für Brute-Force so hoch wie notwendig und die benötigte Rechenleistung so gering wie möglich zu setzen.
Also wird mit der Zeit einfach die Datenmenge erhöht. von 1KBit über 2KBit zu jetzt 4KBit für z.B. Zertifikate.
In Zukunft dann halt 8KBit und 16KBit usw.
Mein Fazit: Eine Verschlüsselung bei der es unendlich viele Versuche gibt kann auf theoretischer Ebene nicht sicher sein.
Aber natürlich kann Sie im Jetzt und Hier sehr sicher sein.
Viele Grüße
Stefan
Eine Antwort auf die Frage findest du hier:
http://www.heise.de/ct/ausgabe/2016-1-Der-Krypto-Wegweiser-fuer-Nicht-K ...
http://www.heise.de/ct/ausgabe/2016-1-Der-Krypto-Wegweiser-fuer-Nicht-K ...
Wenn man Kenntnis vom Klartext hat gibt es Möglichkeiten über "Known Plaintext Attacks" die Verschlüsselung leichter anzugreifen.
Um Bruteforce kommst du zwar weiterhin nicht herum, wenn du aber weißt wonach du suchst werden die Bruteforce-Attacken deutlich einfacher.
Die von dir eingesetzte Betriebsart ECB ist für diese Art Angriff leider extrem anfällig - denn sie bildet relativ kurze Blöcke, die dann separat für sich mit dem geheimen Schlüssel verschlüsselt werden. Das ist doof, weil du dabei wiedererkennbare Blöcke erzeugst (gleiche Klartextmuster egeben gleiche verschlüsselte Muster).
Das ist bei deinem kurzen Text noch nicht so richtig sichtbar, da die Blöcke in der Regel zwischen 64 und 128 Bit lang sind.
Wenn du dich dagegen schützen willst, solltest du CBC als Betriebsmodus verwenden. Der bildet zwar auch einzelne Blöcke, verknüpft diese aber vor der Verschlüsselung per XOR mit dem vorherigen Block - das führt dann dazu, dass du keine wiedererkennbaren Muster hast, selbst wenn du darin eine Textdatei verschlüsselst, die nur 5.000 Leerzeichen enthält. Und das wiederum erschwert unter anderem die Known Plaintext Attacks.
Für CBC benötigst du für die Verschlüsselung des ersten Blocks einen "Initialitation Vector", dessen Länge einer Blocklänge entspricht.
Der wird für die Verschlüsselung des ersten Blocks benötigt und muss bei der Entschlüsselung bekannt sein - er ist aber nicht besonder "Schutzbedürftig" und kann daher einfach den verschlüsselten Daten vorangestellt in der Datei übertragen werden. Man sollte als IV etwas nehmen, was nicht vorhersagbar ist - z.B. zufällig generierte Zahlen multipliziert mit dem aktuellen Timestamp oder sowas.
Beispiel für AES-ECB:
Als Input habe ich einfach 32x das Zeichen "A" und direkt danach 32x das Zeichen "Z" geschrieben, so dass wiedererkennbare Muster entstehen können.
(16 Zeichen ergeben jeweils 128 Bit Input). Die daraus entstehenden verschlüsselten Daten sind:
b5 e7 60 b4 85 55 33 c3 dc 6e ca 9a dd a5 2c 4b
b5 e7 60 b4 85 55 33 c3 dc 6e ca 9a dd a5 2c 4b
5c 54 2c 58 d9 52 2b 7e 79 a0 47 44 22 b4 e6 72
5c 54 2c 58 d9 52 2b 7e 79 a0 47 44 22 b4 e6 72
Man erkennt relativ deutlich, wo wiederholende Zeichenketten sein müssten
Da man jetzt für eine Bruteforce-Attacke (sofern man den Inhalt im Klartext kennt) nur noch ein einziges kurzes Muster entschlüsseln können muss, reduziert sich der Aufwand gewaltig da per Bruteforce gegen zu hämmern.
Das gleiche im CBC-Modus:
8e 73 40 07 d1 10 d9 22 60 79 38 d0 e0 71 55 2c
02 36 ba 9c 66 90 1a 3d 6d 75 be 2f f1 fb 5a 9b
d1 79 56 a4 51 b9 be 5d ff 97 da 80 f4 c0 74 2e
5a 4a 49 bd 69 f8 f7 a0 ff 8b 8b a1 69 90 92 1d
Initialitation Vector: 31 52 71 fe 70 ed 9f c9 36 50 c7 8b 68 2b 3c 38
Trotz wiederholender Daten gibt es keine wiederholenden Muster.
Um deine Frage dahingehend noch etwas zu beantworten:
Es gibt verschiedene Möglichkeiten die verschlüsselten Daten auszugeben - als Hexadezimal-Repräsentation oder als Base64 oder...
Fakt ist aber, dass du den verschlüsselten Text nicht mehr mit normalen ASCII-Characters darstellen kannst und demzufolge die Daten "Binary Safe" übertragen musst.
Um Bruteforce kommst du zwar weiterhin nicht herum, wenn du aber weißt wonach du suchst werden die Bruteforce-Attacken deutlich einfacher.
Die von dir eingesetzte Betriebsart ECB ist für diese Art Angriff leider extrem anfällig - denn sie bildet relativ kurze Blöcke, die dann separat für sich mit dem geheimen Schlüssel verschlüsselt werden. Das ist doof, weil du dabei wiedererkennbare Blöcke erzeugst (gleiche Klartextmuster egeben gleiche verschlüsselte Muster).
Das ist bei deinem kurzen Text noch nicht so richtig sichtbar, da die Blöcke in der Regel zwischen 64 und 128 Bit lang sind.
Wenn du dich dagegen schützen willst, solltest du CBC als Betriebsmodus verwenden. Der bildet zwar auch einzelne Blöcke, verknüpft diese aber vor der Verschlüsselung per XOR mit dem vorherigen Block - das führt dann dazu, dass du keine wiedererkennbaren Muster hast, selbst wenn du darin eine Textdatei verschlüsselst, die nur 5.000 Leerzeichen enthält. Und das wiederum erschwert unter anderem die Known Plaintext Attacks.
Für CBC benötigst du für die Verschlüsselung des ersten Blocks einen "Initialitation Vector", dessen Länge einer Blocklänge entspricht.
Der wird für die Verschlüsselung des ersten Blocks benötigt und muss bei der Entschlüsselung bekannt sein - er ist aber nicht besonder "Schutzbedürftig" und kann daher einfach den verschlüsselten Daten vorangestellt in der Datei übertragen werden. Man sollte als IV etwas nehmen, was nicht vorhersagbar ist - z.B. zufällig generierte Zahlen multipliziert mit dem aktuellen Timestamp oder sowas.
Beispiel für AES-ECB:
Als Input habe ich einfach 32x das Zeichen "A" und direkt danach 32x das Zeichen "Z" geschrieben, so dass wiedererkennbare Muster entstehen können.
(16 Zeichen ergeben jeweils 128 Bit Input). Die daraus entstehenden verschlüsselten Daten sind:
b5 e7 60 b4 85 55 33 c3 dc 6e ca 9a dd a5 2c 4b
b5 e7 60 b4 85 55 33 c3 dc 6e ca 9a dd a5 2c 4b
5c 54 2c 58 d9 52 2b 7e 79 a0 47 44 22 b4 e6 72
5c 54 2c 58 d9 52 2b 7e 79 a0 47 44 22 b4 e6 72
Man erkennt relativ deutlich, wo wiederholende Zeichenketten sein müssten
Da man jetzt für eine Bruteforce-Attacke (sofern man den Inhalt im Klartext kennt) nur noch ein einziges kurzes Muster entschlüsseln können muss, reduziert sich der Aufwand gewaltig da per Bruteforce gegen zu hämmern.
Das gleiche im CBC-Modus:
8e 73 40 07 d1 10 d9 22 60 79 38 d0 e0 71 55 2c
02 36 ba 9c 66 90 1a 3d 6d 75 be 2f f1 fb 5a 9b
d1 79 56 a4 51 b9 be 5d ff 97 da 80 f4 c0 74 2e
5a 4a 49 bd 69 f8 f7 a0 ff 8b 8b a1 69 90 92 1d
Initialitation Vector: 31 52 71 fe 70 ed 9f c9 36 50 c7 8b 68 2b 3c 38
Trotz wiederholender Daten gibt es keine wiederholenden Muster.
Um deine Frage dahingehend noch etwas zu beantworten:
Es gibt verschiedene Möglichkeiten die verschlüsselten Daten auszugeben - als Hexadezimal-Repräsentation oder als Base64 oder...
Fakt ist aber, dass du den verschlüsselten Text nicht mehr mit normalen ASCII-Characters darstellen kannst und demzufolge die Daten "Binary Safe" übertragen musst.
2
Vielen Dank für deine ausführliche Antwort!
