Schnelle Verschlüsselung/Entschlüsselung von Strings???

[romber]

Hallo!

Ich übertrage String-Daten (300 - 1.500 Zeichen) vom Server zum Client - bisher als Plain-Text. Die Übetragung ist absolut zeitkritisch. Nun bin ich auf der Suche nach einem schnellen einfachen Verschlüsselunsalgorithmus. Ich brauche keine besondere Sicherheit, mir ist nur wichtig, dass die Daten nicht Plain-Text übertragen werden und möglichst schnell ver- und entschlüsselt werden. Was könnt Ihr mir empfehlen?

[Aphton]

Xor Verschlüsselung (Bit Arithmetik)?!

[shmia]

Hier eine Funktion für die XOR-Verschlüsselung.
Das Ergebnis ist ein String mit binären Daten (auch Hex $0).
Ruft man die Funktion ein 2. Mal auf entsteht wieder der Orginaltext (was im Prinzip der Umkehrbarkeit von XOR liegt).

Für die Übertragung per TCP/IP muss dem Empfänger über ein Längenwort
mitgeteilt werden wie lange die verschlüsselten Daten sind.

Delphi-Quellcode:

function StringXorCrypt(const text, key:Ansistring):Ansistring;
var
   i, j, keylen : Integer;
begin
   SetLength(Result, length(text));
   j := 1;
   keylen := Length(key);
   for i := 1 to Length(text) do
   begin
      Result[i] := AnsiChr(ord(text[i]) xor ord(key[j]));
      Inc(j);
      if j > keylen then j := 1;
   end;
end;

[Popov]

Wenn es dir nur um einen Sichtschutz geht, wie wäre es mit ROT13 Verschlüsselung? Hierbei werden die Buchstaben des Alphabets um 13 Stellen rotiert. Diese Verschlüsselungsart ist alt, bekannt, aber nicht unbedingt sicher, denn sie kann zu Not wieder leicht dekodiert werden. Aber sie ist schnell und bietet einen guten Sichtschutz.

[romber]

Vielen Dank für die schnelle Reaktionen!

@shmia
Muss der Key genauso lang sein wie der zu verschlüsselnde String (so wie es bei XOR vorgeschrieben ist) oder kann ich ein beliebig langes Key verwenden?

[romber]

Zitat:

Zitat von Popov (Beitrag 1159092)

Wenn es dir nur um einen Sichtschutz geht, wie wäre es mit ROT13 Verschlüsselung? Hierbei werden die Buchstaben des Alphabets um 13 Stellen rotiert. Diese Verschlüsselungsart ist alt, bekannt, aber nicht unbedingt sicher, denn sie kann zu Not wieder leicht dekodiert werden. Aber sie ist schnell und bietet einen guten Sichtschutz.

Und wie sieht es dann aus mit den Sonderzeichen?

[shmia]

Zitat:

Zitat von romber (Beitrag 1159093)

Muss der Key genauso lang sein wie der zu verschlüsselnde String (so wie es bei XOR vorgeschrieben ist) oder kann ich ein beliebig langes Key verwenden?

Der Key darf beliebig lang sein. Sollte der Key kürzer als die Nutzdaten sein, wird er wieder beginnend mit dem 1. Zeichen verwendet.
Wenn der Key nur ein Zeichen lang ist, wird jedes Zeichen mit dem gleichen Wert "verXodert".

[romber]

Kann ich AnsiString durch PAnsiChar ersetzen? Sollte dadurch perfomanter werden...

[shmia]

Zitat:

Zitat von romber (Beitrag 1159104)

Kann ich AnsiString durch PAnsiChar ersetzen? Sollte dadurch perfomanter werden...

Na klar, allerdings würde ich nur innerhalb der Funktion mit Zeigern arbeiten.
Ich empfehle vor der Änderung einen kleinen Test schreiben.
Dann kannst du danach sicher sein, dass alles noch in Ordnung ist.

Delphi-Quellcode:

var
  text, key, ctext : Ansistring;
begin
  text := 'das ist der Text, der verschlüssel werden soll'#0#13#10'....1234567890';
  key := 'geheimer key';

  ctext := StringXorCrypt(text, key);

  if StringXorCrypt(ctext, key) <> text then
     raise Exception.Create('Funktion StringXorCrypt() ist defekt');
end;

PS: die Delphi Funktion ist um Welten schneller als der Datentransport über das Netzwerk.
Du fängst jetzt an zu optimieren ohne zu wissen ob das überhaupt notwendig ist.
Man nennt das "premature optimization". siehe auch: http://www.clean-code-developer.de/V...mierungen.ashx

[romber]

Delphi-Quellcode:

Result[i] := chr(ord(Text[i]) xor ord(Key[j]));

Vielleicht noch chr direkt durch AnsiChar ersetzen, ansonsten "Inkompatible Typen: 'AnsiChar' und 'Char'"

Zitat:

Zitat von shmia (Beitrag 1159110)

Du fängst jetzt an zu optimieren ohne zu wissen ob das überhaupt notwendig ist.

Stimmt, ich probiere es erstmal so aus. Im monent wird der String zwar verschlüsselt, aber nur teilweise wieder entschlüsselt.

[Popov]

Zitat:

Zitat von romber (Beitrag 1159096)

Und wie sieht es dann aus mit den Sonderzeichen?

Hier kannst du ein wenig zu dem Thema lesen: http://de.wikipedia.org/wiki/ROT13

Das "besondere" an ROT13 ist, dass es nur eine Prozedur für Ver- und Entschlüsselung gibt. Eigentlich gilt das nur für das reine 26 Zeichen Alphabet. Der Gag dabei ist, dass ein mal rotieren den Text verschlüsselt, noch mal rotieren wieder entschlüsselt. Wenn du noch weitere Zeichen Verschlüsseln willst, mußt du eine Anwandlung von ROT13 schreiben.

[himitsu]

Ich würde noch empfehlen den String vorher in allgemeingültiges und stabiles Format zu konvertieren.
UTF-8 bietet sich da besonders an.
Und erst danach zu verschlüsseln.

Somit kann man die Funktion für ANSI und Unicode verwenden und für beide Codierungen wäre alles sogar kompatibel untereinander.

Ansonsten muß man sich eben auf einen Typen festlegen (meistens AnsiString), aber zukunftssicher wäre es dann nicht unbedingt.

[BUG]

Wenn man schon etwas Arbeit hereinsteckt: warum nicht RC4?
Das eigendliche Codieren sollte damit schnell genug sein und man hat ein erprobtes und bekanntes Verfahrenen.

[Bummi]

http://www.delphi-forum.de/viewtopic...=563952#563952

[generic]

Zitat:

Zitat von romber (Beitrag 1159079)

vom Server zum Client

Welches Protokoll?

Wenn du TCP nutzt, dann nutz doch einfach SSL. Das ist fertig und "sicher".

[romber]

Zitat:

Zitat von generic (Beitrag 1159205)

Welches Protokoll?

TCP (IdTCPServer/IdTCPClient)

Zitat:

Zitat von generic (Beitrag 1159205)

Wenn du TCP nutzt, dann nutz doch einfach SSL. Das ist fertig und "sicher".

Habe auch daran gedacht. Ist SSL nicht zu langsam für mein Vorhaben?

[Valle]

Also ich würde mich BUG und generic hier anschließen. Wenn du hier wirklich etwas verschlüsseln willst, dann sollte das auch einigermaßen sicher sein. Sonst kannst du dir die Arbeit auch sparen. XOR und ROT13 sind keine sinnvollen Techniken hier. Du lernst und bekommst mehr, wenn du richtig verschlüsselst. Je nach dem, welche Komponenten du bisher nutzt (mit Indy sollte das einfach sein), bist du mit SSL schnell fertig und auf der absolut sicheren Seite.

Was die Geschwindigkeit angeht: Ich glaube nicht dass die Verschlüsselung hier der Flaschenhals ist. Du kennst vielleicht SSH, ein verschlüsseltes Protokoll zur Administration eines Servers. Dazu gibt es auch SSHFS, damit kann man auf die Dateien des Servers zugreifen. Außerdem unterstützt SSH verschlüsselte Tunnel, quasi Proxy. Das alles habe ich schon sehr oft verwendet, zum Teil in Gigabit Netzwerken, und konnte keine Geschwindigkeitsverluste erkennen.

Liebe Grüße,
Valentin

[generic]

Ich meine immer: Warum das Rad neu erfinden, wenn man gleich los fahren kann.

[Perlsau]

Zitat:

Zitat von romber (Beitrag 1159079)

Nun bin ich auf der Suche nach einem schnellen einfachen Verschlüsselunsalgorithmus. Ich brauche keine besondere Sicherheit, mir ist nur wichtig, dass die Daten nicht Plain-Text übertragen werden und möglichst schnell ver- und entschlüsselt werden. Was könnt Ihr mir empfehlen?

Ich verwende meist TJvVigenereCipher aus der Jedi-Library. Damit hab ich mal ein Testprogramm geschrieben, um einem Kunden zu demonstrieren, daß man auch mit MSAccess Daten sicher speichern kann.

[Aphton]

@Valle

Zitat:

Ich brauche keine besondere Sicherheit, mir ist nur wichtig, dass die Daten nicht Plain-Text übertragen werden und möglichst schnell ver- und entschlüsselt werden

- keine besondere Sicherheit
- Hauptziel: keine Plain-Text-Übertragung
- Effizienz

Also warum mit Raketen auf Spatzen schießen?

[BUG]

Wieso auf Spatzen schießen, die schon im Käfig sitzen? SSL ist ja schon fertig.

Und bezüglich "Kanone": RC4 hast du genauso schnell implementiert wie die ganzen "billigen" Lösungen.

[Aphton]

Ne, damit will ich aber nicht verneinen, dass es einfach implementierbar ist.
Eine Xor Verschlüsselung alleine - ohne die Substitutions Box (und deren Handhabung/Overhead -> RC4) ist einfach schneller implementiert!

=P

[Valle]

Zitat:

Zitat von Aphton (Beitrag 1159260)

- keine besondere Sicherheit
- Hauptziel: keine Plain-Text-Übertragung
- Effizienz

Es gibt keine "keine besondere Sicherheit". entweder es ist sicher oder eben nicht. Mit XOR oder ROT13 brauch man hier gar nicht erst anfangen. Wer sich für den Inhalt interessiert, der wird sich davon nicht abbringen lassen.

Vielleicht verrätst du, romber, uns, um was es konkret geht? :)

Aber ich will hier nicht darüber streiten. Meiner Meinung nach macht man es entweder ganz oder gar nicht. Aber es ist natürlich die Entscheidung des TEs.

Liebe Grüße,
Valentin

[Aphton]

Jo, jedem das seine...

Zitat:

entweder es ist sicher oder eben nicht

Nun, das ist relativ zu betrachten.
Gegen den 0815 Programmierer / User ist das schon eine effektive Methode, gegen einen Kryptoanalytiker nicht!

Ich interpretiere das ganze so, dass er die Daten eigentlich nur unleserlich machen will und mehr nicht!

[romber]

Zitat:

Zitat von Valle (Beitrag 1159277)

Vielleicht verrätst du, romber, uns, um was es konkret geht? :)

Ja sicher doch :-) Es geht um eine branchenspezifische Client-Server-Anwendung für eine mittelgroße Versicherungsagentur. Über eine Schnittstelle (bzw. über mehrere Schnittstellen) bekommt der Server Daten, die er möglichst zeitnah (kritisch) an die Clients weiterleiten muss, die diese Daten aboniert haben. Das ganze passiert innerhalb eines Unternehmens. Da es bei dem Teil der Daten um personenbezogene Angaben handelt, ist es eine der Bedingungen, dass die Daten verschlüsselt übertragen werden. So sieht es aus.

Zurück zu SSL. Das wäre eigentlich die einfachste und zugleich auch noch eine der sichersten Varianten. Ist SSL schnell genug? Wer hat Erfahrungen damit bei ähnlichen Aufgaben?

[Furtbichler]

Es eigentlich gibt keine Geschwindigkeitseinbußen.

Allerdings wäre es denkbar, das auf einem 286er PC, kombiniert mit einem TBit-Netz, Performanceverluste auftreten.

[cookie22]

Zitat:

Zitat von Valle (Beitrag 1159277)

Es gibt keine "keine besondere Sicherheit". entweder es ist sicher oder eben nicht. Mit XOR oder ROT13 brauch man hier gar nicht erst anfangen. Wer sich für den Inhalt interessiert, der wird sich davon nicht abbringen lassen.

XOR richtig implementiert, ist theoretisch sogar zu 100% sicher und unkackbar. Nur muss der Schlüssel genauso lang sein wie der zu verschlüsselned Text und muss zufällig erzeugt worden sein.

[Klaus01]

Zitat:

Zitat von cookie22 (Beitrag 1159349)

Zitat:

Zitat von Valle (Beitrag 1159277)

Es gibt keine "keine besondere Sicherheit". entweder es ist sicher oder eben nicht. Mit XOR oder ROT13 brauch man hier gar nicht erst anfangen. Wer sich für den Inhalt interessiert, der wird sich davon nicht abbringen lassen.

XOR richtig implementiert, ist theoretisch sogar zu 100% sicher und unkackbar. Nur muss der Schlüssel genauso lang sein wie der zu verschlüsselned Text und muss zufällig erzeugt worden sein.

Stichwort: OTP (OneTimePad)

Grüße
Klaus

[BUG]

Nur leider sind One-Time-Pads für solche Anwendungen denkbar ungeeignet, weil man dann regelmäßig neue echt zufällige (*) Schlüssel verteilen müsste, die nur den Kommunikationspartnern bekannt sind.
Und wenn selbst RC4 zu schwer ist, dann vermute ich, dass Quantenkryptografie für die Übertragung der Schlüssel nicht in Frage kommt :wink:

(*) Sonst ist es nur so "sicher" wie der Pseudo-Zufallszahlengenerator (zb. RC4 :stupid:). Es gibt Hardware dafür, aber auch das ist Aufwand.

[cookie22]

Es ging um die Aussage von Valle, XOR sei generell unsicher.