Verschlüsselung einer TCP-Verbindung

[xaromz]

Hallo,

ich bin gerade dabei, eine Abstraktionsschicht für Datenbankabfragen zu schreiben. Dazu entwickle ich in Delphi.Net einen Server, der Abfragen über TCP entgegennimmt und die Ergebnisse wieder ausgibt.
Da die TCP-Verbindung nicht nur lokal, sondern auch über der Internet erfolgen soll, würde ich gerne den Datenstrom verschlüsseln.
Leider habe ich bis jetzt keine Routine gefunden, die eine Verschlüsselung unter .Net erlaubt (es gibt da zwar was im Netz, aber sehr teuer).
Die Art der Verschlüsselung ist eher zweitrangig, es sollte nur eine vernünftige sein (also kein XOR oder sowas, eher Public-Key, Blowfish, AES...).

Kennt jemand Routinen oder kann mir einen Tipp geben, wie ich sowas selbst implementiere? Leider hab ich von diesem Thema nicht viel Ahnung, sonst würde ich mich mal durch's DEC wühlen (Btw., Hagen könnte doch das DEC mal für .Net umsetzen :wink: ).

Ach ja, auf der anderen Seite (Client) läuft eine ganz normale Win32-Anwendung. Die soll natürlich auch ver- und entschlüsseln können, aber da gibt's ja genügend Klassen. Trotzdem freue ich mich über Empfehlungen.

Gruß
xaromz

[mkinzler]

Das .Net-Framkework bietet doch unter dem Namespace System.Security.Cryptography.* eigene Verschlüsselungsfunktionalitäten.
Im speziellen unter System.Security.Cryptography.X509Certificates.

[xaromz]

Hallo,

Zitat:

Zitat von mkinzler

Das .Net-Framkework bietet doch unter dem Namespace System.Security.Cryptography.* eigene Verschlüsselungsfunktionalitäten.
Im speziellen unter System.Security.Cryptography.X509Certificates.

Danke für den Hinweis. Ich hab mit .Net erst letzte Woche angefangen, daher kenn' ich den Umfang noch nicht ganz. Werd' ich mir mal anschauen.

Gruß
xaromz

[xaromz]

Hallo,

ich bin jetzt einen Schritt weiter. Testweise benutze ich jetzt Rijndael (AES) zum Verschlüsseln. Leider stoße ich da auf ein kleines Problem:
Wenn ich in .Net einen String der Länge 8 Byte verschlüssele, so ist das verschlüsselte Ergebnis 16 Byte lang. Wenn ich den gleichen String aber im DEC verschlüssele, so ist das Ergebnis nur 8 Byte lang. Ich hab' da so meine Zweifel, dass ich damit eine funktionierende Kommunikation hinbekomme :? .

Hat jemand auf diesem Gebiet Erfahrung und kann mir sagen, was da falsch läuft?
Oder anders gefragt: Welche Einstellungen muss ich im TCipher_Rijndael (DEC) resp. im RijndaelManaged (.Net) treffen, damit das Ergebnis kompatibel ist?

Gruß
xaromz

[negaH]

Zitat:

Oder anders gefragt: Welche Einstellungen muss ich im TCipher_Rijndael (DEC) resp. im RijndaelManaged (.Net) treffen, damit das Ergebnis kompatibel ist?

Kurz gesagt: die gleichen !

Das im .NET die Länge der Nachricht 16 Bytes ist deutet darauf hin das .NET ein simples auf 16 Byte Grenze bezogenes Nachrichten-Padding vornimmt. DEC reagiert da "cleverer" und versucht immer die Nachrichtenlänge in Bytes von der originalen Nachricht zur verschlüsselten Nachricht nicht zu verändern. Bei normalem Padding wird dies aber immer der Fall sein und verhindert somit das technologisch einfache und inplaced Verschlüsseln.

Aber! wird im DEC die Nachricht schon vor ihrer Verarbeitung im DEC nach einem spezifischen Paddingschema bearbeitet dann ändert DEC daran später nichts mehr. In deinem Falle heist dies

1.) im .NET nachschauen welches Padding sie benutzen
2.) in deinen Sourcen die Nachricht vor der Verarbeitung selber padden

Warum ist ein solches Padding nicht im DEC ?

Weil es einfach zu viele Arten dieses Paddings gibt. Jeder "Standard" benutzt sein eigenes Verfahren. DEC benutzt sogenanntes Cipher Text Stealing und in der neuesten Version wechselt es aus Sicherheitsgründen sogar den Cipher Modus von einem Block orientiertem zu einem Byte orientiertem Modus. Das macht es weil eine Blockverschlüsselung zur kurzer Nachrichtenblöcke immer unsicherer sein muß als eine Byteweise Verschöüsselung, egal ob man ein Padding benutzt oder Cipher Text Stealing.
Würde DEC sich also auf ein solches Paddingschemas konzentiereren so käme das einer Festlegung der Funktionalität auf diesen einen Standard gleich. Das will ich aber nicht, da es viele Standards gibt die einfach "unsicher" sind.

Gruß Hagen

[xaromz]

Hallo,

Zitat:

Zitat von negaH

Das im .NET die Länge der Nachricht 16 Bytes ist deutet darauf hin das .NET ein simples auf 16 Byte Grenze bezogenes Nachrichten-Padding vornimmt. DEC reagiert da "cleverer" und versucht immer die Nachrichtenlänge in Bytes von der originalen Nachricht zur verschlüsselten Nachricht nicht zu verändern. Bei normalem Padding wird dies aber immer der Fall sein und verhindert somit das technologisch einfache und inplaced Verschlüsseln.

Das war's! Danke.

Gruß
xaromz