Frage zum DEC

[monty.ms]

Hallo.

Ich habe ein Programm geschrieben und verwende darin DEC zum kodieren und dekodieren von Strings. Ich wollte fragen ob ich das so richtig angewendet habe. Es funktioniert, aber vielleicht habe ich etwas vergessen, wodurch es unsicherer wird:

Delphi-Quellcode:

ACipherClass := TCipher_Rijndael;
ACipherMode := cmCFS8;
AHashClass := THash_MD5;
ATextFormat := TFormat_MIME64;
AKDFIndex := 1;

Kodieren:

Delphi-Quellcode:

function ghEncode(const vText: String; const vPassword: String): String;
var Salt, Data: Binary;
begin
  With ValidCipher(ACipherClass).Create, Context Do
  Try
    Salt := RandomBinary(1024);
    Mode := ACipherMode;
    Init(ValidHash(AHashClass).KDFx(vPassword, Salt, KeySize, TFormat_Copy, AKDFIndex));
    Data := Salt + EncodeBinary(vText) + CalcMAC;
    Result := ValidFormat(ATextFormat).Encode(Data);
  Finally
    Free;
    ProtectBinary(Salt);
    ProtectBinary(Data);
  End;
end;

Dekodieren:

Delphi-Quellcode:

function ghDecode(const vText: String; const vPassword: String): String;
var Salt, Data, Check: Binary;
    Len: Integer;
begin
  With ValidCipher(ACipherClass).Create, Context Do
  Try
    Salt := ValidFormat(ATextFormat).Decode(vText);
    Len := Length(Salt) -1024 -BufferSize;
    Data := System.Copy(Salt, 1025, Len);
    Check := System.Copy(Salt, Len +1025, BufferSize);
    SetLength(Salt, 1024);
    Mode := ACipherMode;
    Init(ValidHash(AHashClass).KDFx(vPassword, Salt, KeySize, TFormat_Copy, AKDFIndex));
    Result := DecodeBinary(Data);
    If Check = CalcMAC Then
      Begin
        Result := DecodeBinary(Data);
      End
    Else
      Begin
        Result := 'Error';
      End;
  Finally
    Free;
    ProtectBinary(Salt);
    ProtectBinary(Data);
    ProtectBinary(Check);
  End;
end;

Wäre nett, wenn eben einer drüber schauen könnte. Danke!

Dann hätte ich noch eine Frage zum Thema: Könnte jemand das Passwort raus bekommen, wenn der jenige den eigentlichen (unverschlüsselten) Text kennt?

Vielen Dank schonmal!

[Luckie]

Guck dir hier meine Demo an:
http://www.michael-puff.de/Developer...agen_Reddmann/
So sollte es sicher sein, laut Hagen.

[monty.ms]

Hallo, Danke erstmal für die Hilfe!

Welche Demo genau meinst du? Diese hier: "SimpleEncryptionClasseForDEC.zip"? Oder direkt aus dem "DEC 5.1c.zip"?

Bei dem erst genannten ist es ja etwa wie bei mir, nur eben mit einem Stream. Bei dem zweiten hab ich mich irgendwie nicht zurecht gefunden Oo. Weis nicht, ob die Demo da genau das erklären soll. Vielleicht hab ich es auch übersehen. Werd das gleich nochmal durcharbeiten.

Danke nochmal.

[Hansa]

Ich würde mal auf den großen Meister warten. Der gibt dir sicher noch selber Antwort. Allerdings : die Frage nach dem bekannten Text und dazu den verschlüsselten suchen oder umgekehrt : glaube kaum, dass das geht. Vielleicht hat er aber eine Hintertür aufgelassen. Warte ab.

[himitsu]

Kann mir eigentlich kaum vorstellen, daß er eine intertür versteckt hat. :angel:

Aber natürlich ist es möglich ein (nicht unbedingt das) Passwort rauszubekommen, womit der Text verschlüsselt wurde.
Weiß zwar nicht, wie weit es möglich ist, den verschlüsselten Text so zurückzurechnen, daß man am Ende ein Passwort rausbekommt, aber notfalls kann man ja immernoch viele Passwörter durchprobieren (z.B. per Bruteforce) und schauen, ob man mit einem davon die Daten entschlüsseln kann.

[Luckie]

Zitat:

Zitat von monty.ms

"SimpleEncryptionClasseForDEC.zip"? Oder direkt aus dem "DEC 5.1c.zip"?

Oh, sorry. Ersteres meinte ich.

[monty.ms]

Eine Hintertür glaub ich auch nicht, will ich auch überhaupt nicht :)
Mir ging es bei der Frage eben nur darum, ob man es irgendwie zurückrechnen kann.

@Luckie, Danke nochmal für das Beispiel.

Werde natürlich noch auf eine Antwort des Meisters warten ^^

[negaH]

So ist das schon richtig, du hast alle wichtigen Punkte beachtet. (wahrscheinlich um einiges sicherer als so manches professionelle Produkt :) )

Zu deiner Frage mit dem Zurückrechnen:

Ja, man kann es zurückrechnen sogar mit fast 100% Sicherheit. Aber das ist die Betrachtungsweise eine Mathematikers, infinitimal. Wenn es unendlich viele Passwörter gibt mit unendlicher Größe in Bits und wir diese Passwörter mit einem 128 Bit Salt und 128 Bit Hashfunktion mappen dann gibt es zu jedem der 2^128 möglichen Hashoutput exakt 2^unendlich viele Kollisionen, die Wahrscheinlichkeit das man das zurückrechnen kann beträgt also 2^128 und das man ein gültiges Passwort findet beträgt Unendlich/2^128 = Unendlich = 1.

Nun kommt der Ingenieur und fügt neue Randbedingungen hinzu, nämlich Zeit, Rechenaufwand und Technologie. Alles davon ist aus unserer Sicht im Vergleich zu Unendlich enorm begrenzt. Und das ändert alles. Denn nun wird das System praktisch unknackbar, bzw. es sollte so konstruiert sein das mit heutiger (und noch in 20 Jahren) Technologie und Wissenstand es nicht zurückrechenbar ist.

Drittes stellt sich die Frage was man unter Zurückrechnen versteht. Wenn man 2^256 verschiedene und gleichverteilte Passwörter betrachtet die mit einer 128 Bit Hashfunktion gemappt werden dann muß es 2^256 / 2^128 kollidierende Passwörter geben. Um nun den Schlüssel im Schloß umdrehen zu können benötigen wir also garnicht das korrekte Passwort sondern nur eines der 2^256 / 2^128 möglichen die den gleichen Hash erzeugen. Eine Aussage darüber zu treffen das man nun das exakte Passwort aus den sich 2^128 überschneidenden Passwörtern zu einem Hashdigest gefunden hat ist aber nur rein statistisch möglich. Man findet also zu einen Hashdigest mit 128 Bit Größe aus einem Set von 2^256 Passwörtern mit Sicherheit 2^128 korrekte Paswörter kann aber auf Grund des Mappings der Hashfunktion niemals exakt sagen welches tatsächlich als Input diente. Und das ist der Sinn wenn man mit einer randomisierten KDF ein Passwort umwandelt in einen Sessionkey. Denn so garantiert man das defakto es garnicht möglich ist nur alleine mit Hilfe der Hashfunktion und Zufallssalt das exakt benutzte Passwort zurückberechnen zu können. Man schützt also das Passwort des Benutzers selbst wenn man die Verschlüsselung und somit den Sessionkey irgendwie geknackt hat.

Es ist also eher eine Frage wie man "Zurückrechnen" definiert. Möchte man nur eines der möglichen und funktioniernden Passwörter berechnen dann ist dies aus Sicht eines Mathematriker zu 100% möglich, er denkt infinitimal, er hat Computer die alles in 0-Zeit berechnen können. Für einen Ingenieur sind diese Resourcen stark begrenzt und somit ist selbst das Zurückrechnen praktisch undurchführbar, einfach weil 2^128 eben eine enorm große Anzahl ist.
Möchte man das real benutzte Passwort finden und es gehört in die Menge der zb. 256Bit großen zufälligen Passwörter, dann ist es beweisbar unmöglich aus einem 128 Bit Hashdigest exakt dieses Passwort zurückzuberechnen, einfach weil ein 128 Bit Hashdigest um 128 Bit zu kurz geraten ist um ein 256 Bit langes Passwort exakt zu beschreiben, es fehlen also nötige Informationen.

Einfaches Beispiel ist modulare Arithmetik. Nehmen wir mal unsere Analoguhren. Sie gehen von 0 Uhr bis 12 Uhr und beginnen nun von vorne. Wenn wir nun 3 Uhr haben dann können wir keine Aussage darüber treffen wieviele Tage seit dem letzten 3 Uhr das wir beobachtet haben vergangen sind. Klar ? Ein Hashdigest mit 128 Bit ist also unser Ziffernblatt mit 2^128 Unterteilungen. Unser Passwort ist 2^128 Tage * 2^128 Uhrenuntereilungen. Da der Hashdigest nur die unterseten 2^128 Zeiteiheiten angibt fehlen uns die 2^128 oberen (Tagesanzahlen) um das 256 Bit Passwort exakt beziffern zu können. Ergo: man kann aus einem 128 Bit Hash nicht das exakt benutze 256 Bit Passwort zurückberechnen, dazu fehlen einfach 128 Bit anwichtigen Informationen.

Ohne Salt braucht man aber auch garnicht das exakte 256Bit Passwort zurückrechnen, eines der 2^128 möglichen Passwörter die den gleichen Hash erzeugen reicht uns schon aus. (was aber mit heutigem Wissensstand und Resourcen auch nicht praktisch geht). Man hätte also ein funktionierendes vergleichbares Passwort zum Original. Wenn der Benutzer nun sein Originalpasswort mit dem gleichen Verfahren für verschiedene Sachen mehrfach benutzt hat dann können wir das alles sofort knacken obwohl wir nicht das Originalpasswort haben. Nun benutzen wir aber noch einen 128 Bit Zufallssalt. Auch wenn dieser für alle Beteiligten lesbar ist so wird dieser Salt in der KDF dafür sorgen das jedesmal wenn wir die KDF mit dem Originalpasswort und einen anderen Salt benutzen der Aufwand des Knackens dramatisch inkrementiert wird. Denn nun haben wir quasi einen Modularen Ring innerhalb eines Modularen Ringes. Zu jedem der 2^128 unterschieldichen Salts erzeugen wir eine modulare Menge von 2^128 verschiedenen Hashs für nur eine Originalpasswort! Das bedeutet das wenn wir eine der vielen unterschieldichen Verschlüsselungen geknackt haben, also ein funktionierendes aber nicht das originale Passwort gefunden haben, das dieses Pseudopasswort nur mit dem einen benutzten Salt korrekt funktioneren wird. Mit einer Wahrscheinlichkeit von 1/2^128 haben wir das originale Passwor gefunden das mit jedem anderen der 2^128 möglichen Salts immer korrekt funktionieren wird. Das bedeutet das wenn der Angreifer nun eine weitere Nachricht von uns knacken möchte der wieder von vorne beginnen muß da sein Pseudopasswort eben mit diesem zweiten Zufallssalt nicht mehr funktioniert, mit einer Wahrscheinlichkeit von 2^128/(2^128-1) ca. 1 ist dies der Fall. Der Zufallssalt stellt also nun sicher das ein Angreifer mit enorm hoher Wahrscheinlichkeit seinen Ersten Erfolg nicht dazu benutzen kann um weitere Nachrichten von uns direkt entschlüsseln zu können.

Gruß Hagen

[monty.ms]

Vielen Dank. Vorallem für die detailierte Erläuterung. Ein wirklich interessantes Thema, auch wenn ein wenig kompliziert :)