Verschlüsselte JPEG Datei anzeigen

[cable545]

Juten Tag,
ich hab mal ne Frage. Ich habe mit einer eigenen AES Implementierung eine JPEG Datei verschlüsselt, um das Resultat einer bestimmten Betriebsart von Blockchiffren zu sehen.
Nun ist es aber so, dass sich der Inhalt der verschlüsselten Datei nicht anzeigen lässt.
Besitzt eine JPEG Datei irgendeinen Header in welchem Daten drin stehen die ich nicht verschlüsseln darf?
Oder anders, kann ich eine solche Kennung wiederherstellen?

 

[HoaX]

Wenn es verschlüsselt ist, dann ist es kein Bild mehr, das ist ja der Sinn der Verschlüsselung, den Inhalt zu verbergen.

Wozu den Header stehen lassen wenn die enthaltenen Daten ggf. ungültig sind, weil diese nicht dem JPEG-Format entsprechen? Willst du eine bildliche Darstellung erreichen? Dann ist wohl ehr ein Format wie BMP sinnvoll. Wie die ganzen Bildformate aufgebaut sind (Header, etc.) findet man massig bei Google.

 

[irgendjemand]

@TO
selbst wenn du dir die mühe machst und den header nicht cryptest ... wirst du das problem haben das der rest dann keine gültigen JPEG daten mehr sind *zu mal auch gerade bei block-ciphern das problem der längenänderung besteht -> die gecrypteten daten sind unter umständen länger* ... womit du auch nichts mehr graphisch darstellen kannst ...


bei sowas müsstest du dann schon BMP oder ähnliches verwenden die ihre daten 1) nicht verschlüsselen 2) in der regel auch ohne header angezeigt werden können und 3) RAW daten sind ... also das ein pixel auch wirklich 4byte *32bit -> ARGB* hat ... wodurch sich auch bei normalen "auflösungen" kein problem mit der länge ergeben sollte ...

 

[cable545]

cool, ich danke euch. Ich habs mit einem BMP File probiert und hab genau das was ich haben wollte. Ich hab mein ursprüngliches File mit einem FileInputStream in ein Byte Array geschrieben und hab die ersten
54 Byte(Header 1 = 14 Byte, Header 2 = 40 Byte) in ein extra Array geschrieben. Den Rest aus dem Byte Array hab ich verschlüsselt.
Das Byte Array mit den verschlüsselten Daten hab ich dann wieder an den Header gepackt.
Also Header + verschlüsselte Daten. Das läßt sich glücklicher Weise dann auch als BMP File öffnen.

 

[irgendjemand]

auch wenn mir der sinn dahinter nicht ganz klar werden will ... aber gut ... schön das es so funktioniert wie du willst

 

[cable545]

Der Sinn ist der, dass ich mir visuell den Nachteil des "electronic code book mode" bei Blockchiffren anzeigen lassen will. Von meinem ursprünglichen Bild werden immer einzelne Blöcke hintereinander verschlüsselt und dann wieder zusammen gepackt. Jeder 16 Byte(AES) Block aus meinem Bild wird also einzeln verschlüsselt. In dem verschlüsselten Bild lässt sich dann gut erkennen, dass gleiche Byte Folgen immer in allen Blöcken gleich verschlüsselt sind. Bei Wikipedia gibts ein Artikel zum ECB Mode. Da wird genau das Beispiel erklärt. Ich wollte es nochmal selbst ausprobieren.

 

[irgendjemand]

das ist der sinn hinter ECB ... ist halt schnell und unkompliziert ...

wenn du diesen nachteil umgehen willst musst du dir mal CBC *chain block cipher* geben ...
einfach erklärt wird dort jeder folgeblock mit dem vorherigen bereits verschlüsseltem block XOR verknüpft und dann erst durch den cipher gejagt ...

hat aber auch nachteile

1) du brauchst für den ersten block einen sog. initialisierungs Vector
2) durch die zusätzlich XOR operation mehr zeit

außerdem ist gerade bei CBC auch pkcs5padding sinnvoll ... sonst kann es beim entschlüsseln schnell zum "BadBlockPadding" fehler kommen ...

 

[cable545]

Den CBC Mode werde ich morgen mal zusammen basteln. Ist das mit dem IV ein Nachteil ? Ich kann mir den doch zufällig erzeugen lassen und nutz den dann jeweils zur Ver- und Entschlüsselung.
Zu dem padding hab ich leider nix gefunden. Kannst Du das kurz erläutern?
Ansonsten, vielen Dank für die Tipps.

 

[irgendjemand]

nun ... das problem des IV ist das beide seiten genau den selben IV brauchen ... ansonsten knallt es schon beim ersten block

PADDING ist grob gesagt eine technik bei block-basierten vorgängen um unterschiedlich lange input-sequenzen immer auf ein vielfaches der sog. blocklänge zu bringen ...
es passiert nichts mehr und nicht weniger als das der input um so viele zeichen erweitert wird bis der letzte block voll ist ... *bei AES128 immer 16byte blöcke* ...

wie du schon am namen erkennen kannst gibt es für unterschiedliche cipher PKCS #1-14 *glaub ich .. ansonsten wars 1-11* auch immer unterschiedliche PADDING-verfahren ...

AES z.b. fällt unter PKCS #5 ... und verwendet darum das für PKCS #5 beschriebene verfahren ...

*wikipedia sollte bei "PKCS" einiges dazu liefern*

leider kann bei einem ungünstigen input dies zu fehlern führen wenn z.b. der input genau die sequenz enthält die durch das padding ergänzt werden würde geht zwar beim verschlüsseln noch alles gut ... aber beim entschlüsseln kann es dann zu problemen führen ... gerade wenn dieser spezielle block irgendwo mitten drin auftauchen ... kann es beim entschlüsseln dazu führen das der de-cipher denkt das wäre der letzte block mit padding ... und dann gehen eine menge daten verloren ...

 

[cable545]

Ich hab mir den CBC Mode mal erstellt und ausprobiert. Is ne schöne Sache. Den letzten Block meiner Daten hab ich mit Nullen aufgefüllt. Trotz der von Dir genannten Nachteile. Aber da es bei mir nur zum Lernen fungiert, denke ich geht das in Ordnung. Ich danke Dir für Deine guten Tipps.
Bis denne!!!

 

[irgendjemand]

hmm .. gut ... manuell irgendwie padden würde ich nicht ... das würde ich schon dem cipher-impl überlassen ... da z.b. das was du machst FAST PKCS #1 entspricht *anhängen von genau einem "1"er Bit und den rest mit "0"-bits füllen *wird unter anderem auch in der SHA-familie genutzt** ...