DEC Verschlüsselung mit Blowfish,etc. unsicher ?

[Predator]

moin Jungs,

einem anderen Forum meint jemand folgendes:

(bedenke: ich verwende Blowfish mit SHA_1 und cmCBC)

"deine verschluesselung setzt sich immer zuerst aus dem verschluesselten quelltext und direkt danach dem passwort zusammen, wobei das passwort den eigentlichen verschluesselten quelltext nicht beeinflusst!

Bsp.:

verschluesselter quelltext: xyz
passwort verschluesselt: pass01

zusammen sieht das bei dir dann so aus:

verschluesselung gesammt: xzypass01

um den quelltext unabhaengig zu entschluesseln wird das passwort garnicht benoetigt, was die sache nicht sehr sicher macht!"

stimmt das nun oder stimmt das nun nicht ?

Ich denke nicht, weil das Passwort doch nicht wirklich in der Datei gespeichert wird oder ist das wahr ?

[BungeeBug]

Hi,

angenommen das wär so ... wieso heist das dann Verschlüsselung?Das einzige ander Aussage was verschlüsselt ist der Sinn, den kann ich nämlich nicht erkennen.

Infomaterial bekommst du aus der aktuellen CT, die kostet 3 ? und gibbet an jedem Kiosk.
Ich meine mich entsinnen zukönnen das DES + 128 Bit Schlüssel für die nächste Zeit als sicher gilt.
Für alles weitere musst du eben in der CT nachlesen, ich habs sie im mom nicht griffbereit und kann dir deswegen nichts näheres sagen.

[sakura]

Warte noch ein bisschen. Der Autor des DEC (Hagen Reddmann) wird heute bestimmt noch vorbei schauen und Dir eine qualitative Antwort geben können.

......

[negaH]

Zitat:

Warte noch ein bisschen. Der Autor des DEC (Hagen Reddmann) wird heute bestimmt noch vorbei schauen und Dir eine qualitative Antwort geben können.

Tja, wenn das so einfach wäre, denn ich verstehe nicht die Frage ?
Was hat die Frage mit meinem DEC zu tun ?? ich weiß es nicht.

Also es gab zwei verschiedene DEC Versionen
Version 1.0 und 2.0, bei denen das Passwort gespeichert werden konnte wenn das der Programmierer wollte und Version 3.0 wo dieses Feature nicht mehr existiert.

Nun beide sind NICHT unsicher ! denn im DEC wurde dann mit einer Hashfunktion aus dem Passwort ein Sessionkey erzeugt. Dieser wurde als Schlüssel für die Verschlüsselung benutzt. Man kann aber diesen Schlüssel mit sich selber verschlüsseln und an den Anfang der Datei speichern.

D.h. SessionKey := Hash(Passwort); KeyChecksum := Encrypt(SessionKey, Key = SessionKey). Nur wer den richtigen SessionKey hat konnte KeyChecksum erneut nach berechnen oder eben Entschlüsseln. SessionKey kann nicht zum Paswort zurückberechnet werden. Nur eine Brute Force oder Dictionary Attacke können einem Passwort ein SessionKey zuordnen.

Nun, der Artikel in der CT ist sehr fundiert und gerade noch so von Anfängern verstehbar. Wie der Auto korrekt bemerkte sollte man aus den Passwörtern IMMER mit Hilfe einer KDF = Key Derivation Function den Sessionkey erzeugen. Wichtig dabei ist es das diese KDF ein Passwort UND einen Salt = Salz mit einander per Hashfunktion verknüpft. Der Salt ist wichtig und sollte aus ca. 128 Bit sicherem Zufall bestehen.

Nun, wie die oben gesehen hast macht das das DEC in Version 1.0 bis 3.0 eben nicht.
Es gibt dafür mehrere Gründe:
- nur die Qualität des Passwortes bestimmt die Sicherheit, egal wie man den Sessionkey erzeugt
- die Benutzung zufälliger Salts erhöht den technischen Aufwand und verhindert nur in Grenzen bestimmte Angriffe.

Genauer gesagt der Salt verhindert tatsächlich nur eine Beschleunigung einer Brute Force Attacke. Eine solche dynamische Attacke sähe so aus das man aus einer Datenbank alle viel benutzten Wörter nimmt, sie mit der Hashfunktion umwandelt und diesen Sesionkey ausprobiert.
Ohne SALT könnte man bei bekannter Hashfunktion in der Datenbank die Sessionkeys zum Passwort mitabspeichern. Somit wäre der Angriff um einen Faktor schneller, als bei der Live berechnung. Dies geht aber nur wenn die KDF() ohne Zufallssalt arbeitet. Eben wie im DEC 1-3.
Im nun neu erstellten DEC werden nun denoch echte KDF's mit Random Salt benutzt.

Denoch ! ein Passwort wie A wird in jedem Falle unsicher sein. Ein Passwort wie Genauer gesagt der Salt verhindert tatsächlich nur eine Beschleunigung einer Brute Force Attacke. Eine solche dynamische Attacke sähe so aus das man aus einer Datenbank alle viel benutzten Wörter nimmt, sie mit der Hashfunktion umwandelt und diesen Sesionkey ausprobiert.
Ohne SALT könnte man bei bekannter Hashfunktion in der Datenbank die Sessionkeys zum Passwort mitabspeichern. Somit wäre der Angriff um einen Faktor schneller, als bei der Live berechnung. Dies geht aber nur wenn die KDF() ohne Zufallssalt arbeitet. Eben wie im DEC 1-3.
Im nun neu erstellten DEC werden nun denoch echte KDF's mit Random Salt benutzt.

wäre in bis jetzt absolut sicher gewesen, egal ob mit Salt oder ohne, egal ob dessen Hashwert mit sich selber verschlüsselt und gespeichert würde, oder ohne diese Speicherung.

Der Typ der dies meinte wollte sich entweder wichtig tuen, mir eines auswischen, oder aber hat es so wie ich teilweise zu absolutistisch gesehen. In der Kryptographie/Kryptologie gibt es aber keine festen Grenzen, was wie sicher ist. Nur in der Logischen Analyse kann man solche JA / NEIN Aussagen treffen.

Obige Aussagen als Sicherheitskriterium ausgedrückt würde heissen:

Eine Benutzung einer Zufallssalt basierten KDF und NICHT Speicherung irgendwelcher Passwort Informationen ist sicherer als das Passwort direkt als Schlüssel zu benutzen und dessen Hash verschlüsselt zu speichern. Der Sicherheitunterschied ist aber bei weitem nicht so hoch das man die letzere Methode mit gutem Paswort als unsicher bezeichnen könnte.
Wäre die letztere Methode auf Grund ihres schlechten Passwortes als unsicher einzustufen dann wäre jede bessere Methode mit gleichen Passwort ebenso unsicher. Noch schlimmer, da sichere Verfahren benutzt wurden und der Benutzter animmt das die Sicherheit gestiegen ist, bedeutet das man mit unsicherem Passwort sogar weniger physikalische Sicherheit hat als ohne diese komplexen Verfahren. Denn! mit einem scharfen Messer schneidet man sich nicht, gilt hier. Der Benutzer wird schlampiger mit der Sicherheit umgehen bei Hochsicherheitssystemen da er glaubt es wäre dann immer noch sicher. Der User wird mit instabilen Systemen viel zärtlicher und genauer umgehen denn er weiß das es nicht perfekt ist.

Übrigens: würde man keinerlei Information zum Passwort speichern, aber eine Header/Prüfsumme an den Anfang oder Ende der verschlüsselten Daten speichern, dann wäre die genauso unsicher wie den verschlüsselten Hash des Passwortes zu speichern. Denn es geht darum wie schnell ein Angreifer erkennen kann ob ein getestes Passwort das richtige ist. Nun, Datei Header/Footer/Prüfsummen lassen sich NIEMALS vermeiden. Selbst nur das Wissen ob englischer/deutscher/MIME Format oder sonstwas verschlüsselt wurde reicht demnach aus. Technologisch gesehen würde ein gespeicherter Passworthash also nur marginal die Sicherheit reduzieren im Vergleich zu ohne.


Gruß Hagen