kurze Verschlüsselung

[Blumi]

Hi

Ich suche eine kurze Verschlüsselungsmethode. Mit kurz meine ich die Länge des Strings nach der Verschlüsselung.
MD5 wäre optimal in der Länge, nur bringt es mir nichts da der String wieder entschlüsselt werden muss!

Ich habe es mit Verschiebung und Xor miteinander versucht, sieht zwar gut aus , ber beeinhaltet alle Zeichen. Manchmal gibt es dann Probleme das die Zeichen nicht richtig angezeigt werden. Deshalb sollten nur Zahlen und Buchstaben in der Verschlüsselung enthalten sein.

Den String in ASCII Werte umwandeln finde ich nicht so super da der String dann gerade doppelt so lang ist.

Gruss Blumi

[Sharky]

Hai Blumi,

was spricht denn dagegen das der verschlüsselte Text nicht darstellbare Zeigen enthält?
Wenn es aber zingend so seinn muss könntest Du ihn nach dem verschlüsseln zum Beispiel in Base64 "Format" bringen.

Selbstverständlich wird das Ergebniss dann länger sein. Aber das liegt nun einmal in der Natur der Sache.

[Olli]

Moin Blumi,

du mußt dir schon klar werden, ob du eine wirkliche Verschlüsselung willst, dann ist die verschlüsselte Nachricht immer mindestens genauso lang wie die Ausgangsnachricht (und vor allem kannst du dann die Bedingung abschreiben, daß die Zeichen "printable" sein müssen).
Wenn du hingegen nur die Absicht verfolgst, die Nachricht unlesbar zu machen, aber nicht auf Unknackbarkeit wertlegst, dann kannst du auch eine einfache Verschiebung (ala ROT13) nehmen. Das dürfte dann keinen Einfluß darauf haben, ob der Text "printable" ist. Denn es wird nur in einem bestimmten Rahmen "verschoben".

Ansonsten gilt das von Sharky Gesagte!

[Union]

Zitat:

Zitat von Olli

dann ist die verschlüsselte Nachricht immer mindestens genauso lang

Das stimmt nicht, wenn der Verschlüsselungsalgorithmus eine verlustfreie Kompression beinhaltet und der Text sich komprimieren läßt!

[ichbins]

Ein Beispiel für lesbare XOR-Verschlüsselung:

Delphi-Quellcode:

const
  hexes:array[0..15] of char=('0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F');

function hextobyte(hex:string):byte;
var
  i:integer;
begin
  for i:=0 to 15 do
    if hexes[i]=hex[1] then
      result:=16*i;
  for i:=0 to 15 do
    if hexes[i]=hex[2] then
      result:=result+i;
end;

function bytetohex(b:byte):string;
begin
  result:=hexes[b div 16]+hexes[b mod 16];
end;

function encodexor(data,password:string):string;
var
  i:integer;
begin
  result:='';
  for i:=1 to length(data) do
    result:=result+bytetohex(byte(data[i]) xor byte(password[1+(i mod length(password))]));
end;

function decodexor(data,password:string):string;
var
  i:integer;
begin
  result:='';
  for i:=1 to (length(data) div 2) do
    result:=result+char(hextobyte(data[i*2-1]+data[i*2]) xor (byte(password[1+(i mod length(password))])));
end;

Beispielanwendung im Anhang.

[Olli]

Zitat:

Zitat von Union

Das stimmt nicht, wenn der Verschlüsselungsalgorithmus eine verlustfreie Kompression beinhaltet und der Text sich komprimieren läßt!

Für mich sind Packalgorithmen aber keine echten Verschlüsselungsalgorithmen. Sieht so aus als hätten wir hier einen Disput?! Sie ähneln sich sicher, aber es sind keine kryptographischen Algorithmen.
Für mich gibt es nur 2 Fälle: entweder man packt die Ausgangsnachricht und verschlüsselt dann, oder (nicht ganz so clever) man verschlüsselt die Ausgangsnachricht und packt die verschlüsselte Nachricht.

[glkgereon]

Zitat:

Zitat von Olli

Zitat:

Zitat von Union

Das stimmt nicht, wenn der Verschlüsselungsalgorithmus eine verlustfreie Kompression beinhaltet und der Text sich komprimieren läßt!

Für mich sind Packalgorithmen aber keine echten Verschlüsselungsalgorithmen. Sieht so aus als hätten wir hier einen Disput?! Sie ähneln sich sicher, aber es sind keine kryptographischen Algorithmen.
Für mich gibt es nur 2 Fälle: entweder man packt die Ausgangsnachricht und verschlüsselt dann, oder (nicht ganz so clever) man verschlüsselt die Ausgangsnachricht und packt die verschlüsselte Nachricht.

macht die reihenfolge einen wirklichen Unterschied?
doch eigentlich nur wenn die Verschlüsselung die Daten vergrößert.
Wenn die Größe gleichbleibt ist es ne 50%/50% chance wie rum es Platzsparender wäre....

[ripper8472]

die ausgangsdaten lassen sich i.d.r. besser komprimieren.
deshalb erst komprimieren, dann verschluesseln.

[glkgereon]

Zitat:

Zitat von ripper8472

die ausgangsdaten lassen sich i.d.r. besser komprimieren.
deshalb erst komprimieren, dann verschluesseln.

mal ganz naiv: wieso denn das?

[xaromz]

Hallo,

Zitat:

Zitat von glkgereon

Zitat:

Zitat von ripper8472

die ausgangsdaten lassen sich i.d.r. besser komprimieren.
deshalb erst komprimieren, dann verschluesseln.

mal ganz naiv: wieso denn das?

weil eine Verschlüsselung zum Ziel hat, das Ergebnis möglichst gleichmäßig verteilt zu haben. Das macht das Entschlüsseln schwieriger, aber auch das Packen.

Gruß
xaromz
//Edit: Zitat korrigiert