Entwickler-Ecke

Delphi Language (Object-Pascal) / CLX - String mit Passwort verschlüsseln


colaka - Mi 14.05.14 07:57
Titel: String mit Passwort verschlüsseln
Hallo,

ich möchte einen String, der ungefähr 30 bis 100 Zeichen lang ist, mit Hilfe eines einfachen, kurzen Passworts verschlüsseln und später durch Eingabe des Passworts wieder entschlüsseln können. Die Sicherheit spielt dabei eigentlich keine große Rolle, aber der verschlüsselte String soll länger sein als das Original.

Mir wäre es am liebsten, wenn das mit Delphi Standardkomponenten machbar wäre.

Ich habe schon die Suche benutzt, aber nur ziemlich aufwendige Methoden gefunden.


jasocul - Mi 14.05.14 08:05

Suche doch mal bei Google:Suche bei Google DELPHI STRING VERSCHL?SSELUNG EINFACHE
Da sind reichlich Treffer.


colaka - Mi 14.05.14 09:11

Vielen Dank für die schnelle Antwort.

Die Suche hatte ich bereits vorher benutzt, aber ich bin nur auf Methoden gestossen, bei denen der verschlüsselte String genauso lang war wie das Original. Ich möchte aber, dass der verschlüsselte String länger wird. Oder gibt es sowas nicht?


ub60 - Mi 14.05.14 09:13

user profile iconcolaka hat folgendes geschrieben Zum zitierten Posting springen:
aber der verschlüsselte String soll länger sein als das Original.
Um wieviel soll er denn länger sein und warum? Konkrete Angaben (Beispiel für Ausgangslänge, Wunschlänge) wären sinnvoll.

user profile iconcolaka hat folgendes geschrieben Zum zitierten Posting springen:
Mir wäre es am liebsten, wenn das mit Delphi Standardkomponenten machbar wäre.
Dazu benötigt man keine Komponenten, das sind nur wenige Zeilen Quelltext.

ub60


Blup - Mi 14.05.14 09:17

Einfach vor dem Verschlüsseln davor und/oder dahinter zufällige Zeichen anhängen und beim Entschlüsseln wieder entfernen.
So etwas nennt sich wohl "Salt".


jasocul - Mi 14.05.14 10:13

user profile iconBlup hat folgendes geschrieben Zum zitierten Posting springen:
Einfach vor dem Verschlüsseln davor und/oder dahinter zufällige Zeichen anhängen und beim Entschlüsseln wieder entfernen.

Das erschien mir so klar, dass ich nicht davon ausgegangen bin, dass man das erklären muss.


Popov - Mi 14.05.14 14:49

@colaka

Wenn dich nicht stört, dass der Text doppelt so lang wird, einfach in Hex konvertieren. Zufällig habe ich in meinem Beispielordner was gefunden:

Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
function TextToHex(S: AnsiString): AnsiString;
var
  i: Integer;
begin
  Result := '';
  for i := 1 to Length(S) do
    Result := Result + IntToHex(Ord(S[i]), 2);
end;

function HexToText(S: AnsiString): AnsiString;
var
  k: Integer;
begin
  Result := '';
  k := 1;
  while k <= Length(S) do
  begin
    Result := Result + Chr(StrToInt('$' + Copy(S, k, 2)));
    Inc(k, 2);
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  s: String;
begin
  s := TextToHex('Hallo Welt');
  ShowMessage(s);
  s := HexToText(s);
  ShowMessage(s);
end;


Alternativ könntest du auch in Base64 konvertieren, ist aber schon etwas komplexer.

Wenn die Verschlüsselung keine wichtige Rolle spielt, würde ich ROT13 nehmen.


LuMa86 - Mo 26.05.14 21:23

Warum nicht mit der RCx-Unit [http://www.delphipraxis.net/140859-rcx-verschluesselung.html] aus der DP? Sollte eigentlich wunderbar klappen.

Gruß


GuaAck - Mo 26.05.14 23:38

Ich nutze den XTEA-Algorithmus, den ich vor einigen Jahren gefunden hatte. Es ist ein 128-Bit-Schlüssel, nach meinem Eindruck (bin kein Crypto-Fachmann) ist das Verfahren gegenüber Hobby-Angreifern sicher. Und der Code ist sehr kompakt.

Ich habe mir damit eine CLASS(TFilestream) gemacht, so dass ich verschlüsselte Dateien ganz normal schreiben und lesen kann, ohne dass eine unverschlüsselte Datei auf der Festplatte entsteht. (OK, Swapping könnte sein...)

Anbei der Code, vermutlich opensource, besser aber mal suchen, ob es Beschränkungen gibt.

Gruß GuaAck


Gammatester - Di 27.05.14 11:56

Hallo GuaAck,

Für den Hausgebrauch ist Deine XTEA-Unit wahrscheinlich geeignet. Allerdings unterstützt sie wohl nur den bösen ECB-Modus und wird selbst dafür Probleme haben, wenn Du Daten von anderen verarbeiten willst, weil sie offensichtlich nicht in das standardmäßige Big-Endian konvertiert.

Hier zwei Beispiele (alle in Hex) von bekannten Implementation, beide bestätigt durch CryptoBench und meine eigene Unit:

Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
Botan:
key:    00112233445566778899AABBCCDDEEFF 
plain:  0123456789ABCDEF
cipher: B8BF2821622B5B30

Bouncy Castle:
k: 0123456712345678234567893456789A
p: 0102030405060708
c: 8c67155b2ef91ead

Es ist mir nicht gelungen, aus Deiner Unit irgendetwas herauszubekommen, das den Sollwerten ähnlich sieht.


GuaAck - Di 27.05.14 21:12

Hallo Gammatester,

viele Dank, interessante Einwände. Das mit dem Hausgebrauch stimmt schon, aber ich denke, Hobby-Knacker haben keine Chance, und für Profis ist es nicht lohnend.

Ich nutze das Verfahren um z. B. eine kleine Datenbank mit personenbezogenen Daten(sehr unkritisch, gerade eben oberhalb der Schwelle, ab der Schutz erforderlich ist, die Daten habe ich auch alle noch auf Papier in Leitz-Ordner in einem verschlossenen Büro-Schrank, Schlüssel oben rechts in meinem unverschlossenen Schreibtisch) auf einem normalen PC (offen, ohne Password usw.) zu nutzen.

Der Code ist nicht von mir, aber der Aspekt mit Big-Endian ist sehr interessant, habe ich noch nicht drüber nachgedacht, aber auch noch kein Problem mit gehabt.

Hat mich gefreut der Einwand,
beste Grüße
GuaAck