Verschlüsselung

[Casablanca]

Hi,

ich habe eine Zeichenkette, die von zwei unterschiedlichen Programmiersprachen durch AESMode.cbc mit dem KEY und IV verschlüsselt sind:

do+uVdp2bl9fwqXhfKGXBA==
do+uVdp2bl9fwqXhfKGXBA==

Wie man es sieht, sehen beide Verschlüsselungen gleich aus, wobei bei der ersten bekommt man eine saubere Entschlüsselung und bei der zweiten gar nichts heraus. Versteht das jemand, warum so etwas möglich ist?

LG

[klawischnigg]

Hi there,

ich habe eine Zeichenkette, die von zwei unterschiedlichen Programmiersprachen durch AESMode.cbc mit dem KEY und IV verschlüsselt sind:

do+uVdp2bl9fwqXhfKGXBA==
do+uVdp2bl9fwqXhfKGXBA==

Wie man es sieht, sehen beide Verschlüsselungen gleich aus, wobei bei der ersten bekommt man eine saubere Entschlüsselung und bei der zweiten gar nichts heraus. Versteht das jemand, warum so etwas möglich ist?

Ja, entweder Du machst oder die Programmiersprache macht beim Entschlüsseln einen Fehler. Meine jahrzehntelange Erfahrung in diesen Dingen sagt mir, daß der Fehler vermutlich nicht bei der Programmiersprache liegt...

[Casablanca]

Hallo,

weise Worte! Ich habe nun herausgefunden, dass beim Kopieren der Zeichenkette etwas am Ende der Zeichenkette mit kopiert wird. Die Zeichenkette steht im Anführungszeichen, also "do+uVdp2bl9fwqXhfKGXBA==". Wenn ich nun die rechte Anführungszeichenkette einmal lösche und nochmal setze, funktioniert mit der Entschlüsselung auch tadellos. Das, was am Ende zwischen = und " stehen kann, ist mir nicht klar. Gruß

[klawischnigg]

Hi there,

Das, was am Ende zwischen = und " stehen kann, ist mir nicht klar.

Ja, böses Foul, so etwas kann passieren. Was dann wirklich dort steht, kann man sich in einem Hex-Editor anschauen. Was es bedeutet findet man nur heraus, wenn man den Zeichensatz kennt, in dem man sich bewegt...

[Raktenfüllfix]

Das, was am Ende zwischen = und " stehen kann, ist mir nicht klar.

Nun, wie klawischnigg schon schrieb, da kann wirklich alles mögliche stehen. Aber:

"do+uVdp2bl9fwqXhfKGXBA==" ist wohl eine base64-codierte Repräsentation eines “Blob“. Ein Blob ist sowas wie eine Folge von Bytes, die aber teilweise in Text nicht vorkommen dürfen und von Textbetrachtern und Editoren unterschiedlich behandelt (ignoriert oder ersetzt) werden. Ein gezippte Daten oder ein kompiliertes Programm wäre ein Beispiel.

Damit man diese Blobs als Texte transportieren und notieren kann werden diese kodiert (sozusagen umgerechnet) und zwar auf eine Gruppe von 64 Zeichen (A-Z, a-z, 0-9, +/). Das nennt sich base64encode. Die „Rückrechnung“ ist eindeutig.

Vergleichbar ist das mit dem Umrechnen von Zahlen zwischen Zahlen Systemen: So ist Repräsentation einer dezimal notierten 9 binär 1001, oktal 81.

Beim Versachlüsseln entsteht also eigentlich ein Blob, der dann base64-kodiert präsentiert wird. Dem werden zur Erkennung die beiden "==" angehangen. Oft werden überlange Zeilen außerdem noch umgebrochen. Manchmal steht da noch eine Prüfsumme am Ende - nach den beiden "==" (Radix)

Vor dem Entschlüsseln ist also auch ein „Ausradieren“ der Zeilenumbrüche und dann base64-decode fällig. Offenbar gibt es hier ein Problem: nämlich das am Ende des base64-Codes ein (eventuell!) nicht druckbares Zeichen steht. Es kann auch nicht gesehener Zeilenumbruch sein.

Unter Linux würde ich also einfach versuchen, die in Base64 kodierten Daten vor der Weiterverarbeitung mit etwas wie tr -d '[:cntrl:]' von Steuerzeichen (z.B. Zeilenumbrüchen) zu befreien.

echo -e "Hallo\nWelt" | tr -d '[[:cntrl:]]'

gibt dann "HalloWelt" aus. Das ist nicht perfekt, sollte aber genügen.

Ach so: Wo das Problem entsteht weiß ich nicht. Jedenfalls hast Du nach dem Verschlüsseln und Base64-kodieren (oft ein Schritt, genau wie umgekehrt) etwas, was Du beim Entschlüsseln nicht willst bzw. was Dein Programm nicht versteht. Also untersuche, ob das Steuerzeichen durch irgendetwas in Deinem Skripten bzw. Befehlen in den String gelangt.

Oder „putze“ den String wie gezeigt mit etwas wie tr. oder halt dem was Deine Programmier/Skriptsprache dafür mitbringt

[Raketenkorrigierfix]

So ist Repräsentation einer dezimal notierten 9 binär 1001, oktal 81.

So ist Repräsentation einer dezimal notierten 9 binär 1001, oktal 11.

[Rolf B]

Hallo Raktenfüllfix,

das == am Ende eines base64-codierten Strings ist ein Füllzeichen, kein Erkennungsmarker. Das = ist kein gültiges base64-Codierzeichen. Wenn die Länge des Input-Datenstroms durch 3 teilbar ist, gibt es kein Füllzeichen am Ende. Ist die Länge 3n+1, endet der base64-String auf ==. Ist die Länge 3n+2, endet er auf =.

Die Info, ob etwas base64 codiert ist, muss der Kontext hergeben, dafür gibt es keine spezielle Marke in der Codierung.

Umbruch ist bei base64 - soweit ich weiß - nicht vorgegeben. Nur wenn man base64-codierte Binärströme in andere Kontexte einfügt, z.B. in eine Mail, gibt der Kontext vor, wie umzubrechen ist (spätestens nach 76 Zeichen).

Rolf

[Der Martin]

Hallo,

das == am Ende eines base64-codierten Strings ist ein Füllzeichen, kein Erkennungsmarker. Das = ist kein gültiges base64-Codierzeichen. Wenn die Länge des Input-Datenstroms durch 3 teilbar ist, gibt es kein Füllzeichen am Ende. Ist die Länge 3n+1, endet der base64-String auf ==. Ist die Länge 3n+2, endet er auf =.

guter Punkt, das ist mir beim Lesen auch schon aufgefallen. War mir aber nicht wichtig genug, um einen Folgebeitrag zu schreiben.

Umbruch ist bei base64 - soweit ich weiß - nicht vorgegeben. Nur wenn man base64-codierte Binärströme in andere Kontexte einfügt, z.B. in eine Mail, gibt der Kontext vor, wie umzubrechen ist (spätestens nach 76 Zeichen).

Dann müssen aber natürlich die Umbrüche vor dem Decodieren entfernt werden - oder ignoriert ein der Spezifikation entsprechender Decoder von sich aus Whitespace und Umbrüche?

Live long and pros healthy,
 Martin

[Rolf B]

Hallo Martin,

Dann müssen aber natürlich die Umbrüche vor dem Decodieren entfernt werden

Ein base64-Decoder ignoriert alles außer den 64 Zeichen des Base64-Alphabets und dem = Zeichens (RFC 1521).

Was - wie schon gesagt - das Problem "Wo beginnt und endet das base64-codierte Datenstück" an den Host-Text delegiert.

Rolf

[Raketenfüllfix]

Nur wenn man base64-codierte Binärströme in andere Kontexte einfügt, z.B. in eine Mail, gibt der Kontext vor, wie umzubrechen ist (spätestens nach 76 Zeichen).

Deswegen hab ich ja geschrieben: oft wird er umgebrochen.