Verschlüsslung AES_Decrypt

[Ykcim]

Hallo Zusammen,

ich habe eine Frage zum Verständnis bezgl. des Verschlüsselns von Datenfeldern.

Also ich möchte ein Datenfeld verschlüsseln und habe gelesen, dass ich dazu AES_ENCRYPT(STR, KEY_STR) verwenden kann.

Jetzt habe ich das ausprobiert und komme mit dem Ergebnis nicht zurecht:

Select AES_ENCRYPT('Hallo','abcd') Das ergibt den Wert: 'çòË¡�)—)�' Ich war davon augegangen, dass ich diesen Wert mit AES_DECRYPT(CRYPT_STR,KEY_STR) wieder entschlüsseln kann.

Aber Select AES_DECRYPT('çòË¡�)—)�','abcd') ergibt den Wert: NULL

Andererseits wenn ich folgendes teste, funktioniert es: Select AES_DECRYPT(AES_ENCRYPT('Hallo','abcd'),'abcd') . Das ergibt den Wert: Hallo .

Ich habe gedacht, dass diese komischen Zeichen nicht in der Eingabkonsole erkannt werden. Kann man die Art der verwendeten Zeichen auf alphanumerisch eingrenzen?
Ich habe es dann mal in einem kleinen Programm getestet und es hat auch nicht funktioniert.
Kann mir jemand sagen, was ich falsch mache?

Vielen Dank
Patrick

[mkinzler]

Select DECRYPT('çòË¡�)—)�','abcd') oder
Select AES_DECRYPT('çòË¡�)—)�','abcd') ?

[Ykcim]

Sorry!

Ich meinte AES_DECRYPT - war nur ein Schreibfehler in meinem Post.

Patrick

[mkinzler]

Ist das Feld auch groß genug?

Zitat von http://dev.mysql.com/doc/refman/5.1/de/encryption-functions.html:

Da AES als Algorithmus auf Blockebene arbeitet, werden Strings unterschiedlicher Länge bei der Verschlüsselung mit Füllzeichen erweitert. Die Länge des Ergebnis-Strings lässt sich mit folgender Formel berechnen:

16 × (trunc(string_length / 16) + 1)

Wenn AES_DECRYPT() ungültige Daten oder ein inkorrektes Auffüllen erkennt, gibt es NULL zurück.

[himitsu]

Das Verschlüsselte/Komprimierte solcher Funktionen stellt (meistens) Binärdaten dar, also solltest du sie entweder in einem Binär-Feld/Blob speichern oder sie, nach dem Vershclüssel, gleich in HEX oder Base64 umwandeln, wenn du sie als Text behandeln willst.

Ich vermute mal, daß sich dein çòË¡�)—)� irgendwo einen Umkodierungsfehler (Codepages) einfängt und damit geschrottet wurde.

PS: die Doku sagt

Zitat:

If AES_DECRYPT() detects invalid data or incorrect padding, it returns NULL.

http://dev.mysql.com/doc/refman/5.6/...on_from-base64

[Ykcim]

An diesem Gedanken habe ich gerade gearbeitet. Daher habe ich es nicht nur mit Einträgen versucht, sondern habe ein Fald als BLOB definiert und den Inhalt von AES_ENCRYPT da drin gespeichert.
Dann habe ich folgendes leider ohne Erfolg getestet:

Delphi-Quellcode:

Select CONVERT(passwort USING utf8 ) from hlp_login where user_id=1
union
Select AES_DECRYPT(passwort,'abcd') from hlp_login where user_id=1

und auch das ergab den Wert NULL:

Delphi-Quellcode:

Select CONVERT(passwort USING utf8 ) from hlp_login where user_id=1
union
Select AES_DECRYPT(CONVERT(passwort USING utf8 ),'abcd') from hlp_login where user_id=1

Die obere Select-Anweisung gibt mir den gespeicherten Wert korrekt zurück, nur die Entschlüsslung sagt immer NULL.

Gruß Patrick

[cookie22]

Edit: Hab mal wieder Unfung geschrieben.

[mkinzler]

Das Problem wird schon bei der Verschlüsselung auftreten. Der erzeugte Wert ist zu kurz [ sollte 16 Zeichen lang sein: 16 * ( Trunc( 5/16)+1) ]. Im 1. Beitrag hat der aber nur 8 Zeichen

[x000x]

Moin moin,

himitsu hat dir doch schon die Ursache genannt. Wenn du es wie folgt ausführst, dann wird es auch funktionieren:

Code:

SELECT HEX(AES_ENCRYPT('Hallo','abcd')); # E7F2CBA19029129729FCD71EA91E3634
SELECT AES_DECRYPT(UNHEX('E7F2CBA19029129729FCD71EA91E3634'),'abcd');

[himitsu]

Base64 ist allerdings etwas "kompakter", als das Hexadezimale.
OK, soooo viel ist es nun auch nicht ... +100% (200%) für Hex und +33% (133%) für Base64.

Und wenn man die Binärdaten ohne "gefährliche" Umwege (über Text) direkt zwischen dem BLOB/VARBINARY und der Funktion übergibt, dann kann man sich das umkodieren auch sparen.
Wenn es denoch "immer" konvertiert wird, dann kann man das dann natürlich auch in ein TEXT/VARCHAR speichern, da es dann ja Text und nichts Binäres ist.


PS: Je nach Sicherheitsstufe sollte man auch über die Verschlüsselung der DB-Verbindung nachdenken, oder ob man die Daten nicht vielleicht bereits im Programm verschlüsselt, damit sie nicht als Klartext aus den Verbindungsdaten ausgelesen werden können.

Ein kleines Beispiel, welches mir vor Kurzem untergekommen ist.
- Die Passwörter werden MD5-gehasht und als HEX, in der DB gespeichert.
- Das Programm verfügt über eine Logfunktion, welche standardmäßig (falls man es nicht geziehlt deaktiviert) vielleicht die letzten 100 Queries der Connection in einem eher ungeschützten Log vorhält.
- Die Prüfung des Passwortes wurde dann in etwa so erledigt SELECT password = md5(:password) FROM users WHERE user = :user .
- Und das Ergebnis war dann das Passwort als Klartext im Log. (welches zum Glück nicht mehr standardmäßig 'ne Woche lang auf der Festplatte landet)