Verschlüsselung c# DES -> Delphi DEC DES

[WM_CLOSE]

Ich habe hier folgendes Problem:
Ich habe einen mit dem DES Algorithmus verschlüsselten Text vorliegen.
Der lässt sich mit dem DEC von Delphi entschlüsseln.
In C# sind es ungültige Daten.

Dann habe ich versucht den Text in C# zu verschlüsseln.
Dabei wird nach dem eigentlichen verschlüsselten Passwort noch ein 2. Block angehängt.

In Delphi:

Code:

'123456' -DES> 6C D8 5E D9 85 B9 80 2F

In C#

Code:

"123456" -DES> 6C D8 5E D9 85 B9 80 2F DB F0 9E 7C 06 3A 28 CD

Das Problem dabei: C# braucht den 2. Block zum Entschlüsseln

Kennt jamand einen Weg wie man den 2.Block umgehen kann, bzw den Block berechnen kann

Das ist der Code in C# zum entschlüsseln (Quelle: http://www.codeproject.com/KB/cs/NET...Decrypt.aspx):

Code:

  byte[] iCipherIV = getCipherInitKey();
  byte[] iCipherPassword = getCipherPassword();  //<=IV und PW holen

  DESCryptoServiceProvider cryptoProvider = new DESCryptoServiceProvider();
  cryptoProvider.Mode = CipherMode.CBC;
  MemoryStream memoryStream = new MemoryStream(Convert.FromBase64String(cryptedString));
  CryptoStream cryptoStream = new CryptoStream(memoryStream,
      cryptoProvider.CreateDecryptor(iCipherPassword, iCipherIV), CryptoStreamMode.Read);
  StreamReader reader = new StreamReader(cryptoStream);
  return reader.ReadToEnd();

Ich hoffe mir kann jemand bei dem Problem helfen.

[himitsu]

Der String ist seit Delphi 2009 Unicode ... doppelt sogroße Chars = mehr und andere Daten

Ich weiß jetzt nicht, wie du das in Delphi gelöst/übersetzt hast,
aber verwende mal einen AnsiString.

[edit]
Halt nee, warte mal, das ist bei dir ja andersrum. (in Delphi kürzer)
hmmmm

[Deep-Sea]

Convert.FromBase64String(cryptedString) Wurde die Base64-Kodierung beachtet?!

(PS: DES ... nicht vlt. eeetwas veraltet?! ^^)

[Satty67]

Ich weis nicht, ob C# etwas ans "API-Ergebnis" anhängt, aber vielleicht ist es eine Alternative in Delphi einfach auch die API Funktionen zu verwenden.

Falls ja, Suchbegriffe zum ansetzen:

CryptAcquireContext (holt den DESCryptoServiceProvider)
Übersetzungen von WinCrypt.h nach WinCrypt.pas gibt es auch im Netz

Die CryptoProvider der Win-API (ab XP/SP3) zu verwenden, ist garnicht so komplex. Mit einem CryptRandom Generator hatte ich schon mal einen einfachen Versuch gestartet.

PS: Umschaltung auf AES ist dann auch kein Ding

[gammatester]

Da nur einen Block in Delphi vorliegen hast, ist das entweder der ECB-Modus oder einer von Hagens Spezial-Privat-Modi. Beide kannst Du wohl schwerlich mit CBC entschlüsseln. Versuch's also einmal mit ECB auch in C#, wenn's nicht klappt mußt Du Dir halt die Delphi-Implementation näher ansehen.

Was ist denn der Schlüssel für den Block?

[WM_CLOSE]

Da problem ist, dass ich die Delphi-Anwendung nicht so einfach verändern darf.
Die verschlüsselung läuft in Delphi auch mit CBC, der erste Teil des verschlüsselten Textes ist ja gleich. Und die Base64 kodierung klappt auch einwandfrei. Das Prob ist wirklich "nur" der 2.Block in C#.
Auch das PWD und der IV sind gleich.

Danke erstmal für die Antworten.

Vielleicht starte ich mal einen Delphi-Versuch mit dem Crypto-Provider.

[WM_CLOSE]

So für alle die es interressiert:
Man muss in C# den PaddingMode des CryptoProviders auf none setzen, dann klappt da auch:

Code:

cryptoProvider.Padding = PaddingMode.None;

Danke für die Antworten

Faszinierend: Kaum macht mans richtig schon funktionierts!

[negaH]

Achte dann aber bitte darauf das alle deine Nachrichten vor der Verschlüsselung eine Länge mit dem Mehrfachen von 8 Bytes haben.

Bei DEC ist das irrelevant da der Padding Mode entweder immer Cipher Text Stealing ist (ältere Versionen) oder vom x Bytes Blockmode wird im letzten unvollständigen Datenblock in den 1 Byte Feedback Modus umgeschaltet (neuste Versionen).

Das Padding der Datenblöcke ist lange Zeit ohne Standards gewesen und so hat jeder seine eigenen Verfahren entwickelt.

DEC selbst beschränkt sich ausschließlich auf Paddings deren Datenlänge am Input gleich dem Output ist, also ohne Datenexpansion. Das benutzte Padding Verfahren ist dann für alle Blockmodis der Cipher einheitlich. DEC enthält alos nur ein Padding Verfahren und dieses ist immer implizit aktiv wenn die Nachrichtenlänge nicht glatt durch die Cipher Blockgröße teilbar ist.

Desweiteren werden in DEC keine anderen Padding Verfahren angeboten. Möchte man diese nachträglich einbauen dann muß man nur vor der Verschlüsselung die Nachricht auf ein Mehrfaches der Blockgröße des Ciphers expandieren. Dies impliziert auch das das DEC eigene Padding autom. deaktiviert ist. Der Aufwand ist also relativ gering im Vergleich dazu das DEC alle möglichen Padding Verfahren implementieren müsste, was dann auch die Komplexität für die Benutzer des DECs erhöht. Und davon abgesehen gab es zum Zeitpunkt des DECs noch garnicht all die Paddingverfahren die es heute gibt. Es ist dabei konzeptionell sehr schwierig für die Zukunft des DECs eine ausbaufähige Schnittstelle zu definieren die dann später einfachst erweitert werden könnte durch eigene Paddingverfahren. Hätte es damals schon Standards gegeben, an die man sich auch global orientiert, dann wäre auch dieses Thema im DEC abgehandelt worden.

Gruß Hagen

[negaH]

Verschlüssele doch mal in C# mit Padding eine Nachricht mit zb. 12 Bytes. Den 16 Bytes Ciphertext entschlüsselst du danach mit DEC. Dann wirst du ab dem 12. Byte die fehlenden 4 Bytes lesen können. Ich schätze das da sowas wie 3,2,1,0 drinnen steht.

Wenn du nun dieses Padding im DEC benutzt um deine 12 Bytes Nachricht auf 16 zu expandieren und danach verschlüsselst sollten identische Ciphertexte rauskommen.

Gruß Hagen

[WM_CLOSE]

Danke,
aber das habe ich schon bedacht. Die Nachricht hat genau 8 Bytes (123456\0\0)
C# hängt leider trotzdem ein Padding dran.
Ich hab es jetzt ausgeschaltet, dann geht es.
Dazu kommt, dass ich an der Verschlüsselungsmethode nichts ändern darf (wegen Kompatibilität).