DEC 5.2 mit Vector deccipher Umbau von DOT net auf Delphi

[gammatester]

Wenn ich mir den gesamten Thread noch einmal ansehe, tauchen eine Punkte auf, die zu klären sind: Der Origialbeitrag arbeitet mit 256-Bit Schlüsseln und MD5. Du sagst, Ihr benutzt die gleiche C#-Funktion, verwendest aber in den Codebeispielen 128-Bit-Schüssel und SHA1?

Auf jeden Fall ist ein IV für AES 16-Bytes groß und deshalb sowas wie '2013-02-14 15:45:07.307' nicht zulässig. Also muß ein IV noch irgendwie daraus generiert werden. Daß ist zwar kein Problem als solches, aber der gleiche IV muß halt auf beiden Seiten verwendet werden: Also übertragen oder auf Empfängerseite generieren. Ein fixer IV ist keine gute Idee!

[ToFaceTeKilla]

Ja da hast du natürlich recht. Wir arbeiten auch mit 256-Bit-Schlüsseln, so wie im Bsp. Die 16-Byte die ich in den Codeschnippseln stehen habe, sind da aufgrund des Rumprobierens gelandet (weil ich wirklich KEINE Ahnung hatte, in welchem Zusammenhang das steht). Hab das jetzt entsprechend auch auf 32 Byte geändert.
Im Gegensatz zum OP benutzen wir aber SHA-1 auf C#-Seite, aber das sollte ja weiter keine Rolle spielen oder?
Der IV wird mit übertragen. Also kann ich den Timestamp so nehmen, ja?

[gammatester]

Zitat:

Zitat von ToFaceTeKilla (Beitrag 1206506)

Im Gegensatz zum OP benutzen wir aber SHA-1 auf C#-Seite, aber das sollte ja weiter keine Rolle spielen oder?
Der IV wird mit übertragen. Also kann ich den Timestamp so nehmen, ja?

Vermutlich ja, das hängt von DEC und dem 'Protokoll' ab. Fakt ist, daß ein AES-IV (im engeren Sinn) 16 Bytes hat (wie auch '@1B21337e5F6g7H8' im Original).

Wenn DEC aus der Zeit 16 Bytes für den eigentlichen IV destilliert und zB dem Ciphertext voranstellt, Base-64 kodiert..., dann muß halt die Empfängerseite darauf eingerichtet sein und das ganze in umgekehrten Reihgenfolge aufdröseln: Base64 decodieren, IV separieren, entschüsseln... Der Empfängerseite kann es dann egal sein, wie der IV generiert wurde.

[ToFaceTeKilla]

Nächstes Problem: da ja SHA-1 nur 160-Bit-Output hat (wenn ich das richtig verstehe), hab ich die verwendete Hash-Funktion auf SHA-256 geändert.
Um das überhaupt erstmal zum Funktionieren zu bringen, ver- und entschlüssel ich jetzt erstmal testhalber in Delphi. Dabei ist mir aufgefallen, dass der Aufruf von

Delphi-Quellcode:

pbkdf1s(hash,Password,@Salt,2,key,32);

in der Verschlüsselungsfunktion einen anderen Key ergibt als in der Entschlüsselungsfunktion mit selben Parametern.
Sollte das nicht gleich sein, damit der gleiche Schlüssel erzeugt wird? Ich bin etwas ratlos :|

Edit: OK, mir ist grad wieder eingefallen, dass PBKDF1 nur 160-Bit unterstützt, also hab ich auf SHA-1 zurückgeändert, den Key als array of byte [0..19] deklariert und als dkLen 20 angegeben. Ändert aber nix daran, dass die Keys unterschiedlich sind.

Edit2: Bin jetzt erstmal eine Woche im Urlaub, also nicht sauer sein, wenn ich nicht mehr reagiere ^^

[gammatester]

Zitat:

Zitat von ToFaceTeKilla (Beitrag 1206521)

Nächstes Problem: da ja SHA-1 nur 160-Bit-Output hat (wenn ich das richtig verstehe), hab ich die verwendete Hash-Funktion auf SHA-256 geändert.
...
Edit: OK, mir ist grad wieder eingefallen, dass PBKDF1 nur 160-Bit unterstützt, also hab ich auf SHA-1 zurückgeändert, den Key als array of byte [0..19] deklariert und als dkLen 20 angegeben. Ändert aber nix daran, dass die Keys unterschiedlich sind.

Vielleicht solltest Du zuerst einmal klären, welche KDF die C#-Funktion PasswordDeriveBytes verwendet. Warum verwendest Du ausgerechnet PBKDF1, das als einzige Funktion eine Maximallänge (= Hashlänge) hat? Der Originalcode kann so nicht funktioniert haben mit 128-Bit-Hash und 256-Bit-Schlüssel.

Zitat:

Zitat von ToFaceTeKilla (Beitrag 1206521)

Um das überhaupt erstmal zum Funktionieren zu bringen, ver- und entschlüssel ich jetzt erstmal testhalber in Delphi. Dabei ist mir aufgefallen, dass der Aufruf von

Delphi-Quellcode:

pbkdf1s(hash,Password,@Salt,2,key,32);

in der Verschlüsselungsfunktion einen anderen Key ergibt als in der Entschlüsselungsfunktion mit selben Parametern.
Sollte das nicht gleich sein, damit der gleiche Schlüssel erzeugt wird? Ich bin etwas ratlos :|

Bist Du sicher, daß beides mal die gleichen Eingangsdaten benutzt wurden? Insbesondere muß natürlich das Salz übereinstimmen (kein Zeitstempel, Zufall etc)!?

[ToFaceTeKilla]

Zitat:

Zitat von gammatester (Beitrag 1206792)

Vielleicht solltest Du zuerst einmal klären, welche KDF die C#-Funktion PasswordDeriveBytes verwendet. Warum verwendest Du ausgerechnet PBKDF1, das als einzige Funktion eine Maximallänge (= Hashlänge) hat? Der Originalcode kann so nicht funktioniert haben mit 128-Bit-Hash und 256-Bit-Schlüssel.

PasswordDervieBytes benutzt PBKDF1. Zu dem Warum: Hat eine Kollegin gemacht, ich habe damit nix am Hut. Da die Funktion der des OP entspricht, tippe ich mal auf "irgendwo im Netz gefunden". Laut ihrer Aussage funktioniert das Ver- und Entschlüsseln auf C#-Seite. Vielleicht sollte man ja mal den C#-Code ändern...

Zitat:

Zitat von gammatester (Beitrag 1206792)

Bist Du sicher, daß beides mal die gleichen Eingangsdaten benutzt wurden? Insbesondere muß natürlich das Salz übereinstimmen (kein Zeitstempel, Zufall etc)!?

Die Eingangsdaten sind wirklich gleich. Feste Strings zum Testen.

Edit: Arg wie so oft sitzt das Problem vor dem Monitor :roll:

Delphi-Quellcode:

pbkdf1(hash,@Password[1], Length(password),@Salt[1],2,key,20);

statt

Delphi-Quellcode:

pbkdf1(hash,@Password[1], Length(password),@Salt,2,key,20);

ist des Rätsels Lösung. Der Salt-Parameter ist ja ein Pointer auf einen String. Naja, ich kann mich damit rausreden, dass ich mich bisher von Pointern fern gehalten habe, wenn es ging :stupid:
Jetzt funktioniert zumindest schon einmal das Ver- und Entschlüsseln auf Delphi-Seite. Mal schauen, ob es mit den C#-Testvektoren funktioniert.

[ToFaceTeKilla]

Wie zu erwarten war, geht es natürlich nicht so einfach.

Möglicherweise ist der C#-Code ja nicht mit DEC umkehrbar.
Deshalb wollte ich das jetzt mal mit deinem AES_CBC probieren, kriege da aber auch nur Zeichensalat raus.
Würdest du mir verraten, wie ich das implementieren muss?

Die Testvektoren sind:
Salt: Lovley
IV: 2013-02-14 15:45:07.307 (wenn ein AES-IV immer 16 Byte hat, heißt das, dass hier nur '2013-02-14 15:45' genommen wird?)
Base64-Ciphertext: d1n/OvzsX3r12qplF5izlg==
Plaintext: Test
Passwort (ASCII-Werte): 7 14 31 13

Mein Versuch sieht wie folgt aus (Base64-Decode ist aus DEC):

Delphi-Quellcode:

function DecryptBase64Str(const CipherText_Base64: Binary; const Password: Binary; const Salt: Binary; const InitVector: string): string;
var
  hash: PHashDesc;
  key: array[0..19] of byte;
  ctx: TAESContext;
  aesblck: TAESBlock;
  decodedTxt: string;
  i: Integer;
begin
  hash:= FindHash_by_ID(_SHA1);
  pbkdf1(hash,@Password[1], Length(password),@Salt[1],2,key,20);
  for i := 1 to 16 do
    aesblck[i-1]:= Byte(initvector[i]);
  decodedTxt:= TFormat_MIME64.Decode(CipherText_Base64);
  Result:= decodedTxt;
  ctx.IV:= aesblck;
  AES_CBC_Init_Decr(key,160,aesblck,ctx);
  AES_CBC_Decrypt(@decodedTxt[1],@result[1],length(decodedTxt),ctx);
end;

Über die kryptographische Sicherheit lässt sich sicherlich streiten, aber es geht ja erstmal darum, dass zum Laufen zu bekommen.

Edit:
Was mir noch einfällt: die C#-Verschlüsselung benutzt PKCS7 als Paddingmodus.

[gammatester]

Zitat:

Zitat von ToFaceTeKilla (Beitrag 1208155)

Delphi-Quellcode:

AES_CBC_Init_Decr(key,160,aesblck,ctx);

Das ist Unsinn! Es gibt keine 160-Bit AES-Schlüssel! Leider scheinst Du auch der Unsitte anzuhängen, Fehlercodes einfach nicht zu benutzen und auszuwerten. AES_CBC_Init_Decr ist eine function, mit Deinen Parametern liefert sie -1 = AES_Err_Invalid_Key_Size.

Wie schon gesagt, klär erst mal genau wie auch C#-Seite die Nicht-Standard-Operationen implementiert sind. Wenn das geklärt ist, reduziere alles auf Byte-Testvektoren. Also:

Passsword/Salt etc liefert letztendlich via pbkdf1 einen 128-, 192- or 256-Bit-Schlüssel, den man schon mal auf Übereinstimmung testen kann, ohne die Verschlüssung anzuwerfen. Wenn Du damit fertig bist, diesen Key als array[0..xx] of byte weiter verwenden.

Analog IV und Base64-decodierten Ciphertext CT mit PKCS7-Padding als Bytearrays.

Mit den drei Bytearrays Key, IV und CT gehst Du dann in die CBC-Entschlüsselung, der letzte Block des Klartexts enthält dann das Padding und kann für einen schnellen Test auf Übereinstimmung erstmal ignoriert werden. Ein Plaintext der Länge 4 ist nicht sinnvoll, weil CBC überhaupt nicht zum Einsatz kommt, nimm lieber einen mit 32 oder mehr Zeichen.

[ToFaceTeKilla]

Ja du hast ja recht. Asche über mein Haupt. Ich habe das in der Zwischenzeit beim durchsteppen auch gesehen, dass der Schlüssel nicht reicht.
Die 160 hatte ich ja wegen der Maximallänge von SHA-1 gewählt*. Ich habe gerade nochmal nachgeschlagen, wie das auf C#-Seite funktionieren kann und dabei ist mir aufgefallen, dass PasswordDeriveBytes.GetBytes einfach das Bytearray pseudozufällig auf die gewünschte Länge auffüllt (hier auch nochmal sehr schön beschrieben).
Dann muss wohl erstmal auf C#-Seite der Code angepasst werden.

*Man kann doch mit pbkdf1 und SHA-1 keinen Schlüssel > 160Bit erzeugen oder nicht? Deine pbkdf1-Funktion gibt dann ja auch kdf_err_invalid_dKLen zurück.

[gammatester]

Zitat:

Zitat von ToFaceTeKilla (Beitrag 1208184)

*Man kann doch mit pbkdf1 und SHA-1 keinen Schlüssel > 160Bit erzeugen oder nicht? Deine pbkdf1-Funktion gibt dann ja auch kdf_err_invalid_dKLen zurück.

Jedenfalls nicht mit einem Aufruf der Funktion. Wenn es denn sein muss, reichen zB zwei Aufrufe mit (..,salt1,..) plus (..,salt2,..) oder (..,salt,n1,..) plus (..,salt,n2,..).

Aber das ist Gefrickel. Wenn möglich, nimm lieber pbkdf2; damit kannst Du mit jeder Hashfunktion beliebig lange Bytefolgen erzeugen.

Edit: Sehe gerade das die API aus Deinem ersten Link als veraltet gekennzeichnet ist, die dort angegebene nicht veraltete Alternative ist GetBytes, das PBKDF2 benutzt.