Einfache sprachübergreifende Stringverschlüsselung???

[romber]

Hallo!

Ich weiss, es gibt hier im Forum hunderte Beiträge zum Thema "Strings-Verschlüsselung". Doch eine eindeutige Antwort auf meine Frage habe ich ledier nicht gefunden.

Ich habe einen kleinen TCP-Server, geschrieben in Delphi. Ich möchte die gesammte Kommunikation mit einem schnellen Verschlüsselungsalgorithmus verschlüsseln, das sich ohne großen Aufwand mit den gängigen Prigrammiersprachen realisieren lässt bzw. für das bereits fertige Bibliotheken zur Verfügung stehen. Ich brauche keine 4096Bit Verschlüsselung, mir ist nur wichtig, dass die Daten nicht als lesbares Text übertragen werden und mit jedem Sniffer ohne weiteres gelesen werden können.

Welchen Verschlüsselungsalgoritmus könnt Ihr mit empfehlen?

[blackfin]

Symmetrische Verschlüsselung wahrscheinlich, hm?....hmm....Blowfish ist ein sehr weit verbreiteter Algorithmus.
Oder Serpent, oder 3DES, oder RCx...oder...Cäsar Nein, letzteres dann doch lieber nicht

Ich würde bei Kompatibilität zwischen zig Sprachen denke ich auf Blowfish oder 3DES setzen.
Ausserdem: Was spricht dagegen, mehrere, wählbare Verschlüsslungen für die Paketdaten einzubauen? So schwer ist das ja nicht
Ein kleiner TCP-Server, den ich mal geschrieben habe kann z.B. über ein einfaches Byte im Paket-Header ermitteln, ob die Daten im Paket unverschlüsselt oder per blowfish, serpent oder asymmetrisch verschlüsselt (RSA) vorliegen. Nur so als Denkanstoss vielleicht...
Für asymmetrischhe Verschlüsselung brauchste natürlich vorher noch ein Handshake für den pub-Schlüsseltausch.

[romber]

Vielen Dank für die schnelle Antwort!

Ich probiere es mit Blowfish.

[Deep-Sea]

Zitat von romber:

[...] einem schnellen Verschlüsselungsalgorithmus [...] Ich brauche keine 4096Bit Verschlüsselung [...]

Wäre dann nicht eine Stromchiffre genau das richtige?!


@blackfin:
Wieso schlägst du gerade Serpent vor, und nicht die anderen AES-Finalisten oder AES selbst?

[Daniela.S]

Stand auch einmal vor diesem Problem und musste feststellen, dass das gleiche Verschlüsselungsverfahren mit den gleichen Parametern in .net mit Delphi Prism und Delphi XE nicht das gleiche Ergebnis lieferte.

Zur schnellen Abhilfe habe ich mit .net eine DLL erstellt, die das Verschlüsseln übernimmt und diese am Server in Delphi XE eingebunden.

[Deep-Sea]

@Daniela.S:
Dann war wohl eine der Implementationen falsch. Das ist dann kein Fehler oder Problem vom Algorithmus, sondern vom Programmierer
Dafür gibt es ja auch Testvektoren - man wird ja wohl nicht einfach einen Algorithmus implementieren, nicht testen und statt dessen auf Gott vertrauen, dass alles stimmt?!

[blackfin]

Zitat von Deep-Sea:

@blackFin:Wieso schlägst du gerade Serpent vor, und nicht die anderen AES-Finalisten oder AES selbst?

Ich habe die vorgeschlagen, mit denen ich selbst bisher schon gute "Cross-Language"-Erfahrungen gemacht habe.
Bei AES / Rijndael hatte ich mal ähnliche Probleme wie Daniela S., ausserdem ist AES inzwischen angreifbarer als Serpent. AES ist nur etwas schneller als Serpent, dafür ist letzterer etwas sicherer.

Generell hast du aber recht: Jeder der AES-Finalisten ist erstmal gut geeignet für eine Verschlüsslung, die es wahrscheinlich in guter Implementierung in vielen Sprachen gibt

[Daniela.S]

Dann liegt's vielleicht an dem von uns verwendeten AES/Rijndael, wie blackfin angedeutet hat.

Wenn diese Verschlüsselung jedenfalls gefordert wird, dann sucht man sich nach dem Fehler dumm und dämlich. Ich habe hier genug Zeit verloren und vergeblich Fehler gesucht, da hin und wieder das Ergebnis ein Anderes war. Daher, falls jemand die gleichen Probleme hat, mein Lösungsvorschlag...

[mschaefer]

Die Compiler scheinen mit unterschiedlicher Rechengenauigkeit zu arbeiten. Manchmal liegt es sogar nicht nur am Compiler. Vom 386´er bis zum Pentium habe ich es geschafft mit dem gleichen Programm zur Wetterdatensimulation unterschiedliche Ergebnisse zu bekommen, je nach Prozessortyp, und da war der/die Pentium-Bug noch nicht dabei.

[Deep-Sea]

Rechen(un)genauigkeit? Bei Ganzzahl-Arithmetik? Wohl hoffentlich nicht