Dies ist der (bisher) aufwändigste Eintrag.

Nachdem ich einen Interessanten Artikel [1] gelesen hatte, wusste ich direkt das es ein gutes Thema für den cryptblog ist. Und zwar geht es um Probleme beim Verschlüsseln von Bildern.

Zuerst jedoch noch eine wichtige Grundlage: bei Kryptosystemen gibt es verschiedene Betriebsmodi, die bekannteste ist der ECB-Mode (Electronic Code Book). Es ist ja in der Regel so, das nicht nur lediglich 128 Bit verschlüsselt werden sollen, sondern Gigabyte an Daten. Dafür wird dieser große Haufen bei Blockchiffren entsprechend aufgeteilt in kleinere. Ein Beispiel:

“Hallo, wie geht es dir  ” wird (sofern 1 Zeichen = 16 Bit) in:

“Hallo, w”, “ie geht “, “es dir  ”

aufgeteilt. Wie man sieht wurde hier der letzte String aufgefüllt damit er ein Vielfaches von 8 entspricht. Dies ist auch in der Praxis üblich.  Wir besitzen also am Ende eine große Liste von 128-Bit blöcken welche nacheinander ins Kryptosystem eingespeist und damit verschlüsselt werden. Heraus kommt z.B:

“mdjwbcxg”, “ötüeoejd”, “ndkrdkdp”.

Das Problem bei diesem Modus ist, das gleicher Klartext auch in den gleichen Chiffretext verschlüsselt wird. D.h. wenn ich “12345678″ an 2 unterschiedlichen Stellen im Text verschlüssele, würde auch jeweils die gleiche Verschlüsselung entstehen.

aus: “Hallo, wie geht es dir Hallo, wie geht es dir ” wird also:
“mdjwbcxgötüeoejdndkrdkdpmdjwbcxgötüeoejdndkrdkdp“.

Und das ist ein Problem bei Bildern, denn dort finden sich an vielen Stellen gleiche/ähnliche Werte. An dieser Stelle ein Beispiel mit zwei 2×2 Pixel Bildern:

Sei also links unser Klartext (das normale Bild) und rechts der Chiffretext (die Verschlüsselung). Aus dem schwarz und dem dunkelgrau werden jeweils gelb und grün. Jedoch diese zwei silbergrauen Flächen werden identisch verschlüsselt (blau). Dies wäre natürlich nur der Fall wenn die Chiffre nur eine 32 Bit Blockgröße hätte (Rot, Grün, Blau, Alpha), jedoch bleibt das Problem bei 128 Bit ebenso: gleiche Flächen werden gleich verschlüsselt und dies ist vorallem bei kontrastreichen und großen Bildern durch wiederholende Muster zu sehen.

Da mir das jedoch noch nicht genügte, habe ich ein Programm gebaut, welches die Bilder mit Blowfish (24 lässt grüßen) im ECB Modus verschlüsselt.

Oben zu sehen das Originalbild, unten jeweils die Verschlüsselungen mit zwei unterschiedlichen Passwörtern. Hier ist das Problem deutlich zu erkennen: im vertikalen Bereich sind die Farbcodes jeweils identisch. Die kleinen Ungenauigkeiten stammen wahrscheinlich aus der JPG Komprimierung.

Zuletzt das ganze auch mal mit einem richtigen Bild. An dieser Stelle danke ich Tobias Gräber für die Bereitstellung:

Besonders gut zu erkennen ist das Geländer an der rechten Seite. Auch einige Konturen finden sich in der verschlüsselten Version wieder.

Abschließend lässt sich also sagen, das eine Verschlüsselung alleine nicht immer genügt. Die Verschlüsselung und dessen Modus muss auch zum Einsatzzweck passen.

Quellen:
[1] http://www.turbocrypt.com/eng/content/TurboCrypt/Backup-Attack.html

Tim Kryptographie

Nachdem ich nun in den letzten Wochen Staffelweise 24 geschaut habe, will ich einige Aussagen (die ich so gehört habe) kommentieren.

“das ist Blowfish verschlüsselt, das erkennt man am Header.”

Klingt gut, ist aber Unsinn. Eine verschlüsselte Datei bzw. ein verschlüsselter Container besitzt keinen besonderen Header. Natürlich könnte man dem zurecht entgegenhalten das dies Anwendungsspezifisch ist. Jedoch wo liegt der Sinn einem Angreifer schon vor Eingabe des Passworts den Algorithmus zu verraten (lassen wir Kerkhoff außen vor).  Sofern kein besonderer Verschlüsselungsalgorithmus ausgewählt ist, führen Programme “Probeentschlüsselungen” durch und prüfen auf Plausibilität. 

Decryption is considered successful if the first 4 bytes of the decrypted data contain the ASCII string “TRUE”, and if the CRC-32 checksum of the last 256 bytes of the decrypted data (volume header) matches the value located at byte #8 of the decrypted data (this value is unknown to an adversary because it is encrypted – see the section Header Key Derivation, Salt, and Iteration Count). If these conditions are not met, the process continues from (3) again, but this time, instead of the data read in (1), the data read in (2) are used (i.e., possible hidden volume header). If the conditions are not met again, mounting is terminated (wrong password, corrupted volume, or not a TrueCrypt volume).

Quelle: http://www.truecrypt.org/docs/encryption-scheme.php

Außerdem ist Blowfish (128 Bit) schwer veraltet.

Definieren wir das Ganze einfach mal als zweifelhaft.

 

Als nächstes:

“das ist eine affine Chiffre, die kann man nicht knacken”

Okay, Blowfish geht, aber eine (linear) affine Chiffre nicht. Die Affine Chiffre ist (das findet auch jeder in Google) eine einfache Blockchiffre, welche allerdings im Gegensatz zur einfachen Verschiebechiffre noch einen 2. Schlüssel hat. Der Schlüssel ist also ein zwei-Tupel: k=(a,b). Wenn wir eine Alphabetsgröße von 26 festlegen, verschlüsselt sich Text mit Hilfe folgender Formel:

c = a*p + b mod 26

Wobei c das neue Chiffre- und p ein Klartextzeichen ist. Ein Beispiel:

Klartext: “ABC”, Key: (2,3)

2 * 0 (A) + 3 mod 26 = 3 (C)
2 * 1 (B) + 3 mod 26 = 5 (E)
2 * 2 (C) + 3 mod 26 = 7 (G)

Chiffretext = “CEG”

Zum entschlüsseln muss ein mulitplikatives Inverses berechnet werden.

Das versteht man also unter einer affinen Chiffre. Natürlich ist etwas kniffeliger als eine reine Verschiebe oder Vignerechiffre, jedoch nicht wirklich ein Problem. Mit ein wenig Verstand bekommt man es auch noch gut auf dem Papier hin.
Diese Aussage können wir zweifelsfrei als Unsinn bezeichnen.

Tim IT-Sicherheit, Kryptographie