Passwortabfrage bei Verschlüsselung

[Kutter111]

Hallo,

ich benutze dcpcrypt2 zum ver- und entschlüsseln meiner txt-Datei. Das funktioniert auch. Das Problem liegt eher daran, daß ich nicht verstehe wie ich die Passwortabfrage mache. Das heißt, wenn ich die Datei mit einem Passwort verschlüssle und dann wieder entschlüssle, ABER mit einem anderen Passwort, entsteht sozusagen Datenmüll. Wie kann ich das vermeiden und z.B. ein ShowMessage mit der Meldung, daß das Passwort nicht richtig ist, erscheint?
Ich hoffe, daß ich mich nicht zu blöd anstelle, aber ich habe schon viele Seiten in der DP durchgelesen (Danke an Hagen für die ausführlichen Erklärungen der Verschlüsselung), doch nichts hat mir wirklich geholfen.
Vielleicht hat jemand eine Idee.

Vielen Dank im Voraus.

[Dax]

Indem du deinen anstatt der reinen Datei den Stream (Passwort + Datei) verschlüsselst. Wenn du jetzt wieder entschlüsselst und sich eingegebenes und entschlüsseltes Passwort decken, ist das Passwort richtig.

[DP-Maintenance]

Dieses Thema wurde von "sakura" von "VCL / WinForms / Controls" nach "Programmieren allgemein" verschoben.

[Kutter111]

Hallo,
Danke für die schnelle Antwort.
Das Verschlüsseln mache ich über den Stream, aber das Problem ist auch nicht das entschlüsseln, sondern daß die Datei unlesbar bzw. nicht mehr entschlüsselbar wird, wenn ein falsches Passwort eingegeben wird. Deswegen sollte, bevor versucht wird zu entschlüsseln, das Passwort verglichen werden und bei Falscheingabe eine Meldung kommen.
Ich habe das Problem auch bei der Demo der dcpcrypt2 festgestellt.

[Dax]

Du hast offenbar meine Antwort nicht verstanden... Mach das Passwort zum Teil der Datei!

[Kutter111]

Okay...

aber wenn das Passwort in der verschlüsselten Datei ist kann ich es doch nicht mit einem in einem TEdit eingegebenen Text vergleichen, oder doch?
Vielleicht ist ein bisschen Code gut( wie gesagt, aus der Doc von dspcrypt2 etwas abgewandelt):

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
var Cipher: TDCP_rc4;
    KeyStr: string;
    TextInhalt:TStringList;
  begin
    TextInhalt:=TStringlist.Create;
    TextInhalt.LoadFromFile('C:\PW.TXT');
    KeyStr:= '';
    if InputQuery('Passphrase','Enter passphrase',KeyStr) then
    begin
      Cipher:= TDCP_rc4.Create(Self);
      Cipher.InitStr(KeyStr,TDCP_sha1);
      TextInhalt.Text:= Cipher.DecryptString(TextInhalt.Text);
      Cipher.Burn;
      Cipher.Free;
      TextInhalt.SaveToFile('C:\PW.TXT');
    end;
    TextInhalt.Free;
  end;

[Dax]

Du hast meine Antworten nicht verstanden.. :(

Pseudocode mit Strings als Daten:

Delphi-Quellcode:

string Passwort, Daten

Temp := Passwort + Daten;
Temp := Verschlüsseln(Temp);

---

Temp := Entschlüsseln(Temp);
if Copy(Temp, 1, Length(Passwort)) <> Passwort then
  ShowMessage('Passwort falsch!')
else
  Daten := Copy(Temp, Length(Passwort) + 1, Length(Temp));

[Kutter111]

Ich werde das versuchen...
aber wohl erst nach Weihnachten.
Ich gebe aber nicht auf und melde mich dann wieder.

Frohe Weihnachten an alle...

[Kutter111]

Hallo,

leider konnte ich mich erst jetzt wieder meinem Programm widmen.

@Dax: Das Problem ist damit leider nicht aus der Welt, denn das Entschlüsseln des Strings (bei Dir <Temp>) passiert ja dann schon vor dem Prüfen des Passwortes. D.h. der String wäre damit schon nicht mehr entschlüsselbar, und auch nicht mit dem Passwort vergleichbar.
Ich habe es jetzt über einen anderen Weg (die Idee kam mir aber durch Dax Vorschlag, ich weiß seeeehr seltsam...) gelöst. Und zwar verschlüssle ich das Passwort in einer 2. Datei. Vor dem Entschlüsseln der Daten verschlüssle ich das eingegebene Passwort mit dem gleichen Algorythms. Damit kann ich dann den Inhalt der 2. Datei mit dem Passwort vergleichen. Was mir allerdings daran nicht passt, ist: Wenn diese Datei versehentlich gelöscht würde hätte ich keinen Zugriff mehr auf meine Daten. Klar, das Problem hätte ich auch wenn ich die Daten lösche, aber die Chance ist eben höher , da ja dann zwei Dateien zum löschen da sind. Es muß doch noch eine andere Möglichkeit geben das Passwort vor der Entschlüsslung zu überprüfen. Hat noch jemand (Dax natürlich nicht ausgeschlossen;) eine weitere Idee?

[Reinhard Kern]

Zitat:

Zitat von Kutter111

Hallo,

leider konnte ich mich erst jetzt wieder meinem Programm widmen.

@Dax: Das Problem ist damit leider nicht aus der Welt, denn das Entschlüsseln des Strings (bei Dir <Temp>) passiert ja dann schon vor dem Prüfen des Passwortes. D.h. der String wäre damit schon nicht mehr entschlüsselbar, und auch nicht mit dem Passwort vergleichbar.
...

Eben, dann weisst du, dass das Passwort falsch ist. Es ist nur richtig, wenn das entschlüsselte Passwort mit dem eingegebenen übereinstimmt.

Jede weitere Idee ist sinnlos - solange du die Vorschläge nicht verstehtst, besteht keine Hoffnung, dass du dein Problem lösen kannst. Du musst erst mal deine Denkblockade überwinden.

Gruss Reinhard

[Kutter111]

Ohhhhhh Mann!

Na klar, Ihr habt recht. Das ist es. Es ist wirklich zu einfach. Es geht darum die Daten selber nicht anzutasten sondern eine Kopie, diese mit dem eingegebenen Passwort zu entschlüsseln und das Passwort zu vergleichen. Damit wäre die Sicherheit der Daten gewährleistet, auch wenn das Passwort falsch wäre. Jetzt verstehe ich auch Dax Vorschlag. Manchmal hilft eben nur der Hammer!

Danke für die Hilfe, das sind genau die Dinge, die manchmal zum Erfolg führen, obwohl sie nicht ganz offensichtlich für einen sind.

Gruß Kutter111

[mashutu]

Zitat:

Zitat von DAX

Indem du deinen anstatt der reinen Datei den Stream (Passwort + Datei) verschlüsselst. Wenn du jetzt wieder entschlüsselst und sich eingegebenes und entschlüsseltes Passwort decken, ist das Passwort richtig.

Ich frage mich allerdings, ob damit die Sicherheit nicht deutlich eingeschraenkt wird???
Wenn ein Cracker weiss, dass er beim ausprobieren von Pwds oder bei einem Brute-Force-Attack als Result in den ertsen 'n' Zeichen wieder das 'n'-Zeichen lange Pwd findet macht man es ihm schon leicht.

Ich kenne jetzt das dcpcrypt2 nicht, aber IMHO hast Du entweder einen Denkfehler oder ein Designproblem.

[Hador]

Zitat:

Zitat von mashutu

Ich frage mich allerdings, ob damit die Sicherheit nicht deutlich eingeschraenkt wird???

Ganz klar: Ja wird sie.

Das Passwort mit zu verschlüsseln ist Quatsch.

Das Sinnvollste was du machen kannst ist entweder vom Passwort ein Hash zu erstellen und damit das Passwort zu prüfen oder alternativ einen Hash der entschlüsselten Datei anzulegen und die Datei nach dem entschlüsseln prüfen.

Empfehlen würde ich dabei die erstere Methode.

Zum Thema Hash-Verfahren kannst du die bspw. mal md5 angucken

[SirThornberry]

ich würde keine der Varianten nehmen. Denn sobald ein festes Muster beim entschlüsseln vorhanden ist kann per Automatisierung geprüft werden ob das probierte Passwort korrekt ist. Das sichere ist eben, das nur derjenige der die Daten in unverschlüsseltem Zustand kennt, weiß ob die Daten verwertbar sind oder nicht.
Wenn also jemand das richtige Passwort zufällig verwendet aber trotzdem nicht erkennen kann ob das Passwort richtig war oder nicht, dann ist das ganze sicherer als wenn derjenige sofort eine algorythmiche Prüfung hernehmen kann welche die Richtigkeit überprüft.

[Reinhard Kern]

Zitat:

Zitat von SirThornberry

ich würde keine der Varianten nehmen. Denn sobald ein festes Muster beim entschlüsseln vorhanden ist kann per Automatisierung geprüft werden ob das probierte Passwort korrekt ist. Das sichere ist eben, das nur derjenige der die Daten in unverschlüsseltem Zustand kennt, weiß ob die Daten verwertbar sind oder nicht.
Wenn also jemand das richtige Passwort zufällig verwendet aber trotzdem nicht erkennen kann ob das Passwort richtig war oder nicht, dann ist das ganze sicherer als wenn derjenige sofort eine algorythmiche Prüfung hernehmen kann welche die Richtigkeit überprüft.

Hello Sir,

wenn du damit recht hättest, würde weder das Internet noch sonst etwas auf dem Computer funktionieren: natürlich muss man feststellen können, ob ein Passwort korrekt ist, ohne eine komplette Datei unbekannter Grösse zu entschlüsseln und zu interpretieren. Zutreffend ist allerdings, dass man ein Passwort nie im Klartext speichern sollte, deswegen ist das Standardverfahren, einen Hash des PW zu speichern, mir dem man die Gültigkeit prüfen kann, der aber keine Rekonstruktion des PW erlaubt.

Dieser Hash muss also in jedem Fall irgendwo gespeichert werden, ob ich da noch eine zu verschlüsselende Datei gleich mit dranhänge, ändert an der Sicherheit NICHTS! Für das angeprochene Problem ist es also die beste Lösung, das PW zu hashen wie z.B. in Linux üblich (dort landet es ja auch in der PW-Datei, und der Hash kann ohne weiteres gelesen werden, ohne dass dadurch die Sicherheit gefährdet ist), und diesen Hash mit in die verschlüsselte Datei zu packen.

Schliesslich muss man ja noch was mit den Daten anfangen können. Du hast aber sicher recht mit deiner Grenzwertbetrachtung, dass Daten dann am sichersten sind, wenn man sie überhaupt nicht mehr entschlüsseln kann; das ist bloss für die Praxis wenig hilfreich.

Gruss Reinhard

[himitsu]

Zitat:

natürlich muss man feststellen können, ob ein Passwort korrekt ist, ohne eine komplette Datei unbekannter Grösse zu entschlüsseln und zu interpretieren.

ich sag's mal so ... zip, 7zip, rar und Co. entschlüsseln die Dateie(n) und erkennen dann ob die Datei korrekt entschlüsselt wurde.
> Hash der gepackten Datei

[Hador]

Letztendlich muss man zwischen Benutzerfreundlichkeit und Sicherheit abwägen.

Das sicherste ist definitiv die Lösung, die SirThornberry vorgeschlagen hat: Die Datei wird entschlüsselt und _nicht_ überprüft. Der Anwender selber muss dann entscheiden, ob die so entstandenen Daten lkorrekt sind. So hat man es selbst mit einem BruteForce Angriff schwer, da man nicht weiß, welche entschlüsselung korrekt ist.

Die zweite Möglichkeit, die entschlüsselte datei anhand eines Hashes zu verifizieren macht den BruteForce-Angriff lichter, da so der Erfolgsfall bestimmt werden kann. Jedoch muss jedesmal erst das Entschlüsselungsverfahren mit jedem Key angewandt werden, was recht lange dauert.

Die für den benutzer am angenehmste Methode ist das Erstellen eines Hash vom Passwort, da bei einer Falscheingabe des Passworts sofort zurückgegeben wird, dass das Passwort falsch ist und man nicht erst auf den Entschlüsselungsversuch warten muss. Dafür hilft sowas auch einem möglichen BruteForce-Angriff, der logischerweise so ebenfalls schneller ausgeführt wird.

--

Welche dieser Methoden man wählt ist Situationsabhängig.

[negaH]

Vieles wurde ja schon beantwortet, also nur par Hints von mir.

1.) Das Passwort wird in einen pseudozufälligen und sicheren Sessionkey umgewandelt. Dazu benutzt man sogenannte KDFs -> Key Derivation Functions -> Schlüsselableitungsfunktionen. Diese benutzen das Passwort + einen > = 128Bit Zufallswert im Zusammenhang mit einer Hashfunktion um aus dem immer gleichen Passwort einen sicheren, nicht rückrechenbaren und immer anderen, pseudozufälligen, Sessionkey zu erzeugen. Mit diesem Sessionkey wird der Cipher initialisiert und die Daten verschlüsselt.

2.) Mit einer MGF = Mask Generation Function, wird aus dem Passwort und einem Zufallswert = Salt, eine "Prüfsumme" erzeugt. Diese Prüfsumme + dem Zufallssalt, beides >= 128 Bit groß, wird noch vor der Verschlüsselung an den Anfang der Daten gehängt.

also

Salt_1 = RandomBinary(16);
Salt_2 = RandomBinary(16);
SessonKey = KDF(Salt_1, Passwort);
Checksum = MGF(Salt_2, SessionKey);
CipherText = ENCYPT(SessionKey, Salt_2 + Checksum + PlainText);
FinalData = Salt_1 + CipherText;

und entschlüsselt dann so:

Salt_1 = EXTRACT(FinalData, 1, 16);
SessionKey = KDF(Salt_1, Passwort);
Temp = DECRYPT(SessonKey, EXTRACT(FinalData, 16, MaxInt));
Salt_2 = EXTRACT(Temp, 1, 16);
Checksum = EXTRACT(Temp, 16, 16);
if Checksum <> MGF(Salt_2, SessionKey) then ShowMessage('Falsches Passwort');
PlainText := EXTRACT(Temp, 32, MaxInt);


Wir erzeugen also aus 128 Bit Zufall + Passwort einen Sessionkey. Aus diesem erzeugen wir mit 128 Bit Zufall eine Prüfsumme. Beide Werte sind geschützt mit einer Hashfunktion und pseudozufällig. Diese beiden Salts stehen dem Angreifer zwar indirekt zur Verfügung aber denoch kann er nicht, bzw. nur mit einem vorrausberechenbaren Aufwand, daraus Nutzen ziehen. Die Schranke dieses Aufwandes liegt bei 2^128 Kombinationen, eben weil wir beide Salt 16 Bytes groß gemacht haben. Bei einem gutem 128 Bit Password ist also im Sessionkey und Prüfsumme 128 Bit Zufall gemischt mit 128 Bit Passwort. Defakto musst du dir das so vorstellen als ob du ein Passwort benutzt das aus 128 Bit festem Teil und 128 Bit zufälligem Teil besteht und bei dem diese beiden Teile mit einander verknüpft worden sind, so das sie nicht durch den Angreifer getrennt werden können.
Da unsere Prüfsumme über den pseudozufälligen Sessionkey gleich zweimal von 2 Zufallssalts abhängig ist kann der Angreifer keine Informationen rausziehen. Den Salt_1 kann er zwar extrahieren muß dann aber 2^128 Passwörter durchprobieren. Hat er eines probiert muß er den Anfang der Daten damit entschlüsseln und den 2. Salt extrahieren. Hat er falsch gewählt so würde der 2. Salt, der ja auch verschlüsselt wurde, eben falsch entschlüsselt. Die Wahrscheinlichkeit das er mit diesem falschen 2. Salt und der falsch entschlüsselten Prüfsumme zum falschen Sessionkey eine denoch gültige Prüfsumme vor sich hat ist dann exakt so groß wie die Wahrscheinlichkeit das er alle Werte korrekt gewählt hat. Und das ist die Essenz des Verfahrens. Somit gewinnt er keinerlei Informationen im Vergleich falsch zu richtig entschlüsselt, und muß immer eine komplette Brute Force Attacke fahren. Bei diesem "Informationsgewinn" geht es primär nur darum ob er seinen Angriff beschleunigen kann, nicht darum ob er eine korrekte Entschlüsselung identifizieren kann.
Zusätzlich schützt diese Methode das Passwort und damit den Benutzer vor optimierten Brute Force Attacken wie zb. Wörterbuchangriffen -> Rainbow Tables.

Gruß Hagen

Ja Mann, Respekt ;)

[Kutter111]

Wow...,
ich dachte nicht das ich noch so viele Tips bekommen würde nach dem ich das eigentliche Problem bewältigt habe.
Und doch sehe ich wieder viele offene Fragen über den Sinn oder Unsinn des Passwortes und dessen Überprüfung. Es ist vielleicht ganz gut zu wissen, daß die Möglichkeit der Abfrage besteht. Ob man sie jetzt nutzt oder nicht bleibt jedem selber überlassen. Was auch ganz interessant ist ist Hagens Antwort (für soviel Wissen muß man doch einen Kopf wie ein Pferd haben, hast Du?;)), in der man sieht wie sehr man sich bemüht, Angriffen Widerstand entgegenzubringen und wichtige Daten zu schützen. Mit dieser Antwort werde ich mich wohl auf die nächste Ebene der Verschlüsselung begeben müssen. Noch ganz kurz eine Frage an Hagen: Geht das, was Du geschrieben hast mit Deiner DEC so?

Gruß Kutter111

[negaH]

Ja sicher.

DEC hat einen sicheren Zufallsgenerator, die Hash Klassen unterstützen direkt verschiedene KDFs und MGFs und die Verschlüsselungen sind auch integriert. Hier im Forum sollte man sogar einiges an fertigen Source fürs DEC finden.

Gruß Hagen