DEC <-> .Net Cryptohgraphy (Rijndael)

[dfried]

Hallo,

ich habe in Delphi eine Routine um einen String zu Verschlüsseln mit DEC und Rijndael. Nun soll dieser Text über ein .Net Programm wieder entschlüsselt werden mit den .Net-Cryptography Klassen, aber irgendwie haut das überhaupt nicht hin.

Welche Parameter müssten bei DEC bzw. .Net eingestellt werden, damit ich den dort erzeugten Verschlüsselten String wieder über das .Net-Programm entschlüsseln kann?

Hab es derzeit probiert mit dem Mode cmCBCx und dem Format TFormat_MIME64 als Rückgabeformat der Funktion EncodeBinary.

Delphi-Quellcode:

  with TCipher_Rijndael.Create do
  try
    Mode := cmCBCx;
    Init('');
    OutputStr := EncodeBinary(InputStr, TFormat_MIME64);
  finally
    Free;
  end;

[negaH]

Wie wird den im .NET der AES benutzt ? Also welche Einstellungen und Parameter ?

Die Sache ist nämlich das der AES-Rijndael im DEC mit offiziellen Testvektoren verifiziert ist, der ist also richtig.

Gruß Hagen

[dfried]

Im Moment verwende ich dazu das Assembly hier.
(Kann bei Bedarf auch das ZIP hier anhängen, falls du keinen Account bei CodeProject hast)

[negaH]

Und welche Parameter werden benutzt ? Solange man nicht die Parameter kennt, also

- Schlüsselgröße für AES
- Umwandlungsfunktion des Passwortes in einen Sessionkey, falls verwendet
- Ciphermode, wie CBC oder ECB usw.
- verwendete Textformate um binäre Daten darzustellen

macht ein Vergleich keinen Sinn. Dieses abzugleichen ist ja gerade die Kunst des Programmierers der verschiedene Systeme zusammenführen möchte. Entscheidend ist das er Entwickler der Systembibliothek, also im Falle vom DEC meine Person, oder im Falle des Assemblies dessen Programmierer, die nötigen Parameter Standardkonform implementiert und dokumentiert haben. Also im DEC stellst du zb. den CipherMode aud CBC, alles Standard, verschlüsselst damit die Daten und wandelst sie per INet MIME Base64 Standard in lesbaren Text um. Jetzt musst du halt in Erfahrung bringen nach welchem Standard dieses Assembly arbeitet.

Gruß Hagen

[negaH]

Mann ich sehe gerade

Zitat:

Delphi-Quellcode:

with TCipher_Rijndael.Create do
  try
    Mode := cmCBCx;
    Init('');
    OutputStr := EncodeBinary(InputStr, TFormat_MIME64);
  finally
    Free;
  end;

.Init('') ? Du benutzt kein Passwort ?

Gruß Hagen

[dfried]

Zitat:

Zitat von negaH

- Schlüsselgröße für AES
- Umwandlungsfunktion des Passwortes in einen Sessionkey, falls verwendet
- Ciphermode, wie CBC oder ECB usw.
- verwendete Textformate um binäre Daten darzustellen

Ich werd mir das Assembly mal diesbezgl. genauer ansehen, zumindest laut MSDN ist der Ciphermode standardmässig CBC, die Schlüsselgröße 256bit und das Textformat Base64.

Zitat:

Zitat von negaH

.Init('') ? Du benutzt kein Passwort ?

Für den ersten Test nicht, ist das wichtig (bestimmt das vielleicht die Schlüssellänge)?

[Bernhard Geyer]

Evtl. könnt es auch daran liegen das der default-Character unter Delphi 1 Byte groß ist und unter .NET 2 Byte!

[dfried]

Zitat:

Zitat von Bernhard Geyer

Evtl. könnt es auch daran liegen das der default-Character unter Delphi 1 Byte groß ist und unter .NET 2 Byte!

Du meinst, ich sollte unter .Net den String zuerst noch von UTF8 in einen SingleByte Zeichensatz umwandeln bevor ih Ihn verschlüssle?

[Bernhard Geyer]

Zitat:

Zitat von dfried

Zitat:

Zitat von Bernhard Geyer

Evtl. könnt es auch daran liegen das der default-Character unter Delphi 1 Byte groß ist und unter .NET 2 Byte!

Du meinst, ich sollte unter .Net den String zuerst noch von UTF8 in einen SingleByte Zeichensatz umwandeln bevor ih Ihn verschlüssle?

Ich meine primär das du diesen unterschied berücksichtigen solltest. Ob du nun die Delphi-Seite anpaßt um mit Widestrings zu arbeiten oder anpassungen auf der .NET-Seite vornimmst sei dir überlassen.

[blackdrake]

Hallo.

Hat sich das Problem eigentlich gelöst? Sofern es wirklich nur die WideString-Auffassung ist, kannst du es in Delphi einfach mit WideString('test') realisieren. Die Funktion WideString müsste die Chars in WideChars umwandeln (ein #00 wird nach jedem Byte hinzugefügt).

Gruß
blackdrake

[Bernhard Geyer]

Zitat:

Zitat von blackdrake

Die Funktion WideString müsste die Chars in WideChars umwandeln (ein #00 wird nach jedem Byte hinzugefügt).

Falsch. Das €-Zeichen hat unter unsere Codepage den Wert $80 und im Unicode den Wert $20AC .
Und ob die verwendete Komponente auch wirklich einen Widestring direkte verwenden kann oder ihn nur wieder zurückwandelt ...

[blackdrake]

Hallo.

Stimmt. Ich ging mit dem #00 von purem ASCII (ANSI?) aus. Die Umwandlung String -> WideString müsste dann eben mit der Codepage geschehen.

Ich hatte mich ja mal langvirig mit dem Problem auseinander gesetzt, einen WideString mit DEC zu verschlüsseln. Das Ergebnis ist hier: http://www.delphipraxis.net/internal...=768251#768251 . Funktioniert perfekt.

Bitte schreibe uns, ob du einen mit DEC verschlüsselten WideString nun mit der .NET Assembly korrekt entschlüsseln kannst.

Gruß
blackdrake

[Bernhard Geyer]

Zitat:

Zitat von blackdrake

Ich hatte mich ja mal langvirig mit dem Problem auseinander gesetzt, einen WideString mit DEC zu verschlüsseln. Das Ergebnis ist hier: http://www.delphipraxis.net/internal...=768251#768251 . Funktioniert perfekt.

Stimmt, da war ja was :gruebel:

[dfried]

Zitat:

Zitat von blackdrake

Ich hatte mich ja mal langvirig mit dem Problem auseinander gesetzt, einen WideString mit DEC zu verschlüsseln. Das Ergebnis ist hier: http://www.delphipraxis.net/internal...=768251#768251 . Funktioniert perfekt.

Bitte schreibe uns, ob du einen mit DEC verschlüsselten WideString nun mit der .NET Assembly korrekt entschlüsseln kannst.

Bis jetzt noch nicht :-(
Aber mit deiner Erweiterung von DEC sind zumindest schonmal die Verschlüsselten Strings gleich lang, dann kann es jetzt eigentlich nur noch am Key oder IV liegen damit es funktioniert, ich melde mich, sobald es was neues gibt.

[negaH]

Der Key und IV können nicht direkt als WideStrings benutzt werden, das sind immer Array of Byte. Das ist einfach eine Frage des Algorithmus und die arbeiten mit binären Daten. Falls also zb. eine Bibliothek ein zb. 16 Zeichen Passwort als Widestring dem Cipher übergibt dann würde man real ein 32 Bytes Passwort benutzen das an jeder 2. Stelle eine 0 enthielte. Sicherheitstechnisch betrachtet wäre dies grob fahrlässig da so die Sicherheit drastisch reduziert würde.

Ich denke aber mich dunkel erinnern zu können das .NET im Grunde 1 zu 1 kompatibel mit DEC ist, bis eben auf den Punkt das die Daten die man verschlüsseln will als expandierte WideStrings verschlüsselt werden. Bei den Schlüsseln und IV's ist dies aber nicht der Fall.

Gruß hagen

[Alexander]

Evtl. liegt es auch an den Padding's, die man zumindest bei den .NET Funktionen einstellen kann.