Kompatibilität DEC Rijndael, Lockbox RSA zu z.B. C#

[schinger]

Hallo zusammen,

hab hier im Forum schon eine Menge an Informationen zum Thema Verschlüsselung gefunden und hoffe nun, dass Ihr mir
etwas weiterhelfen könnt.

Meine Frage also:

Im Moment benutze ich die Rijndael-Verschlüsselung aus dem DEC als symmetrische und RSA aus Lockbox als asymmetrische Verschlüsselun g in einer Client-Server Applikation (WebService Client und Service selbst). Da ich nun beide Anwendungen selbst schreibe und in beiden die gleichen Komponenten verwende, funktioniert das auch wunderbar. Meine Frage ist jetzt nun, wenn nun jemand einen z.b. C# Client für den WebService schreibt, in wie weit sind dann die Verschlüsselungsalgorithmen kompatibel.
Will sagen, wenn der Client nun eine andere Implementation von Rijndael verwendet, da es die lockbox ja nur für Delphi gibt, funktioniert dann die Verschlüsselung trotzdem oder kann es da zu Problemen kommen. Wenn ja zu welchen und welche Lösungen gibt es in diesem Fall.

Danke schon mal für euere Hilfe.

Gruss

Markus

[Bernhard Geyer]

Theoretische sollte eine Verschlüsselung unabhängig von der Implementierung und Programmiersprache sein.
Aber Teste es lieber. Nicht jede Implementierung ist das wirklich sondern "nur" zu sich selbst kompatible da irgendwelche Compilereigenheiten/Blockgrößen fehlerhaft berücksichtigt wurden. wurden

[schinger]

Danke für die Antwort.

Ich hatte allerdings gehofft, dass jemand dazu vielleicht schon Erfahrungswerte hat.

Vielleicht kann ja auch Hagen, der dankenwerterweise das DEC ja zur Verfügung gestellt hat, was dazu sagen. Sonst müsste ich jetzt erst weitere Testanwendungen schreiben.

Also falls jemand schon Erfahrungen dazu hat, z.b. mit C# oder auch java, wäre ich sehr dankbar.

Gruss

Markus

[negaH]

Sie müssen kompatibel sein, rein Algorithmisch gesehen. ABER! alles was ausserhalb des reinen AES Algos. liegt ist Definitionssache, dh. zb. das Protokoll wie man den übergebenen Schlüssel in einen sicheren Sessionkey umwandelt kann sehr unterschiedlich sein. Das gleiche gilt für die IVs=Init Vektoren.

Du solltest folgendes berücksichtigen:

1.) nur Cipher Modis cmCBC, cmECB, cmOFB etc. pp. verwenden.
2.) NIEMALS Cipher Mode cmCTS verwenden da das eine Eigenentwicklung meinerseits ist. Sie basiert zwar auf dem Standard Modus CBC ist aber kein Standard selber.
3.) den Cipher mit .Init() initialisieren und nicht mit .InitKey(). Die Methode Init() benutzt den Schlüssel so wie er ist. Die Methode .initKey() wanelt per Hashfunktion den Key vorher in einen Sessionkey um. Dieses Umwandlung ist zwar standardmäßig empfohlene Praxis, aber jede Library kocht da ihr eigenes Süppchen WIE sie es umwandelt.
4.) Das Padding der Nachricht auf ein Mehrfaches der Blockgröße. DEC benutzt Cipher Text Stealing im CBC Modus. Die Art&Weise wie nun dieses durchgeführt wird ist noch nicht standardisiert. Nur die neuesten Cipher Modis habe das auch in ihren Standards berücksichtigt. Am besten ist es erstmal mit Nachrichten der Länge Cipher.BlockSize * x austesten. Wenn beide Resultate identisch sind dann mit ungepaddeten Daten nochmal probieren. Meistens unterscheidet sich dann der letzte Block der verschlüsselten Nachricht, je nachdem welches Paddingschemata verwendet wurde.
5.) praktisch Testen! Um einen solchen Test kommst du niemals drumherum.

Gruß Hagen

[schinger]

Hallo,

danke für die Antwort, hab sie leider jetzt erst gelesen.
Werd wohl wirklich nicht um einen Test herum kommen.
Gibt es denn schon jemanden der Erfahrungen mit dem DEC/Verschlüsselung und Kommunikation mit implementation von z.b. Rijndael in anderen Sprachen z.B. c# hat, das wäre sehr hilfreich für mich.

Vielen dank schon mal.

Gruss

schinger

[Phoenix]

Mal ne andere Sache.. warum portierst Du nicht den Delphi-Code nach Delphi.NET, machst ein Assembly und benutzt den dann tatsächlich identischen Code aus C# raus? Ich denke das schliesst zumindest schonmal einige der möglichen Fehlerquellen aus.

[Elvis]

Zitat:

Zitat von Phoenix

Mal ne andere Sache.. warum portierst Du nicht den Delphi-Code nach Delphi.NET, machst ein Assembly und benutzt den dann tatsächlich identischen Code aus C# raus? Ich denke das schliesst zumindest schonmal einige der möglichen Fehlerquellen aus.

Ja klar, er kompiliert eine DCU-only Bibliothek wie DEC mit D.Net? ;)
Selbst wenn er die Saucen hätte wäre der Code nicht kompilierbar, außer er kapselt das DEC in einer DLL.

Dieses D32->D.Net Rekompilieren sollte man bitte mit etwas mehr Vorsicht genießen als es uns so mancher Borland-Zealot glauben machen will.
Lass ihn doch einfach DEC-verschlüsselte Daten vom RSACryptoServiceProvider entschlüsseln und vice versa. Wenn's geht, gates. ;)

[negaH]

Naja, ganz so dramatisch ist es nun auch wieder nicht.

DEC Part I liegt sehr wohl als Source vor, sogar als Freeware. Und es ging hier nur um Bestandteile des Part I.
Desweiteren enthält gerade die neueste Version reine PASCAL Sourcen und per Compilerswitches separat aktivierbaren Assemblercode. Zusätzlich habe ich gerade in dieser neuen Version darauf geachtet die vielen in .NET unerwünschten Zeiger und Sourcekonstrukte zu ersetzen. Nach meiner Meinung nach müsste DEC Part I eigentlich in weiten Teilen sofort in .NET compilierbar sein.

Das was du als reine DCU Distributation kennst ist eigentlich der Part II vom DEC. Das sind nur die Sourcen des sogenannten DECMaths und dessen Bestandteile die nicht frei sind.

Diese werden aber in keinster Weise für obiges Problem benötigt.

Gruß Hagen

[schinger]

Hallo,

danke für eure Antworten und Anregungen.
Ich schildere kurz nochmal mein Problem und würde mich freuen, wenn Ihr dazu was sagen könnten.

Also das Grundproblem ist folgendes:

Verschlüsselung mit Rijndael (DEC) auf Delphiseite. Nun meine Frage. Kann nun jemand meine verschlüsselten Daten problemlos z.B.
mit einer C# -Anwendung wieder entschlüsseln, vorausgesetzt er weiss das verwendete Passwort ;-).

Hat jemand schon damit, oder mit nem ähnlichen Problem, Erfahrung gemacht, und/oder was gibt es da zu beachten?

Ich hab irgendwo gelesen, dass man bei C# neben dem richtigen Passwort auch noch einen Initialisierungverktor braucht. Bei DEC braucht man doch nur das Passwort?

Also danke schon mal.

Gruss

Schinger

[negaH]

Zitat:

Verschlüsselung mit Rijndael (DEC) auf Delphiseite. Nun meine Frage. Kann nun jemand meine verschlüsselten Daten problemlos z.B.
mit einer C# -Anwendung wieder entschlüsseln, vorausgesetzt er weiss das verwendete Passwort .

Einfache Antwort:

Theoretisch JA zu 100%,
praktisch JAIN und eher 80% Wahrscheinlichkeit das irgendwas nich ganz hinhaut.

Zitat:

Hat jemand schon damit, oder mit nem ähnlichen Problem, Erfahrung gemacht, und/oder was gibt es da zu beachten?

Ja ich. Die Sache ist so das man sehr sehr genau darüber bescheid wissen muß WAS WIE in der jeweiligen Library gemacht wird. Es gibt zwar Standards aber wie so oft hält sich daran keiner und erst recht die sogenannten "Big Player" wie Microsoft koxchen sehr gern ihr eigenes Süppchen.

Ich habe die Algorirthmen im DEC absichtlich alle mit den Standard Text Vekroren getestet. Sie sind kompatibel wenn da nicht das klitzekleine Problemchen wäre das es
a.) oft garkeine zertifizierten und vom Autor des Algos herausgegebene Testvektoren gibt
b.) es oft wiedersprüchliche Testvektoren gibt, zb. beim Blowfish kursieren zwei Versionen jeweils für Big Endian und Little Endian und Bruce Schneier hat sich meines Wissens nach nie geäußert ob sein Algo nun Big- oder Little Endian ist.

Zitat:

Ich hab irgendwo gelesen, dass man bei C# neben dem richtigen Passwort auch noch einen Initialisierungverktor braucht. Bei DEC braucht man doch nur das Passwort?

Nicht zwangsläufig :) DEC unterstützt in der alten Version zwei verschiedene Methoden zum Schlüsselsetup.
1.) die einfache und alles inklusive Methode .InitKey() die gerade für Anfänger einige zusätzliche Berechnungen durchführt. Diese Methode IST und KANN auch nicht kompatibel zuirgendwas anderes sein, da es im Grunde eben keine verbindlichen Standards gibt (zumindestensnicht vor 5 Jahren).
2.) die einfache und "Basic" methode .Init() bei der der Programmierer eben selber noch einiges an Preprocessing durchführen muß.

Benutzt man 2.) dann MUSS das erzeugte Resultat bei gleichen Parameteren auch gleiche Outputs erzeugen.

Am wichtigsten ist es zu bedenken das DEC eine Algorithmen Bibliothek ist. Also wie ein Werkzeugkoffer oder Baukasten aber nicht ein fertiges Motorad.

Man muß aber auch bedenken das die meisten Crypto Libraries nur solche Baukästen darstellen. Das bedeutet ob du es willst oder nicht du als Programmierer musst die zusäzliches Wissen erarbeiten, die entsprechenden Betriebsparamter zb. in C# ermitteln und dann beide Systeme aufeinander abgleichen.

Eine professionelle Cryptolibrary wie die von RSAInc. oder so kostet einen rießigen Batzen Geld (nicht umsonst).

Gruß Hagen

[negaH]

Man muß auch unterscheiden um was für Algorithmen es sich dreht.

Bei den Hashalgorithmen kannst du mit 100% davon ausgehen das sich gute Implementierungen wie ein Ei demanderen gleichen.
Das gleiche gilt bei CRCs, Cyclic Redundance Checksums, wenn man die richtigen Parameter, sprich Polynome benutzt.

Bei den Zufallsgeneratoren wird es schon wieder schwieriger das es oft mehrere Versionen vom gleichen Autor gibt, oder von anderen Autoren einfach mal par Details verändert wurden (oder Fehler reingebastelt).

Bei den sym. Verschlüsslungen wird ein verifiziertes System im ECB Modus ohne Padding und Initvektor mit gleichem Passwort mit sehr sehr hoher Wahrscheinlichkeit auf Anhieb laufen. Das gleiche gilt noch für CBC und OFB/CFB solange der gleiche IV benutzt wird und das Keysetup noch identisch ist. Bei den letztgenannten Modis entsteht aber schon das problem mit welchem Padding Schemata die Nachricht expandiert wurde.

Das eigentliche Problem entsteht aber wenn das alles kombiniert wird und mit einem Protokoll versehen dazu benutzt wird eine Datei zu verschlüsseln. Dies Datei enthält einen Header, Prüfsummen, Salts etc.pp. Exakt hier entstehen die meisten "Mißverständnisse" die einen glauben lassen das ein kryptrographischer Algorithmus aus einer Library nicht richtig funktionieren würde.

In fact kann ich aus meiner Erfahrung heraus folgendes sagen: von den vielen hunderten Mails die ich beantwortet habe bezüglich Problemen mit DEC waren vielleicht 5 oder 6 wirkliche Fehler im DEC selber. Die meisten Fehler waren solche bei denen der Hilfesuchende einen Text nicht korrekt ver-entschlüsseln konnte der zb. durch JAVA7Perl/C oder so erzeugt wurde. Fast IMMER lag es daran das der Fragende zb. Sonderzeichen wir Carrige Returns etc.pp. eingefügt oder entfernt hatte. Auch häufig trat das Problem mit Big- und Little Endian Daten auf oder das ein Hilfesuchender einen HEX Formatierten String 1 zu 1 als Passwort benutzen wollte ohne diesen HEX String vorher nach binär umzuwandeln.

Kurz gesagt: die realen Probleme zwischen den Cryptosystemen in punkto Kompatibilität sind im Grunde verschwindend gering wenn man die richtigen Informationen hat, die Systeme korrekt anwendet und ansonsten nicht die vielen äußeren Schusseligkeitsfehler macht.

Das Problem ist halt das wenn man zb. 1+1 rechnet und 3 rausbekommt dies immer noch nahe an der 2 ist. In der Kryptographie ist das aber meistens nicht so. Wenn da nur 1 Bit im Schlüssel falsch ist stimmt am Resultat nichts mehr Hinten noch Vorne.


Gruß Hagen

[schinger]

Hallo Hagen,

danke für die Antworten.

Sie stimmen mich jetzt nicht so positiv wie erhofft, aber ich denke sie helfen mir doch deutlich weiter.

Da du ja wie gesagt schon Erfahrung mit anderen Implementationen gesammelt hast, kannst du mir vielleicht eine konkrete Library oder Implementation in z.B. C# oder auch in ner anderen (Microsoft'schen) Sprache nennen, mit der du es erfolgreich geschafft hast, und mit der auch ich als Anfänger auf dem Gebiet das hinkriegen könnte. Das würde mir für meine Tests erheblich helfen.

Also vielen Dank schon mal.

P.S. Hast du/oder auch jemand anderes der diesen Beitrag liest auch Erfahrung mit RSA aus der Lockbox-Library.
Hier geht es hauptsächlich darum den Public-Key zu Übertragen und damit was zu verschlüsseln. In der Doku steht, dass er in dem Standardformat ASN.1 exportiert werden kann.
Was ich an Infos zu Microsoft-Crypto-Lib hab werden dort aber die Keys als XML exportiert. Hab auch irgendwo gelesen, dass man auch die Teile (Exponent und Modulo richtig??) exportieren kann. Meinst du mit diesen Infos könnte ich mir den Key dann in Lockbox wieder zusammenbauen?


Gruss

Schinger

[negaH]

Hi Schinger,

die Kernaussage meiner ganzen Postings ist
"Du must das selber verstehen und auch dann umsetzen und verifizieren". Eine Library ist eine Library und kein fertiges Produkt. Würdest du dein Auto zu einem in die Werkstatt geben der die ganz deutlich sagt "aber ich bin ein Anfänger" ?


Für C# kenne ich keine Sourcen, da ich damit bisher noch nicht im Kryptogaphiesektor gearbeitet habe.

Lockbox halte ich für keine so gute Bibliothek, eben besonders im Hinblick auf RSA etc.pp. Allerdings muß man dies relativ sehen:

1.) sind meine Ansprüche und mein Verständniss der Sache eine ganz andere wie die der meisten
2.) ist Lockbox, dafür das es Freeware ist, immer noch die für Delphi 2. beste verfügbare Freeware in diesem Sektor

Du könntest dir auch StreamSEC II von Hendrik Hellström anschauen. Hendrik hat enormen Wert darauf gelegt sich an den Standards zu orientieren, und in StreamSec hast du alles integriert.

Gruß Hagen

[schinger]

Hallo,

danke nochmals für deine Antworten.

Ich werd das in der nächsten Zeit alles mal ausprobieren.

Wenn ich auf Probleme stosse, weiss ich jetzt ja wo ich dich finde ;-)

Gruss

Schinger