![]() |
DEC 5.1: Problem bei sprachübergreifender Verwendung von DEC
Hi, ich habe ein kleines Problem damit, dass ich mit Delphi 7 und DEC 5.1 eine Datei verschlüsseln (AES oder Blowfish) und mit Java/JCA die Datei wieder entschlüsseln möchte. Allerdings sind bisher alle Versuche gescheitert. Ich bekomme einfach die Datei nicht wieder entschlüsselt. Hat jemand schonmal Erfahrung mit der plattformübergreifenden Verschlüsselung mittels DEC?
Mein Delphi-Code sieht wie folgt aus:
Delphi-Quellcode:
RegisterDECClasses([TCipher_Rijndael, THash_SHA1]);
AMode := cmCTSx; ACipher := TCipher_Rijndael; Source := TFileStream.Create('origfile.zip', fmOpenReadWrite); try Dest := TFileStream.Create('encfile.enc', fmCreate); try with ACipher.Create do try Mode := AMode; Init(#1#2#3#4#5#6#7#8#9#10#11#12#13#14#15#16); EncodeStream(Source, Dest, Source.Size); finally Free; end; finally Dest.Free; end; //ProtectStream(Source); finally Source.Free; end; Der vollständigkeithalber hier noch der Java-Code, den ich zur Entschlüsselung nutze:
Delphi-Quellcode:
byte[] key = { (byte)1,(byte)2,(byte)3,(byte)4,(byte)5,(byte)6,(byte)7,(byte)8,(byte)9,(byte)10,(byte)11,(byte)12,(byte)13,(byte)14,(byte)15,(byte)16 };
SecretKeySpec skeySpec = new SecretKeySpec(key, "AES"); // Instantiate the cipher try { Cipher cipher = Cipher.getInstance("AES"); cipher.init(Cipher.DECRYPT_MODE, skeySpec); InputStream in = new FileInputStream(new File("encfile.enc")); OutputStream out = new CipherOutputStream(new FileOutputStream(new File("new.zip")), cipher); byte[] dec = new byte[8192]; int n; while(( n = in.read( dec )) > 0 ) { out.write( dec, 0, n ); } in.close(); out.close(); } catch (Exception e) { e.printStackTrace(); } Fällt euch etwas ein, was da nicht passt? Beide Codes erzeugen eine Datei mit der richtigen Größe, aber nicht mit dem richtigen Inhalt... Ich habe es mit AES und Blowfish versucht, aber irgendwie passt es nicht. Danke. Gruß, Stefan |
Re: DEC 5.1: Problem bei sprachübergreifender Verwendung von
also
1. Passwort
Delphi-Quellcode:
2. Cipher Modus kannst du nicht auf cmCTSx stehen lassen da dieser vom JAVA garnicht unterstützt wird. Probiere mal cmCBCx oder cmECBx aus.Init(TFormat_HEX.Decode('0102030405060708090A0B0C0D0E0F10')); 3. Was benutzt JAVA als IV ? (Initvector) 4. Es hat sich bewährt wenn man bei solchen Fragen par Testvektoren hat. So kann man offline überprüfen welche Einstellungen die richtigen sind. Gruß Hagen |
Re: DEC 5.1: Problem bei sprachübergreifender Verwendung von
Hallo Hagen,
danke für die Antwort. Ich habe in meinem Code gar keine IV gesetzt und Java nutzt in der Standardeinstellung für AES einen Mode, der auch keinen IV verlangt. Wenn ich den Mode in DEC nun auf cmCBCx setze, dann müsste ich den IV ja auch in Java setzen. Ich habe jetzt als Mode CBC und einen IV in Delphi explizit gesetzt und diesen dann auch in Java verwendet und siehe da, es passt fast. Ich habe jetzt nur noch ein Problem mit dem Padding. Das Ende der Datei ist abgeschnitten (27 Zeichen fehlen, also passt das Padding auch nicht). Welcher Padding-Algorithmus ist den in DEC per Default eingestellt? Wenn ich "NoPadding" einstelle, dann fehlen am Ende der Datei nur noch 11 Zeichen.... - zwar mehr, aber noch nicht vollständig. Wenn du hierzu noch einen Tipp hättest. Danke. Gruß, Stefan |
Re: DEC 5.1: Problem bei sprachübergreifender Verwendung von
Hm, jo das nächste Problem. JAVA wird wohl an die Daten soviele Bytes dranhängen bis die geamte Nachricht ein Vilefaches von 8 oder 16 Bytes ist. Das dafür benutzte Padding Schemata kann sehr unterschiedlich sein. Da musst du mal in den JAVA Helpfiles stöbern. DEC paddet nur wenn die Nachricht in der Anzahl der Bytes nicht ohne Rest durch Cipher.BlockSize teilbar ist. Der letzte unvollständige Datenblock von X = Nachrichtenlänge modulo Cipher.BlockSize wird dann im cmCBC8 Modus verschlüsselt, Also das ist wie cmCBCx, wobei dieser CBC immer auf Blöcken von Cipher.BlockSize Bytes arbeitet. der cmCBC8 Modus arbeitet mit einem Feedback von 8 Bit = 1 Byte. Somit sind cmCBCx und cmCBC8 von iherer Funktionerweise identisch nur das sich die Datenbreite des Feeebackregisters verändert. Einmal ist es Cipher.BlockSize Bytes und das anderes mal ist es 1 Byte. Dieses Padding ist einfach, führt zu keiner Nachrichtenexpansion, simpel zu implementieren da meistens sowieso beide Feedbackgrößen unterstützt werden und es ist kryptogaphisch sicherer als viel der anderen Paddingschematas.
Du kannst also folgendes machen 1.) verschlüssel die Nachricht soweit bis alle Datenblöcke a Cipher.BlockSize verarbeitet sind 2.) den Rest der Nachricht in temp. Buffer kopieren und mit zusätzlichen Bytes am Ende expandieren, je nach Padding Schemata 3.) diesen Block weiterverschlüsseln und an die verschlüsselten Daten dranhängen Du kannst weiterhin mit Cipher.EncodeStream(), .EncodeBinary() und .Encode() arbeiten. Nur musst du es zweimal aufrufen. Also so
Delphi-Quellcode:
Gruß Hagen
var
Remain,I: Integer; Buffer: array of Byte; begin with TCipher.Create do try Mode := cmCBCx; Init(Password, SizeOf(Password), InitVector); Remain := Source.Size mod Context.BlockSize; EncodeStream(Source, Dest, Source.Size - Remain); if Remain > 0 then begin // Padding nach alter Methode SetLength(Buffer, Context.BlockSize); Source.ReadBuffer(Buffer[0], Remain); for I := Remain to High(Buffer) do Buffer[I] := I; // je nach Padding Schema befüllen Encode(Buffer[0], Buffer[0], Length(Buffer)); Dest.WriteBuffer(Buffer[0], Length(Buffer)); end; finally Free; end; end; |
Re: DEC 5.1: Problem bei sprachübergreifender Verwendung von
Hallo Hagen,
perfekt :-D ! Danke für Padding-Algorithmus, jetzt funktioniert's. Das entschlüsselte Ergebnis hat zwar ein paar Bytes mehr, aber das stört nicht weiter. Vielen Dank nochmal! Gruß, Stefan |
Re: DEC 5.1: Problem bei sprachübergreifender Verwendung von
Musst du detektieren. Einfach des letzte Byte als Anzahl der angehangenen Bytes interpretieren. Manche Paddings speichern in den letzten zuvielen Bytes exakt die Anzahl der angehangenen Bytes. Andere zählen rückwärts/vorwärts runter, wiederum andere hängen auch einen kompletten gepaddeten Datenblock hintendran falls die Nachricht schon ein Mehrfaches der Blockgröße ist. Das musst du also genau in Erfahrung bringen, eg. wie JAVA das macht.
Achso: und da gibts noch die Methode den letzten zu kurzen Datenblock virtuell mit festen Bytes zu erweitern und dann zu Verschlüsseln. Abgespeichert werden von diesem verschl. Datenblock nur die gleichen Anzahl wie vor der Verschlüsselung. Sowas nennt sich meistens Cipher Text Stealing oä. Bei der Entschlüsselung muß man dann aus dem Vorgängerdatenblock quasi Bytes stehlen mit denen der letzte unvollständige Datenblock wiederum virtuell expandiert wird und erst dann entschlüsselt wird. Gruß Hagen |
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:43 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz