Symmetrische Verschlüsselung: MD5-Hash als Schlüssel?

[Andre Sokolew]

Hallo,

ich bin mir nicht sicher, ob das der richtige Weg ist:

Eine Datei mit "binären Daten" soll verschlüsselt werden. Die Rohdaten sind
einige Tabellen, die Text-, Datum- und Real-Spalten enthalten. Für das
_unverschlüsselte_ Dateiformat wird ein Header erzeugt, der vorwiegend die
Eintrittspunkte für die einzelnen Tabellen enthält. Danach folgen die
Tabellen, die nahezu optimal komprimiert sind, d.h. jeder Spaltentyp wird
mit einer speziellen Komprimierungsroutine zusammengefaltet. Der Dateiinhalt
kann nur durch das Original-Programm zugänglich gemacht werden.

Zur Aktivierung der Verschlüsselung muss ein Passwort eingegeben werden.
Außerdem wird bei jedem Speichervorgang ein zufälliger Startwert gewürfelt.
Aus dem Passwort und diesem Startwert zusammen wird ein MD5-Hash gebildet.
Der Startwert wird im ersten Teil des Headers unverschleiert gespeichert.
Der zweite Teil des Headers und der Rest der Datei wird mit dem MD5-Hash
byteweise XOR-verknüpft. Da der Hash-Wert nur 32 Byte lang ist, wird er
immer wieder angewendet, bis das Dateiende erreicht ist.

Zur Entschlüsselung muss das Passwort eingegeben werden. Die Loadroutine
lädt den ersten (unverschlüsselten) Teil des Headers und ermittelt so u.a.
den Zufalls-Startwert, aus dem gemeinsam mit dem eingegebenen Passwort der
MD5-Hash berechnet wird, der als symmetrischer Schlüssel für die
Entschlüsselung dient.

Würdet Ihr dieses Vorgehen für sicher halten?
Vielen Dank für Antworten.

Andre

[Daniel Albuschat]

[snip]

Post by Andre Sokolew
Würdet Ihr dieses Vorgehen für sicher halten?

Nein. Es ist 'security through obscurity'.
Durch den zufallsgenerierten Part kommt noch ein Faktor hinzu, der mir
generell nicht so gut gefällt:
Die gleichen Eingabedaten ergeben bei einem weiteren
Verschlüsselungslauf immer andere Ausgabedaten. Dadurch kann
man nicht anhand von den verschlüsselten Daten feststellen, ob
die Eingabedaten gleich sind.

Wenn du etwas sicher haben willst, solltest du in der Anwendung
einen entsprechenden Schlüssel haben und ein Verschlüsselungsverfahren,
das taugt (XOR tut dies für gewöhnlich nicht), nutzen.
Ich gehe zum Beispiel so vor, dass ich einen solchen Schlüssel in der
Anwendung durch ein 'security through obscurity'-Verfahren vor Hexedit-
Schnüfflern schütze und es dann für Ver- und Entschlüsselung nutze.

Noch etwas zur Komprimierung: Komprimierung wird generell effektiver,
je mehr (bestenfalls gleiche) Daten vorliegen. Wenn du jeden einzelnen,
kleinen Teil der Datei komprimierst, hast du dadurch wahrscheinlich
weniger Erfolg, als wenn du die gesamte Datei im Ganzen komprimieren
würdest.

Von alledem mal abgesehen: Wie sicher musst du es denn haben?
Wenn es nur darum geht, Otto Normalverbraucher davon abzuhalten,
irgend welche Daten zu lesen, reicht das Verfahren vollkommen. Wobei
hier sicherlich die Größe der Audienz eine Rolle spielt: Wichtig ist
nicht, dass jeder einzelne Anwender die Daten nicht dechiffrieren kann,
sondern dass es keinem gelingt, ein Programm zu schreiben, das es jedem
Anwender auf einfache Weise ermöglich, die Daten zu lesen.

MfG,
Daniel

[Andre Sokolew]

Post by Daniel Albuschat
Durch den zufallsgenerierten Part kommt noch ein Faktor hinzu, der mir
Die gleichen Eingabedaten ergeben bei einem weiteren
Verschlüsselungslauf immer andere Ausgabedaten.

Das ist Absicht.
Damit soll der Einsatz von Hash-Tabellen mit "gebräuchlichen" Passwörtern
erschwert bis unmöglich gemacht werden.

Post by Daniel Albuschat
Dadurch kann man nicht anhand von den verschlüsselten Daten feststellen,
ob die Eingabedaten gleich sind.

Ich habe im OP nicht beschrieben, wie das geschieht, aber die Prüfung, ob
das richtige Passwort eingegeben wurde, findet natürlich statt. Unter
anderem deshalb muss jede Datei trotz gleichem Passwort mit einem anderen
Schlüssel verschlüsselt sein.
Genau genommen werden zwei verschiedene Schlüssel erzeugt, der eine zur
Einmal-Verwendung für die Verschlüsselung des Headers (32 Byte reichen da).
Der zweite Schlüssel für die eigentlichen Daten, deren Struktur nicht
vorhersagbar ist, wiederholt sich allerdings regelmäßig bis zum Dateiende.

Post by Daniel Albuschat
Wenn du etwas sicher haben willst, solltest du in der Anwendung
einen entsprechenden Schlüssel haben und ein Verschlüsselungsverfahren,
das taugt (XOR tut dies für gewöhnlich nicht),

Warum nicht?

Post by Daniel Albuschat
Ich gehe zum Beispiel so vor, dass ich einen solchen Schlüssel in der
Anwendung durch ein 'security through obscurity'-Verfahren vor Hexedit-
Schnüfflern schütze und es dann für Ver- und Entschlüsselung nutze.

Ich meine, die Anwendung darf generell keinen Schlüssel oder Teile davon
enthalten.

Post by Daniel Albuschat
Noch etwas zur Komprimierung: Komprimierung wird generell effektiver,
je mehr (bestenfalls gleiche) Daten vorliegen.

Das gilt für ZIP-ähnliche Verfahren, die allerdings kaum Rücksicht darauf
nehmen, welchen Inhalt die Daten haben oder bestenfalls auf bestimmte
Inhalte hin optimiert sind.

Post by Daniel Albuschat
Wenn du jeden einzelnen, kleinen Teil der Datei komprimierst, hast du
dadurch wahrscheinlich weniger Erfolg, als wenn du die gesamte Datei im
Ganzen komprimieren würdest.

Definitiv nicht.
Ich komprimiere Strings anders (z.B. wird im ersten Schritt ein
7-Bit-Zeichensatz simuliert, was ohne großen Aufwand allein schon rund 10 %
Einsparung bringt), und dann (im zweiten Schritt) natürlich _alle_ Strings
gemeinsam - so gesehen hast Du natürlich Recht, nur so lassen sich
Wiederholungen erfassen und ausnutzen.
Die Binärdaten (Datumswerte und sonstige Real-Zahlen) werden anders
komprimiert, weil diese Daten mit hoher Wahrscheinlichkeit in einen
bestimmten Wertebereich liegen, das und andere Spezifika werden ausgenutzt.
Andererseits kommen kaum Wiederholungen vor, so dass ZIP-ähnliche Verfahren
hier schlechter laufen.

Übrigens ging es mir bei der Komprimierung auch nicht um die Einsparung des
letzten Bits, sondern vorwiegend darum, die Datenstruktur in der
gespeicherten Datei unvorhersagbar zu machen.

Post by Daniel Albuschat
Von alledem mal abgesehen: Wie sicher musst du es denn haben?
Wenn es nur darum geht, Otto Normalverbraucher davon abzuhalten,
irgend welche Daten zu lesen, reicht das Verfahren vollkommen.

Dafür bräuchte es dann gar keine Verschlüsselung. Otto Normalbürger kann das
Programm nicht disassemblieren, um das Kompressionsverfahren
rückabzuwickeln. So um 5.000 - 10.000 Leute in Deutschland werden das aber
können, wenn sie sich nur einen Tag lang damit beschäftigen.
Passworteingabe, die nur im Originalprogramm schützt, ohne Verschlüsselung
der gespeicherten Daten ist also Nonsens.

Das Ziel:
Es soll nicht möglich sein, die Verschlüsselung oder das Passwort mit
"vernünftigem Aufwand" zu knacken. Mein Ehrgeiz geht nicht so weit, dass ich
BND, CIA und KGB vor eine unlösbare Aufgabe stellen möchte.
Vor allen anderen soll das Verfahren aber schon sicher sein - Verwendung
eines geeigneten Passwortes vorausgesetzt.

Andre

[Heiko Nocon]

Post by Andre Sokolew

Post by Daniel Albuschat
Wenn du etwas sicher haben willst, solltest du in der Anwendung
einen entsprechenden Schlüssel haben und ein Verschlüsselungsverfahren,
das taugt (XOR tut dies für gewöhnlich nicht),

Warum nicht?

Ein einfaches XOR ist genau dann brauchbar, wenn man entweder
Zufallsdaten damit verschlüsselt oder der Schlüssel mindestens so lang
ist wie die Nachricht. In jedem anderen Fall ergibt sich Angriffsfläche
für statistische Angriffe.

[Andre Sokolew]

Post by Heiko Nocon
Ein einfaches XOR ist genau dann brauchbar, wenn man entweder
Zufallsdaten damit verschlüsselt oder der Schlüssel mindestens so lang
ist wie die Nachricht. In jedem anderen Fall ergibt sich Angriffsfläche
für statistische Angriffe.

Fall zwei ist nicht gegeben, dafür aber in sehr guter Näherung Fall eins.

Andre

[Heiko Nocon]

Post by Andre Sokolew
Das ist Absicht.
Damit soll der Einsatz von Hash-Tabellen mit "gebräuchlichen" Passwörtern
erschwert bis unmöglich gemacht werden.

Es ist natürlich nur eine Erschwernis. Und zwar läßt sie sich sogar
beziffern: Bei gleichem Wörterbuch nimmt der Umfang der Hashtabellen um
genau den Faktor 2^32 zu.

Aber wie schon geschrieben, bei deinem Verfahren macht sich niemand die
Mühe, das Passwort herausfinden zu wollen. Es ist sehr viel einfacher,
den Schlüssel direkt anzugreifen statt die Schlüsselgenerierung.

[Heiko Nocon]

Post by Andre Sokolew
Würdet Ihr dieses Vorgehen für sicher halten?

So sicher, wie ein einfaches XOR mit einem 128Bit-Schlüssel sein kann.
Also nicht sehr sicher.

Der ganze Rest des Verfahrens fällt von vornherein bestenfalls unter die
Kategorie "security by obscurity" und ist mit einem Disassembler und der
nötigen Erfahrung in kurzer Zeit kein Geheimnis mehr.

Beim Disassemblieren fallen dann mit einiger Wahrscheinlichkeit auch
noch Informationen über den Aufbau der verschlüsselten Headerstruktur
ab, mit denen sich zumindest ein Teil der 128Bit zukünftig mit einigen
wenigen einfachen Operationen ermitteln lassen.
Zum vollständigen Lesen der Information wäre dann nur noch ein
brute-force auf den Rest der Bits nötig. Davon hat man dann zwar nicht
das verwendete Passwort, aber den Inhalt der Nachricht.

Daß das so möglich wäre, zeigt deutlich, daß das ganze Geraffel mit MD5,
Passwort und Startwert völlig nutzlos ist.

[Andre Sokolew]

Post by Heiko Nocon
Der ganze Rest des Verfahrens fällt von vornherein bestenfalls
unter die Kategorie "security by obscurity" und ist mit einem
Disassembler und der nötigen Erfahrung in kurzer Zeit kein
Geheimnis mehr.

Das Verfahren soll ja auch gar nicht geheim sein, sonst würde ich es hier
nicht (grob) beschreiben.

Post by Heiko Nocon
Beim Disassemblieren fallen dann mit einiger Wahrscheinlichkeit auch
noch Informationen über den Aufbau der verschlüsselten Headerstruktur
ab, mit denen sich zumindest ein Teil der 128Bit zukünftig mit einigen
wenigen einfachen Operationen ermitteln lassen.

So blond bin ich nun auch wieder nicht, dass ich den Header mit demselben
Schlüssel belege wie die eigentlichen Daten. Solange noch eine gewisse
Struktur vorhersehbar ist, wird natürlich ein Einmal-Schlüssel verwendet.
das sind ja nur wenige Bytes. In dem Teil, wo sich der Schlüssel wiederholt,
ist definitiv keine Struktur mehr vorhersagbar, weil sie eben von den
Informationen im ersten Teil abhängig sind.

Post by Heiko Nocon
Zum vollständigen Lesen der Information wäre dann nur noch
ein brute-force auf den Rest der Bits nötig.

Wie gesagt, so einfach nun doch nicht.

Post by Heiko Nocon
Davon hat man dann zwar nicht das verwendete Passwort,
aber den Inhalt der Nachricht.
Daß das so möglich wäre, zeigt deutlich, daß das ganze Geraffel mit MD5,
Passwort und Startwert völlig nutzlos ist.

Wie dann?

Andre

[Daniel Albuschat]

Post by Andre Sokolew

Post by Heiko Nocon
Der ganze Rest des Verfahrens fällt von vornherein bestenfalls
unter die Kategorie "security by obscurity" und ist mit einem
Disassembler und der nötigen Erfahrung in kurzer Zeit kein
Geheimnis mehr.

Das Verfahren soll ja auch gar nicht geheim sein, sonst würde ich es hier
nicht (grob) beschreiben.

Da du, wie ja bereits erwähnt wurde, einen "security by
obscurity"-Ansatz gewählt hast, ist er *absolut* nutzlos, wenn die
Obskurität preisgegeben wird.

Post by Andre Sokolew

Post by Heiko Nocon
Beim Disassemblieren fallen dann mit einiger Wahrscheinlichkeit auch
noch Informationen über den Aufbau der verschlüsselten Headerstruktur
ab, mit denen sich zumindest ein Teil der 128Bit zukünftig mit einigen
wenigen einfachen Operationen ermitteln lassen.

So blond bin ich nun auch wieder nicht, dass ich den Header mit demselben
Schlüssel belege wie die eigentlichen Daten.

Ob nun 1 Schlüssel, 2 oder 5, das Problem bleibt dasselbe.

Post by Andre Sokolew

Post by Heiko Nocon
Zum vollständigen Lesen der Information wäre dann nur noch
ein brute-force auf den Rest der Bits nötig.

Wie gesagt, so einfach nun doch nicht.

"Einfach" ist relativ. Wenn durch das Knacken deiner Verschlüsselung
Profit generiert werden kann, dann glaub mir, wird sich jemand finden,
der genug Energie in die Sache steckt.
Und dieser Jemand kann dann für 10 Euro ein Tool anbieten, das deine
Daten, die eigentlich 500 kosten würden, freischaltet (oder was auch
immer du gerade verschlüsselst).

Post by Andre Sokolew

Post by Heiko Nocon
Davon hat man dann zwar nicht das verwendete Passwort,
aber den Inhalt der Nachricht.
Daß das so möglich wäre, zeigt deutlich, daß das ganze Geraffel mit MD5,
Passwort und Startwert völlig nutzlos ist.

Wie dann?

Am besten wäre ein asynchrones Verfahren mit im Programm vergebenen
privaten und öffentlichen Schlüsseln, die irgendwo "sicher" abgelegt
werden.

Hier tritt eine abgewandelte Form des Henne-Ei-Problems auf:
Der Schlüssel selbst muss dem Programm bekannt, er darf aber nicht
zugänglich sein. Also muss dieser über ein schwaches Verschlüsselungs-
verfahren geschützt werden. Und wer diese Verschlüsselung knackt, kann
dann auch die letztlich verschlüsselten Daten damit entschlüsseln...

Ich bin mir ehrlich gesagt gar nicht sicher, wie man dieses Problem
richtig lösen können soll.

MfG,
Daniel

[Andre Sokolew]

Post by Daniel Albuschat

Post by Andre Sokolew

Post by Heiko Nocon
Der ganze Rest des Verfahrens fällt von vornherein bestenfalls
unter die Kategorie "security by obscurity" und ist mit einem
Disassembler und der nötigen Erfahrung in kurzer Zeit kein
Geheimnis mehr.

Das Verfahren soll ja auch gar nicht geheim sein, sonst würde ich es hier
nicht (grob) beschreiben.

Da du, wie ja bereits erwähnt wurde, einen "security by
obscurity"-Ansatz gewählt hast, ist er *absolut* nutzlos, wenn die
Obskurität preisgegeben wird.

Das sehe ich anders. Ich habe das Verfahren beschrieben. Die eigentliche
Verschlüsselung geschieht mit einem 32-Byte-Schlüssel, an dem nichts
obskures ist.

Post by Daniel Albuschat

Post by Andre Sokolew

Post by Heiko Nocon
Beim Disassemblieren fallen dann mit einiger Wahrscheinlichkeit auch
noch Informationen über den Aufbau der verschlüsselten Headerstruktur
ab, mit denen sich zumindest ein Teil der 128Bit zukünftig mit einigen
wenigen einfachen Operationen ermitteln lassen.

So blond bin ich nun auch wieder nicht, dass ich den Header mit demselben
Schlüssel belege wie die eigentlichen Daten.

Ob nun 1 Schlüssel, 2 oder 5, das Problem bleibt dasselbe.

Sorry, Du hast das Problem nicht verstanden, das Heiko ansprach.

Post by Daniel Albuschat
Am besten wäre ein asynchrones Verfahren mit im Programm vergebenen
privaten und öffentlichen Schlüsseln, die irgendwo "sicher" abgelegt
werden.
Der Schlüssel selbst muss dem Programm bekannt, er darf aber nicht
zugänglich sein.

Falsch. Der Schlüssel darf dem Programm nicht bekannt sein.
Der Schlüssel _muss_ in dem Moment generiert werden, wenn die Daten
gespeichert werden, und er darf nirgendwo gespeichert werden.

Post by Daniel Albuschat
Also muss dieser über ein schwaches Verschlüsselungs-
verfahren geschützt werden. Und wer diese Verschlüsselung knackt, kann
dann auch die letztlich verschlüsselten Daten damit entschlüsseln...

Genau deshalb ist das Unsinn.

Der Schlüssel darf weder im Programm noch in der Datei gespeichert werden.
Andererseits muss er zur Verfügung stehen, wenn die Datei berechtigterweise
entschlüsselt werden soll. Er muss zu diesem Zeitpunkt also neu generiert
werden, und zwar genau auf dieselbe Weise wie beim Speichern. Daran gibt es
nichts zu deuteln.

Meine Frage im OP bezieht sich darauf, ob ein MD5-Hash prinzipiell als
symmetrischer Schlüssel geeignet ist oder nicht.

Andre

[Daniel Albuschat]

Post by Andre Sokolew

Post by Daniel Albuschat

Post by Andre Sokolew

Post by Heiko Nocon
Der ganze Rest des Verfahrens fällt von vornherein bestenfalls
unter die Kategorie "security by obscurity" und ist mit einem
Disassembler und der nötigen Erfahrung in kurzer Zeit kein
Geheimnis mehr.

Das Verfahren soll ja auch gar nicht geheim sein, sonst würde ich es hier
nicht (grob) beschreiben.

Da du, wie ja bereits erwähnt wurde, einen "security by
obscurity"-Ansatz gewählt hast, ist er *absolut* nutzlos, wenn die
Obskurität preisgegeben wird.

Das sehe ich anders. Ich habe das Verfahren beschrieben. Die eigentliche
Verschlüsselung geschieht mit einem 32-Byte-Schlüssel, an dem nichts
obskures ist.

Dieser 32-Byte Schlüssel lässt sich aber doch ganz einfach aus dem
Startwert und dem Passwort generieren. Und für die Passwörter kann man
Bruteforce anwenden.

Post by Andre Sokolew

Post by Daniel Albuschat

Post by Andre Sokolew

Post by Heiko Nocon
Beim Disassemblieren fallen dann mit einiger Wahrscheinlichkeit auch
noch Informationen über den Aufbau der verschlüsselten Headerstruktur
ab, mit denen sich zumindest ein Teil der 128Bit zukünftig mit einigen
wenigen einfachen Operationen ermitteln lassen.

So blond bin ich nun auch wieder nicht, dass ich den Header mit demselben
Schlüssel belege wie die eigentlichen Daten.

Ob nun 1 Schlüssel, 2 oder 5, das Problem bleibt dasselbe.

Sorry, Du hast das Problem nicht verstanden, das Heiko ansprach.

Doch, was ich jedoch sagen wollte ist nur, dass verschiedene Layer
des gleichen Verfahrens zwar mehr Verwirrung, aber nicht mehr Sicherheit
mit sich bringen.

Post by Andre Sokolew

Post by Daniel Albuschat
Am besten wäre ein asynchrones Verfahren mit im Programm vergebenen
privaten und öffentlichen Schlüsseln, die irgendwo "sicher" abgelegt
werden.
Der Schlüssel selbst muss dem Programm bekannt, er darf aber nicht
zugänglich sein.

Falsch. Der Schlüssel darf dem Programm nicht bekannt sein.
Der Schlüssel _muss_ in dem Moment generiert werden, wenn die Daten
gespeichert werden, und er darf nirgendwo gespeichert werden.

Ok, ich hatte ganz vergessen, dass du ein vom Benutzer einzugebendes
Passwort benutzt.
Ich werde hier nochmal zusammenfassen (weil ich mangels Konzentration
beim Schreiben ein bisschen was durcheinander gebracht habe), was du
tust und was ich dazu zu sagen habe:

Du möchtest Daten mit Hilfe eines Geheimnisses (dem Passwort)
verschlüsseln. Da das Passwort nur wenige Bytes bietet, erweiterst du
es um einen zufälligen Wert. Soweit sogut.
Was ich daran bemängelt habe ist, dass bei jedem Verschlüsselungsvorgang
ein anderes Resultat bei raus kommt. Das kann je nach Situation
gegebenenfallls nachteilhaft sein. Da könnte man gegenwirken, indem
man das Geheimnis statt mit einem Zufallswert mit einem weiteren
geheimen Wert, der im Programm steckt, erweitert. Das allerdings
verschlechtert die Sicherheit. Falls dir egal ist, ob die Ausgangsdatei
bei gleichen Eingangsdaten immer gleich sind, kann dieser Punkt
getrost ignoriert werden.

Was jedoch viel wichtiger ist, ist dass die künstliche Verlängerung
wieder revidiert werden kann, wenn man herausfindet, wo sich der nicht
verschlüsselte Startwert befindet. Hier ist wieder nur ein Layer an
Obskurität hinzugekommen.

Außer bei einem Public-Key-Verfahren ist jede Verschlüsselung relativ
simpel durch Bruteforce knackbar [1]. Nicht umsonst gibt es
beispielsweise solche Programme für passwortgeschützte ZIP-Archive, die
sogar relativ gut funktionieren (bei ZIPs hat man es allerdings viel
einfacher, da man die dekomprimierten Daten anhand des Hashs, der in der
ZIP-Datei hinterlegt ist, validieren kann).

Alles in Allem halte ich das Verfahren für relativ sicher. Zumal man das
unterliegende Binärformat nicht kennt und es wahrscheinlich schwer hat,
korrekt entschlüsselte Daten als solche zu verifizieren.
Es kommt halt ganz darauf an, wie sicher du es haben möchtest.

Post by Andre Sokolew

Post by Daniel Albuschat
Also muss dieser über ein schwaches Verschlüsselungs-
verfahren geschützt werden. Und wer diese Verschlüsselung knackt, kann
dann auch die letztlich verschlüsselten Daten damit entschlüsseln...

Genau deshalb ist das Unsinn.

Da gebe ich dir Recht.

Post by Andre Sokolew
Der Schlüssel darf weder im Programm noch in der Datei gespeichert werden.

Nun, das kommt ganz auf das Scenario drauf an. Vielleicht kannst du dazu
noch ein bisschen mehr schildern?

Post by Andre Sokolew
Andererseits muss er zur Verfügung stehen, wenn die Datei berechtigterweise
entschlüsselt werden soll. Er muss zu diesem Zeitpunkt also neu generiert
werden, und zwar genau auf dieselbe Weise wie beim Speichern. Daran gibt es
nichts zu deuteln.

Wenn du "berechtigterweise" erwähnst, fällt mir noch folgender Punkt
ein:
Muss es eine Möglichkeit der Entschlüsselung geben, wenn das Passwort
verloren wird?
Von dieser Möglichkeit würde ich natürlich dringstens abraten, es kann
aber ggf. Scenarien geben, in dem dies von Bedeutung ist.
Beziehungsweise sollte der Fall des Geheimnisverlusts in der
Gesamprozedur um die verschlüsselten Daten berücksichtigt werden.

Post by Andre Sokolew
Meine Frage im OP bezieht sich darauf, ob ein MD5-Hash prinzipiell als
symmetrischer Schlüssel geeignet ist oder nicht.

Er ist genau so geeignet wie jeder andere 128-Bit-Wert.
Meiner Meinung nach nicht besonders.

Ich würde dir empfehlen, vielleicht andere Standard-
Verschlüsselungsverfahren wie AES und Komponenten/Bibliotheken, die
diese implementieren, anzuschaun.

MfG,
Daniel

[1] Public-Key-Verfahren natürlich auch, aber durch die künstliche
Verlängerung des Geheimnisses und häufig angewandten Methoden,
ein möglichst "kompliziertes" Geheimnis zu erzeugen (die ich nicht
im geringsten verstehe, weil ich kein Mathematiker bin), sind diese
weitaus sicherer.

[Andre Sokolew]

Post by Daniel Albuschat

Post by Andre Sokolew
Das sehe ich anders. Ich habe das Verfahren beschrieben. Die eigentliche
Verschlüsselung geschieht mit einem 32-Byte-Schlüssel, an dem nichts
obskures ist.

Dieser 32-Byte Schlüssel lässt sich aber doch ganz einfach aus dem
Startwert und dem Passwort generieren.

Das ist nun einmal so und gehört zum Prinzip. Das Geheimnis ist das
Passwort. Man könnte stattdessen auch eine Chipkarte oder einen
Magnetstreifen verwenden oder was auch immer, wenn die Technik zur Verfügung
stünde, grundsätzlich würde sich am Verfahren nichts ändern.

Post by Daniel Albuschat
Und für die Passwörter kann man Bruteforce anwenden.

Nein, eben nicht. Du verwechselst da was. Es ist etwas anderes, die
Hashwerte in der SAM des Betriebssystems auszulesen und so lange zu
probieren, bis sich eine Übereinstimmung ergibt, als hier Brute Force
anzuwenden.
Brute Force ist immer eine Frage des Aufwandes. Der wurde hier recht hoch
gelegt, zum Beispiel dadurch, dass der Angreifer erst sehr aufwendig
ermitteln muss, nach welcher "Übereinstimmung" er überhaupt suchen soll.
Auch der zufällige Startwert erschwert einen solchen Angriff ungemein, weil
eine vorbereitete Tabelle mit den Hashwerten der "gängigen" Passwörter
(darauf beruhen die Passwortknacker, die Du in den Zeitschriften an der
Tankstelle findest) nicht greift.
Ich behaupte nicht, dass es unmöglich wäre, aber der Aufwand ist hoch. Sehr
hoch.

Post by Daniel Albuschat

Post by Andre Sokolew

Post by Daniel Albuschat

Post by Andre Sokolew

Post by Heiko Nocon
Beim Disassemblieren fallen dann mit einiger Wahrscheinlichkeit auch
noch Informationen über den Aufbau der verschlüsselten Headerstruktur
ab, mit denen sich zumindest ein Teil der 128Bit zukünftig mit einigen
wenigen einfachen Operationen ermitteln lassen.

So blond bin ich nun auch wieder nicht, dass ich den Header mit
demselben Schlüssel belege wie die eigentlichen Daten.

Ob nun 1 Schlüssel, 2 oder 5, das Problem bleibt dasselbe.

Sorry, Du hast das Problem nicht verstanden, das Heiko ansprach.

Doch,

Nein.
Meiner ersten Beschreibung nach verwende ich _einen_ (recht kurzen)
Schlüssel immer wieder. Heiko merkte an, dass Header-Daten in der Regel
deutlich strukturiert sind und deshalb an bestimmten Stellen vorhersehbare
Bytes zu stehen haben. Dies zu verschleiern macht keinen großen Sinn, weil
man diese Verschleierung mit einem Disassembler leicht rekonstruieren kann.
Wenn man aber das Klar-Ergebnis und die Verschlüsselung dieses Ergebnisses
kennt, dann hat man daraus mit XOR sofort den Schlüssel - zumindest für
diese Bits, wenn nicht gar Bytes.

Durch eine wiederholte Anwendung dieses Schlüssels wären damit zumindest
Teile der Daten bereits geknackt, bevor die richtigen Waffen zum Einsatz
kommen. Somit hätte man vielleicht eine Chance, durch logische Analyse der
Daten - insbesondere unterstützt durch die fortlaufende Wiederholung des
recht kurzen Schlüssels - den Schlüssel zu erraten.

Sorry, dass ich anfangs dieses wichtige Detail vergessen hatte. Aber ich
habe mich schon berichtigt. Der Schlüssel für den Header wird nur einmal
angewandt. Die eigentlichen Daten werden mit einem anderen Schlüssel
verschlüsselt. Und da ist die Wiederholung des Schlüssels kein Problem, weil
durch die vorherige Komprimierung die Datenstruktur völlig unbekannt ist.
Der Angreifer weiß nicht, ob er ein x oder ein u sucht.

Post by Daniel Albuschat
was ich jedoch sagen wollte ist nur, dass verschiedene Layer
des gleichen Verfahrens zwar mehr Verwirrung, aber nicht mehr Sicherheit
mit sich bringen.

Heikos Einwurf bezog sich auf das, was ich eben noch einmal erklärte, da
trifft Dein Argument nicht zu.

Post by Daniel Albuschat

Post by Andre Sokolew

Post by Daniel Albuschat
Am besten wäre ein asynchrones Verfahren mit im Programm vergebenen
privaten und öffentlichen Schlüsseln, die irgendwo "sicher" abgelegt
werden.

Ich habe es mir vorhin verkniffen, aber jetzt muss ich es doch loswerden:
Abgesehen davon, dass kein vernünftiger Mensch größere Datenmengen mit einem
unsymmetrischen Verfahren verschlüsseln würde (es dauert schlicht zu
lange...), kann ich auch überhaupt nicht erkennen, was ein
Public-Key-Verfahren hier soll. Du hast selbst richtig erkannt, dass man den
privaten Schlüssel irgendwo sicher unterbringen muss. Das ist hier nicht
möglich, Smartcard etc. scheiden definitiv aus.

Post by Daniel Albuschat
Du möchtest Daten mit Hilfe eines Geheimnisses (dem Passwort)
verschlüsseln. Da das Passwort nur wenige Bytes bietet, erweiterst du
es um einen zufälligen Wert. Soweit sogut.
Was ich daran bemängelt habe ist, dass bei jedem Verschlüsselungsvorgang
ein anderes Resultat bei raus kommt.

Das ist zwingend erforderlich.

Post by Daniel Albuschat
Das kann je nach Situation gegebenenfallls nachteilhaft sein.

Dann ist halt die Situation falsch.

Post by Daniel Albuschat
Da könnte man gegenwirken, indem man das Geheimnis statt mit einem
Zufallswert mit einem weiteren geheimen Wert, der im Programm steckt,
erweitert.

Nein, nein, nein!
Im Programm darf nichts stecken, was mit der Schlüsselerzeugung zu tun hat,
außer dem Algorithmus natürlich. Kein geheimer Wert! Wenn er im Programm
steckt, ist es kein Geheimnis mehr, das Programm hat der Kunde doch in der
Hand, der kann es untersuchen und wird den Wert finden.

Post by Daniel Albuschat
Was jedoch viel wichtiger ist, ist dass die künstliche Verlängerung
wieder revidiert werden kann, wenn man herausfindet, wo sich der nicht
verschlüsselte Startwert befindet.

Auch das ist falsch.
Der Startwert ist ja nicht geheim und wird deshalb nicht verschlüsselt. Er
dient auch nicht der Verlängerung des Schlüssels, sondern nur dazu, dass
jedesmal ein anderer Schlüssel erzeugt wird.
Beispiel: Der Normal-Benutzer wählt als Passwort "Sonne". Der zufällige
Startwert ist "&x4TG=#81Pgm".
Damit wird der Schlüssel aus "&xS4ToG=n#8n1Pegm" erzeugt. Du wirst zugeben,
dass eine solche Zeichenkette nicht in der Tabelle der gängigsten Passwörter
zu finden ist.
Der Witz am MD5-Hash ist, dass die Veränderung nur eines Bits bei der
Eingabe einen ganz anderen Hash-Wert ergibt. Viel Spaß beim Suchen nach
Übereinstimmungen.

Post by Daniel Albuschat
Hier ist wieder nur ein Layer an Obskurität hinzugekommen.

Keineswegs. Der zufällige Startwert ist ja auch nicht meine Erfindung,
höchstens meine Wortschöpfung. In der Literatur firmiert der unter dem Namen
"Salt" (Salz in die Suppe des Angreifers streuen...)

Post by Daniel Albuschat
Außer bei einem Public-Key-Verfahren ist jede Verschlüsselung relativ
simpel durch Bruteforce knackbar [1].

Grundfalsch.
Public-Key-Verfahren nicht per Definition sicherer als symmetrische
Verfahren, sie dienen einem anderen Zweck, weil damit das
Schlüsseltausch-Problem gelöst werden kann. Um Schlüsseltausch geht es hier
aber gar nicht.
Ich schrieb schon, dass Du über Public-Key-Verfahren erst nachdenken musst,
wenn Du weißt, wo und wie Du den privaten Schlüssel aufbewahrst.
Gängige PK-Verschlüsselungsverfahren (PGP etwa) sind Hybrid-Verfahren: Auch
hier wird jedesmal neu ein zufälliger symmetrischer Schlüssel erzeugt
(allerdings erheblich aufwendiger als ich das tat) und damit die Nachricht
verschlüsselt. Dieser symmetrische Schlüssel wird an die Datei angehängt(!)
und - jetzt kommt's - mit dem öffentlichen Schlüssel verschlüsselt. Nur wer
den privaten Schlüssel hat, kann den symmetrischen Schlüssel entschlüsseln.
Und dann wird der Rest der Datei durch ein ganz normales symmetrisches
Verfahren wieder entschlüsselt.

Post by Daniel Albuschat
Wenn du "berechtigterweise" erwähnst, fällt mir noch folgender Punkt
Muss es eine Möglichkeit der Entschlüsselung geben, wenn das Passwort
verloren wird?

Diese Möglichkeit darf es nicht geben.

Post by Daniel Albuschat

Post by Andre Sokolew
Meine Frage im OP bezieht sich darauf, ob ein MD5-Hash prinzipiell als
symmetrischer Schlüssel geeignet ist oder nicht.

Er ist genau so geeignet wie jeder andere 128-Bit-Wert.

Na, jeder andere sicher nicht.
Ein paar Mindestanforderungen müssen schon erfüllt sein...

Post by Daniel Albuschat
Meiner Meinung nach nicht besonders.

Warum nicht?

Post by Daniel Albuschat
Ich würde dir empfehlen, vielleicht andere Standard-
Verschlüsselungsverfahren wie AES und Komponenten/Bibliotheken, die diese
implementieren, anzuschaun.

Mir ist schon klar, dass man XOR nur unter bestimmten Bedingungen für die
Verschlüsselung nehmen kann. Die sind hier meiner Meinung nach gegeben.
Das Problem ist aus meiner Sicht nicht das Verschlüsselungsverfahren,
sondern die Implementierung des Verfahrens. Auch mit so einer
Fertig-Komponente, die idealerweise auch fehlerfrei arbeitet, kann man bei
der Implementierung noch fürchterlich viel falsch machen.

Das XOR-Verfahren wäre das sicherste aller denkbaren
Verschlüsselungsverfahren und man bräuchte an alle anderen Verfahren keinen
Gedanken verschwenden, wenn beim Entschlüsseln
- derselbe geheime Schlüssel zur Verfügung steht wie bei der Verschlüsselung
und
- der Schlüssel absolut zufällig, gleichverteilt und
- genausolang wie die Nachricht ist,
- außerdem nur einmal verwendet wird,
- ansonsten aber sicher geheim bleibt.
Das zu schaffen oder anzunähern ist Aufgabe der Implementation.
Für mich hat sich gezeigt, dass die Schlüsselerzeugung eines der
gravierendsten Probleme ist. Deshalb meine Frage im OP.

Andre

[Daniel Albuschat]

Hallo,

also nochmal in kurz:

Ohne eine genaue Situation zu kennen, kann ich nur sagen, dass dein
Verfahren grundsätzlich keine hohe Sicherheit bietet (128bit ist
relativ witzlos), es aber trotzdem schwierig zu entschlüsseln sein
*könnte*, da die entschlüsselten Daten evtl. nicht einfach als solche
erkannt werden können. Vielleicht für einen findigen Cracker aber doch.

Und noch eins: Wenn man beispielsweise zufällig zwei verschiedene
Ausgangsdaten erhält, von denen man weiß, dass sie dieselben
Eingangsdaten enthalten, ist das Finden und Bestimmten der zufälligen
Komponente wahrscheinlich ein Kinderspiel.

Ein Versuch, Sicherheit über die Komplexität des Algorithmus', statt
über die Stärke des Algorithmus' zu gewährleisten, scheitert im
Zeitalter von Disassemblern und Debuggern leider höchstwahrscheinlich.

MfG,
Daniel

[Heiko Nocon]

Post by Andre Sokolew
Meine Frage im OP bezieht sich darauf, ob ein MD5-Hash prinzipiell als
symmetrischer Schlüssel geeignet ist oder nicht.

Im Prinzip schon, jedenfalls bei Verwendung eines starken Algorithmus.

[Heiko Nocon]

Post by Andre Sokolew
Wie dann?

1) Garnicht verschlüsseln

2) Richtig verschlüsseln. Und richtig ist nur:
2.a) Anerkannt sicheres Verschlüsselungsverfahren
2.b) Starke Schlüssel
2.c) Nichtöffentliche Schlüssel nicht veröffentlichen, also insbesondere
auch nicht irgendwo im Code ablegen
Wird nur eine der drei Sachen von 2) mißachtet, kann man auch gleich 1)
machen.

Post by Andre Sokolew
So blond bin ich nun auch wieder nicht, dass ich den Header mit demselben
Schlüssel belege wie die eigentlichen Daten.

Du begreifst es nicht. Um den Header lesen zu können, muß der Schlüssel
dafür doch auch irgendwo stecken. Und er wird gefunden werden, weil dein
Code die Angreifer zwangsweise selber zu ihm führt.

[Andre Sokolew]

Post by Heiko Nocon

Post by Andre Sokolew
So blond bin ich nun auch wieder nicht, dass ich den Header mit demselben
Schlüssel belege wie die eigentlichen Daten.

Du begreifst es nicht.

Es tut mir leid, aber das muss ich zurückgeben.

Post by Heiko Nocon
Um den Header lesen zu können, muß der Schlüssel dafür doch
auch irgendwo stecken.

Natürlich nicht, das wäre ja tödlich!

Post by Heiko Nocon
Und er wird gefunden werden, weil dein Code die
Angreifer zwangsweise selber zu ihm führt.

Der Angreifer kann keinen Schlüssel finden, weil der nicht gespeichert wird!
Ist das denn wirklich so schwer zu verstehen?
1) Der Schlüssel wird bei jedem Speichervorgang neu erzeugt, und zwar als
MD5-Hash
2) Damit trotz Benutzung desselben Passwortes jedesmal ein anderer Schlüssel
erzeugt wird, kommt ein zufälliger Startwert ("Salt") zum Passwort, bevor
der MD5-Hash erzeugt wird. Haupteffekt ist, dass der Angreifer für eine
Brute-Force-Attacke tatsächlich jedesmal alle Kombinationen durchprobieren
muss, ohne auf vorbereitete Hash-Tabellen mit den gängigsten Kennwörtern
zurückgreifen zu können.
3) Dieser zufällige Wert wird natürlich in der Datei gespeichert, und zwar
unverschlüsselt. Ist mit einem Disassembler auch leicht zu finden,
eigentlich reicht dafür ein Hexeditor. Aber erst in der Kombination mit dem
richtigen Passwort lässt sich der Hash-Wert erzeugen.
4) Der Hash-Wert wird als simpler XOR-Schlüssel für den Teil des Headers
benutzt, der die Eintrittspunkte der unterschiedlichen Tabellen enthält,
aber nur genau einmal. Deshalb ist nicht relevant, dass einzelne Bytes des
ersten Schlüssels durch die Header-Struktur verraten werden, es sei denn für
[*]
5) Sorry, Punkt 5) ist wesentlich, und ich hatte ihn in meiner ersten
Beschreibung unterschlagen (vergessen): Aus demselben Passwort, aber einem
anderen Zufallswert, wird nun ein zweiter und dann noch einmal ein dritter
Schlüssel gebildet, so existiert jetzt ein neuer Schlüssel mit 32 Byte
Länge.
6) Damit werden jetzt die Daten verschlüsselt, die durch die vorangegangene
Kompression eine völlig unbekannte Struktur aufweisen (die einzelnen Bytes
haben bereits vor der Verschlüsselung ziemlich gleichverteilt Werte zwischen
00 und FF). Durch die unbekannte Struktur der Ausgangsdaten lassen sich auch
auch aus der Wiederholung des 256-Bit-Schlüssels keine Rückschlüsse ziehen.

[*] Die Header-Struktur könnte einen Anhaltspunkt für Brute-Force liefern.
Der Angreifer kann daran erkennen, dass er einen Treffer gelandet hat. Je
besser die Passwort-Qualität ist, um so länger dauert das...

Andre

Post by Heiko Nocon
--
Wer Komponenten ohne Quelltext oder richtig miese Komponenten
oder gute Komponenten mit Quelltext, ohne die Source zu verstehen, sich verschafft,
um sie in Form "eigener" Programme in Verkehr zu bringen,
der wird mit Gefängnis nicht unter 5 Jahren bestraft.

[Arno Garrels]

Post by Andre Sokolew

Post by Heiko Nocon

Post by Andre Sokolew
So blond bin ich nun auch wieder nicht, dass ich den Header mit
demselben Schlüssel belege wie die eigentlichen Daten.

Du begreifst es nicht.

Es tut mir leid, aber das muss ich zurückgeben.

Post by Heiko Nocon
Um den Header lesen zu können, muß der Schlüssel dafür doch
auch irgendwo stecken.

Natürlich nicht, das wäre ja tödlich!

Post by Heiko Nocon
Und er wird gefunden werden, weil dein Code die
Angreifer zwangsweise selber zu ihm führt.

Der Angreifer kann keinen Schlüssel finden, weil der nicht
gespeichert wird!

Die Unbekannte ist und bleibt also das (weiche) Passwort.
Da bietet sich doch für den ungeübten Bruteforce an, oder?


Arno Garrels

[Andre Sokolew]

Post by Arno Garrels
Die Unbekannte ist und bleibt also das (weiche) Passwort.
Da bietet sich doch für den ungeübten Bruteforce an, oder?

Ja, das sehe ich auch so, dem "ungeübten" Angreifer gebe ich dafür allerding
gar keine Chance.

Die Frage ist, ob der Aufwand dafür in vernünftigen Grenzen gehalten werden
kann. Irgendein Passwortknacker aus den "Fachzeitschriften" von der
Tankstelle tut es definiv nicht. Der Angreifer braucht erhebliches Know-How,
muss einen Tag Arbeit oder länger in die Entwicklung eines Tools stecken,
dass den Angriff ausführen soll, und dann muss er noch eine Weile warten,
bis die Arbeit erledigt ist.

Heiko schrieb hier im Thread:
| Aber wie schon geschrieben, bei deinem Verfahren macht sich niemand
| die Mühe, das Passwort herausfinden zu wollen. Es ist sehr viel einfacher,
| den Schlüssel direkt anzugreifen statt die Schlüsselgenerierung.

Zumindest dem zweiten Satz stimme ich nicht zu.

Ich gehe davon aus, dass der qualifizierte Angreifer (nur über den reden
wir) recht schnell durch Disassemblierung begreift, was hier läuft, und sich
für den ersten Weg entscheiden muss.

Die Frage, die ich nicht beantworten kann, ist: Wie lange muss er einen
Computer rechnen lassen, um - bei einem Passwort vernünftiger Qualität - mit
einem Ergebnis rechnen zu können?
Für Hundert Prozent Erfolg muss er jedes denkbare Passwort ausprobieren und
dann noch ein paar Operationen ausführen, um festzustellen, ob er einen
Erfolg gelandet hat.
Die Verwendung von Spezial-Hardware schließe ich als völlig unangemessen
aus.
Was mich interessiert ist: Wie ist der Erwartungswert für eine
80%-Erfolgsquote bei Benutzung eines gängigen PCs?

Ich lese von Milliarden von Möglichkeiten... wie lange dauern eine Milliarde
Versuche? 15 min oder 15 Jahre? Wenn ein Versuch eine hundertstel Sekunde
dauert, braucht man für eine Milliarde Versuche 115 Tage. Dauert ein Versuch
dagegen eine zehntel Sekunde, braucht man dafür über drei Jahre. Das reicht.

Bei einem "weichen Passwort" braucht man keine hunderttausend Versuche, dann
geht es nur um 1000 Sekunden, selber schuld.

Andre

[Arno Garrels]

Post by Andre Sokolew

Post by Arno Garrels
Die Unbekannte ist und bleibt also das (weiche) Passwort.
Da bietet sich doch für den ungeübten Bruteforce an, oder?

Ja, das sehe ich auch so, dem "ungeübten" Angreifer gebe ich dafür
allerding gar keine Chance.

Das hab ich allerdings noch nicht verstanden. Wodurch gibst Du dem
Angreifer keine Chance?

Post by Andre Sokolew
Die Frage ist, ob der Aufwand dafür in vernünftigen Grenzen gehalten
werden kann.

Yau, Sicherheit ist.. eben relativ.

Post by Andre Sokolew
Irgendein Passwortknacker aus den "Fachzeitschriften"
von der Tankstelle tut es definiv nicht.

Wenn, dann hast Du es und deine Software sowieso geschafft.
Nimm es dann einfach sportlich und sonn Dich im Erfolg.

Post by Andre Sokolew
Der Angreifer braucht
erhebliches Know-How, muss einen Tag Arbeit oder länger in die
Entwicklung eines Tools stecken, dass den Angriff ausführen soll, und
dann muss er noch eine Weile warten, bis die Arbeit erledigt ist.

No Problem, so funktioniert das in der Hackerscene, ist die Software
interessant genug, gibt's natürlich auch einen, der sie knackt und
dafür lange genug ackert.

Arno Garrels

[Andre Sokolew]

Post by Arno Garrels
Das hab ich allerdings noch nicht verstanden. Wodurch gibst Du
dem Angreifer keine Chance?

Nicht dem Angreifer an sich, dem "ungeübten" Angreifer gebe ich keine
Chance.
Er braucht erhebliches Know-How (das nicht nur in der Hackerszene natürlich
vorhanden ist, deshalb ja meine Zweifel), dann kann er es schaffen - wenn er
genug Zeit hat.

Post by Arno Garrels

Post by Andre Sokolew
Die Frage ist, ob der Aufwand dafür in vernünftigen Grenzen
gehalten werden kann.

Yau, Sicherheit ist.. eben relativ.

Es beruhigt mich, dass außer mir das noch jemand so sieht. In der Brache der
Automobilbauer ist das übrigens eine Selbstverständlichkeit.

Post by Arno Garrels

Post by Andre Sokolew
Irgendein Passwortknacker aus den "Fachzeitschriften"
von der Tankstelle tut es definiv nicht.

Wenn, dann hast Du es und deine Software sowieso geschafft.

Nö, das reicht nicht.

Post by Arno Garrels

Post by Andre Sokolew
Der Angreifer braucht erhebliches Know-How, muss einen
Tag Arbeit oder länger in die Entwicklung eines Tools stecken,
dass den Angriff ausführen soll,

No Problem, so funktioniert das in der Hackerscene, ist die
Software interessant genug, gibt's natürlich auch einen, der sie
knackt und dafür lange genug ackert.

Die "sportlich motivierte" Hackerszene wird sich niemals um die
Verschlüsselung eines einzelnen Datenfiles kümmern.

Da geht es um das Knacken der Registrierschlüssel. Ich bin gebranntes Kind
diesbezüglich und verwende seit einiger Zeit dafür nur noch eine
RSA-Verschlüsselung. Der öffentliche Schlüssel steckt im Programm, der
private bleibt bei mir und steckt in dem Programm, dass die Lizenzschlüssel
verteilt.

Um der Nachfrage zuvor zu kommen: Ich glaubte RSA verstanden zu haben und
habe in Delphi eine Tiny-Version von RSA programmiert. Die hat auch
funktioniert. Danach hatte ich richtig verstanden. Deshalb verwende ich
diese Tiny-Version nicht in meinen Programmen, sondern eine kommerzielle
Komponente.

Andre

[Arno Garrels]

Post by Andre Sokolew

Post by Arno Garrels
Das hab ich allerdings noch nicht verstanden. Wodurch gibst Du
dem Angreifer keine Chance?

Nicht dem Angreifer an sich, dem "ungeübten" Angreifer gebe ich keine
Chance.
Er braucht erhebliches Know-How (das nicht nur in der Hackerszene
natürlich vorhanden ist, deshalb ja meine Zweifel), dann kann er es
schaffen - wenn er genug Zeit hat.

Post by Arno Garrels

Post by Andre Sokolew
Die Frage ist, ob der Aufwand dafür in vernünftigen Grenzen
gehalten werden kann.

Yau, Sicherheit ist.. eben relativ.

Es beruhigt mich, dass außer mir das noch jemand so sieht. In der
Brache der Automobilbauer ist das übrigens eine
Selbstverständlichkeit.

Post by Arno Garrels

Post by Andre Sokolew
Irgendein Passwortknacker aus den "Fachzeitschriften"
von der Tankstelle tut es definiv nicht.

Wenn, dann hast Du es und deine Software sowieso geschafft.

Nö, das reicht nicht.

Post by Arno Garrels

Post by Andre Sokolew
Der Angreifer braucht erhebliches Know-How, muss einen
Tag Arbeit oder länger in die Entwicklung eines Tools stecken,
dass den Angriff ausführen soll,

No Problem, so funktioniert das in der Hackerscene, ist die
Software interessant genug, gibt's natürlich auch einen, der sie
knackt und dafür lange genug ackert.

Die "sportlich motivierte" Hackerszene wird sich niemals um die
Verschlüsselung eines einzelnen Datenfiles kümmern.

Wir wissen ja nicht, was da an wichtigen Informationen enthalten
ist, wenn z.B. tausende von Kreditkartendaten enthalten sind,
lohnt sich ein Angriff allemal.

Post by Andre Sokolew
Da geht es um das Knacken der Registrierschlüssel. Ich bin gebranntes
Kind diesbezüglich und verwende seit einiger Zeit dafür nur noch eine
RSA-Verschlüsselung. Der öffentliche Schlüssel steckt im Programm, der
private bleibt bei mir und steckt in dem Programm, dass die
Lizenzschlüssel verteilt.

Damit verhinderst Du einen Keygenerator aber ein Patch tut's ja auch.
Das ist viel leichter zu bewerkstelligen, bringt aber auch weniger Ruhm.
Dagen hilft nur Code-Virtualisierung, ExeCryptor, Armadillo und andere
Produkte.

Arno Garrels

Post by Andre Sokolew
Andre

[Andre Sokolew]

Post by Arno Garrels

Post by Andre Sokolew
Da geht es um das Knacken der Registrierschlüssel. Ich bin
gebranntes Kind diesbezüglich und verwende seit einiger Zeit
dafür nur noch eine RSA-Verschlüsselung. Der öffentliche
Schlüssel steckt im Programm, der private bleibt bei mir und
steckt in dem Programm, dass die Lizenzschlüssel verteilt.

Damit verhinderst Du einen Keygenerator aber ein Patch tut's ja auch.
Das ist viel leichter zu bewerkstelligen,

Falsch.
Der Keygenerator für syymetrische Verschlüsselung läuft beim Hacker live, er
erzeugt einige Keys und veröffentlicht sie häppchenweise. Arbeitszeit meist
unter einer Stunde, vielleicht übertreibe ich hier sogar.
Eine Einführung in die Problematik erhielt ich 'mal auf einer Dienstreise
von einem Kollegen abends in der Hotelbar. Er klappte sein Notebook auf und
knackte die Stelle mit der Registrierung in meinem (ihm völlig unbekannten)
Programm in weniger als 10 Minuten. Außerdem versicherte er mir, dass er in
weiteren 15 Min einen kompletten Registrierschlüssel-Satz hätte. Ich
verzichtete, wollte danach verständlicherweise nur noch Bier trinken und
Erdnüsse knabbern und von was anderem reden.
Für einen Patch müsste der Hacker aber anfangen zu programmieren: Wenn es
etwas gibt, was Hacker hassen, dann ist es, für andere zu programmieren. Von
der Arbeit dabei ganz zu schweigen.

Post by Arno Garrels
Dagen hilft nur Code-Virtualisierung, ExeCryptor, Armadillo und andere
Produkte.

Kein sinnvolles Verhältnis zwischen Aufwand und fragwürdigem Nutzen. Wer
einen erkennbar illegalen Patch anwendet, ist definitiv kein potentieller
Kunde. Also ist er mir egal, soll er ruhig tun...

Die Verfahren der genannten Programme sind vielleicht sinnvoll, wenn man
spezielle (hocheffiziente und hochinteressante) Algorithmen geheim halten
möchte, das aber auch nur so lange, bis der Wettbewerber selbst ein besseres
Verfahren gefunden hat.

Ein funktionierender illegaler Registriercode im Internet kostet den
Shareware-Autor dagegen richtiges Geld, denn das fällt für die meisten unter
die Kategorie "Volkssport" und nicht unter "Betrug".

Andre

[Christian Gudrian]

Im einfachsten Fall reicht es aus, ein paar Bytes (manchmal gar nur ein
einziges) im Kompilat zu ändern. Dafür gibt es schon fertige Tools, die
prinzipiell wie ein binäres 'diff' arbeiten, also auch eine gewisse
Fehlertoleranz mitbringen.

Hab ich gehört.

Christian

[Hans-Peter Diettrich]

Post by Andre Sokolew
2) Damit trotz Benutzung desselben Passwortes jedesmal ein anderer Schlüssel
erzeugt wird, kommt ein zufälliger Startwert ("Salt") zum Passwort, bevor
der MD5-Hash erzeugt wird. Haupteffekt ist, dass der Angreifer für eine
Brute-Force-Attacke tatsächlich jedesmal alle Kombinationen durchprobieren
muss, ohne auf vorbereitete Hash-Tabellen mit den gängigsten Kennwörtern
zurückgreifen zu können.
3) Dieser zufällige Wert wird natürlich in der Datei gespeichert, und zwar
unverschlüsselt. Ist mit einem Disassembler auch leicht zu finden,
eigentlich reicht dafür ein Hexeditor. Aber erst in der Kombination mit dem
richtigen Passwort lässt sich der Hash-Wert erzeugen.

Da Salt bekannt ist, bleibt die Anzahl Versuche (für Paßwörter) unverändert.

Post by Andre Sokolew
4) Der Hash-Wert wird als simpler XOR-Schlüssel für den Teil des Headers
benutzt, der die Eintrittspunkte der unterschiedlichen Tabellen enthält,
aber nur genau einmal. Deshalb ist nicht relevant, dass einzelne Bytes des
ersten Schlüssels durch die Header-Struktur verraten werden, es sei denn für
[*]

Da vermutlich der Anfang der ersten Tabelle bekannt ist (gleich nach dem
Header), reduziert sich die Anzahl der notwendigen Versuche.

DoDi

[Andre Sokolew]

Post by Hans-Peter Diettrich

Post by Andre Sokolew
3) Dieser zufällige Wert wird natürlich in der Datei gespeichert, und
zwar unverschlüsselt. Ist mit einem Disassembler auch leicht zu finden,
eigentlich reicht dafür ein Hexeditor. Aber erst in der Kombination mit
dem richtigen Passwort lässt sich der Hash-Wert erzeugen.

Da Salt bekannt ist, bleibt die Anzahl Versuche (für Paßwörter) unverändert.

Natürlich.
Aber es gibt keine Rainbow-Tabellen mehr, die beschleunigend wirken.
Die Berechnungen werden erzwungen.

Post by Hans-Peter Diettrich
Da vermutlich der Anfang der ersten Tabelle bekannt ist (gleich nach dem
Header), reduziert sich die Anzahl der notwendigen Versuche.

Daran habe ich gedacht. Du vermutest deshalb falsch.

Mir ist völlig klar, dass XOR nur unter bestimmten Bedingungen als
"Verschlüsselung" durchgehen kann.
Entweder
- der Schlüssel ist mindestens so lang wie die zu verschlüsselnden Daten
(unerfüllbar) oder
- der Schlüssel ist hinreichend lang (so bei der EFS-Verschlüsselung) oder
- der Schlüssel ist eigentlich zu kurz, aber er verschlüsselt Daten, deren
Bytes zwischen 00 und FF einigermaßen gleichverteilt sind und deren Struktur
nicht bekannt ist.

Nur Punkt 3 ist erfüllt. Das reicht aber.

Die Komprimierung, von der ich schrieb, ist nicht wegen der Komprimierung
eingeführt worden (Nebeneffekt willkommen), sondern um unvorhersagbare
Datenstrukturen zu schaffen. Dabei fallen zwischendurch einige unbenutzte
Bits und auch einige unbenutze Bytes am Ende jeder Tabelle an. Du darfst mir
glauben, dass die nicht alle auf 0 stehen...

Meine Zuversicht, ich schrieb das schon, beruht ja darauf, dass der
Angreifer die Datenstrukltur nicht kennt, obwohl er den Algorithmus durch
Disassemblierung herausfinden kann.
So habe ich auch darauf geachtet, dass der Anfang der ersten Tabelle ohne
entschlüsselte Header-Daten nicht erkennbar ist. Genau deshalb wird der
zweite Teil des Headers überhaupt verschlüsselt. Es ist kein großer Aufwand,
Blöcke zu verschieben, die Wirkung ist aber gewaltig.

Die Frage ist im Kern: Wie lange dauert es auf einem handelsüblichen PC bei
einem MD5-Brute-Force-Angriff, eine Milliarde Passwörter auszuprobieren?

Andre

[Marian Aldenhövel]

Hi,

Post by Andre Sokolew
Würdet Ihr dieses Vorgehen für sicher halten?

Nein. XOR ist erledigt sobald Du einen Schlüssel wiederverwendest. Ist
der Schlüssel so kurz wie Deiner ist es sofort erledigt.

Auch wenn Du jetzt mit einer Version ankommst, bei der die Schwachstelle
nicht so gigantisch leuchtend hervortritt: Ich würde überhaupt nicht
darüber nachdenken. Verwende einen wohlbekannten Algorithmus in fertiger
wohl untersuchter Implementation (zum Beispiel aus OpenSSL) und fühle
Dich wohl.

Es gbt einfach keinen Grund einen eigenen Verschlüsselungsalgorithmus
zu erfinden.

Ciao, MM

[Andre Sokolew]

Es gbt einfach keinen Grund einen eigenen Verschlüsselungsalgorithmus zu
erfinden.

Das habe ich auch nicht versucht. Ich habe eine XOR-Verschlüsselung
implementiert, die als Schlüssel einen MD5-Hash verwendet, und frage mich,
ob Hash grundsätzlich dafür geeignet ist.
Die Wiederholung des Schlüssels sehe ich als unproblematisch an. Der
Angreifer weiß ohne Kenntnis der Originaldaten nicht, ob ein neuer String im
5.Bit des 37.Bytes anfängt oder erst im 3.Bit des 41.Bytes, er weiß schlicht
nichts über die Datenstruktur, obwohl er den Algorithmus, der zu dieser
Struktur führte, kennt. Werden die Originaldaten an einer Stelle geändert,
muss neu gespeichert werden - mit einem neuen Schlüssel. Wo soll da ein
statistischer Vergleich ansetzen?

Ich würde überhaupt nicht darüber nachdenken.

Sorry. Aber das Modul ist nun schon da.

Andre

[Marian Aldenhövel]

Hi,

Ich habe eine XOR-Verschlüsselung implementiert, die als Schlüssel einen
MD5-Hash verwendet, und frage mich, ob Hash grundsätzlich dafür geeignet
ist.

Ja. Für Daten die nicht länger sind als der Hash.

Die Wiederholung des Schlüssels sehe ich als unproblematisch an.

Das steht Dir frei. Ich sehe darin das Hauptproblem Deiner Idee.

Wo soll da ein statistischer Vergleich ansetzen?

Darüber würde ich nachdenken wenn ich eine solche Verschlüsselung brechen
wollte. Ohne eine solche Motivation verschwende ich keine Gedanken daran.

Aus Deiner Sicht halte ich die Mühe für verschwendet. Die Chance, daß Du
etwas übersiehst ist einfach viel zu groß. Nimm' etwas wohluntersuchtes wenn
es sicher werden soll. Oder lass' es bleiben wenn es nicht sicher zu sein
braucht.

"sicher genug" ist kein tragfähiges Konzept wenn wirklich gute Kryptographie
nichts kostet.

Sorry. Aber das Modul ist nun schon da.

Man kann es auch wieder wegwerfen. Aber das ist Deine Sache. Du befindest
Dich damit in zahlreicher Gesellschaft. Wenn auch nicht der besten.

Ciao, MM

[Andre Sokolew]

Post by Marian Aldenhövel
Darüber würde ich nachdenken wenn ich eine solche Verschlüsselung brechen
wollte. Ohne eine solche Motivation verschwende ich keine Gedanken daran.

Ich weiß, dass Du diese Meinung seit langem vertrittst, und ich respektiere
sie als Deine Meinung.

Post by Marian Aldenhövel
Du befindest Dich damit in zahlreicher Gesellschaft. Wenn auch nicht der
besten.

Das geht über eine Meinung, die ich respektieren muss, deutlich hinaus.
Du weißt überhaupt nicht, welchen Hintergrund diese Etüde hat und ignorierst
ganz bewusst das Problem, das hinter der Frage steckt. OK, das ist
zweifellos Dein Recht, nur steht Dir dann keine Bewertung zu und erst recht
keine Beschimpfung.

Andre

[Marian Aldenhövel]

Hallo,

Post by Andre Sokolew
nur steht Dir dann keine Bewertung zu und erst recht
keine Beschimpfung.

Beschimpfung war keine intendiert. Sollte das als solche rübergekommen
sein, bitte ich um Entschuldigung.

Was ich meinte war, daß Du Dich zu der großen Gruppe derer gesellst, die
meinen, ein Verfahren bei dem das Ergebnis zufällig aussieht oder aber
von ihnen selber nicht geknackt werden kann, wäre sicher. Das stimmt
einfach nicht.

Keines dieser Homebrew-Verfahren hat je gehalten. Bestenfalls hat aus
Desinteresse nie jemand einen Angriff unternommen, dann hätte man es sich
aber auch sparen können.

XORen von langen Daten mit kurzen Schlüsseln taugt einfach nicht. Also
ist der Kern des Verfahrens schon bekanntermaßen Quatsch. Also kann nix
gescheites dabei rauskommen. Schlüsselerzeugungsjedöns hin oder her.

Um Bewertung hattest Du explizit gebeten, also jetzt nicht beschweren
wenn die so ausfällt wie Du es gerne hättest.

Nimm doch einfach Deinen MD5-Hash und verwende ihn als Schlüssel für Twofish.
Und schon bin ich still :-).

Ciao, MM

[Andre Sokolew]

Post by Marian Aldenhövel
Nimm doch einfach Deinen MD5-Hash und verwende ihn als Schlüssel für Twofish.
Und schon bin ich still :-).

OK.
Das war konstruktiv. Danke.

Der Sinn der Etüde will aber MD5 und XOR.

Am Ende ist muss die Einschätzung stehen, dass das Verfahren
- allgemein brauchbar ist (natürlich nicht) oder
- für diesen speziellen Fall brauchbar ist (nach meiner derzeitigen
Überzeugung) oder
- generell unbrauchbar ist

Ich habe der bisherigen Diskussion entnommen, dass der Ansatz mit dem Hash
nicht ganz falsch ist, aber niemand meiner Versicherung traut, dass die zu
verschlüsselnden Daten quasi zufällig verteilt sind. Das wäre jedoch
notwendige Bedingung für eine wirkungsvolle XOR-Verschlüsselung mit "zu
kurzem" Schlüssel.

Natürlich werde ich Deinem Hinweis nachgehen und vergleichen.

Andre