Dakuan
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Bevor ich selber versuche Algorithmen wie Blowfish oder Twofish in meine Programme zu integrieren, möchte ich wissen, ob es in den Ubuntu Quellen vergleichbare Funktionen gibt. Außer crypt habe ich jedoch bisher nichts gefunden, was aber auch an ungeschickt gewählten Suchbegriffen liegen könnte. Also ich möchte nicht per Befehl eine komplette ausgewählte Datei verschlüsseln, sondern mein Programm soll nur einzelne Datensätze innerhalb einer von ihm genutzten Datei verschlüsseln. Die Datensätze sind eigentlich nur eine Aneinanderreihung von Containern, und davon sollen auch nur die Nutzdaten verschlüsselt werden, da man die Kopfdaten der Container leicht erraten kann, was dann wohl eine "known plaintext attack" erleichtert. Es sollte jedoch eine symmetrische Verschlüsselung sein, da es sich um lokal gespeicherte Daten und nicht um eine Kommunikation handelt. Außerdem würde mich interessieren, wie man am besten das Passwort zu einer Datei speichert, ohne das es zu leicht eratbar ist. Man kann es ja schlecht in der Datei abspeichern, aber irgendwie sollte das Programm erkennen können, ob das Kennwort richtig ist, da man sonst riskiert, das dass Programm Amok läuft. Wie sollte ich da am besten vorgehen?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7655
|
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12821
|
frostschutz schrieb:
Oder openssl...
Da gibt es symmetrische Verschlüsselung? Wieder was gelernt. 👍
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Danke. Das ist zwar einiges zum lesen, klingt aber gut und habe ich jetzt sogar in den Paketquellen gefunden. Das ist ja fast wie im Krimi, alle üblichen Verdächtigen sind versammelt.
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Ich muss das leider noch einmal aufgreifen. Also unabhängig von der verwendeten Verschlüsselungsmethode stellt sich noch die Frage, wie ein Programm feststellen kann, ob das gegebene Kennwort richtig ist. Man kann das Programm natürlich mit dem eingegebenen Kennwort einfach loslaufen lassen und riskieren, dass das Programm dann mit den falsch entschlüsselten Daten abstürzt. Bei einem echten Angreifer ist das wahrscheinlich sogar die gewünschte Reaktion, aber auch als rechtmäßiger Benutzer habe ich es schon geschafft, das Kennwort 3 mal falsch einzugeben, weshalb ich diese Option nicht gut finde (ich habe hier etwa 6 PCs rumstehen, da kann man schonmal etwas verwechseln). Kommerzielle Programme erkennen die Falscheingabe ohne Absturz. Aber ich kann ja wohl schlecht den erzeugten Schlüssel oder das Kennwort direkt in der Datei abspeichern. Als ich noch mit Windows gearbeitet hatte, hatte ich mal das Buch "Angewandte Kryptographie" von Bruce Schneier gelesen, aber da wird nur das Problem des Schlüssel Austausches allgemein behandelt, wo ich jetzt keinen Zusammenhang mit diesem Problem erkennen kann. Kann mir da vielleicht nochmal jemand mit zweckdienlichen Hinweisen auf die Sprünge helfen?
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5330
|
AFAIK hat Truecrypt das festgestell, indem es am Beginn der Container immer ein "TRUE" geschrieben hat. Ist das beimm entschluesseln dann rausgekommen, ist das Passwort richtig. Daher auch der Name ☺ Wuerde mich auch interessieren, wie das sonst so gemacht wird.
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Ich bin ja kein Kryptoanalytiker, aber wenn ich sowas lese, höre ich im Hinterkopf immer so etwas wie "Known plaintext attack". Ich habe allerdings auch schon überlegt, das Kennwort selbst als ersten verschlüsselten Block in der Datei abzulegen. Aber nachdem ich diverse Artikel über Fehler bei Verschlüsselungsverfahren gelesen hatte, bin ich stark verunsichert. Also wenn ich alleine den Enigma Artikel in der Wikipedia und einige TV Beiträge zu diesem Thema betrachte, sehe ich die größte Gefahr immer ansatzweise darin, das bestimmte erwartete "Floskeln" den Angriff erleichtern könnten. Bei der Enigma war das natürlich "Wehmachtskommando gibt bekannt" und "sofort" (in Deutschland muss, wie alle Welt weiß, alles sofort geschehen). Diese Erkenntnis stammt aus einem BBC Film. Wenn ich weiß, das bei Truecrypt immer "TRUE" auftaucht, könnte das auch ein Angriffspunkt sein. Aber da ich kein Fachmann bin und den Zusammenhang nicht genau kenne, kann ich da auch falsch liegen. Momentan redet da mein Bauchgefühl.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7655
|
Also unabhängig von der verwendeten Verschlüsselungsmethode stellt sich noch die Frage, wie ein Programm feststellen kann, ob das gegebene Kennwort richtig ist.
Indem du dir einen Hash davon merkst. Vorzugsweise einem teuren Hash, also z.B. mit PBKDF2 wie bei cryptsetup. Da läuft es ungefähr so: Du gibst deine Passphrase für den Keyslot ein. Der sieht so aus (luksDump Auszug): Key Slot 0: ENABLED
Iterations: 696598
Salt: d4 19 fc fe 7b 35 90 61 b7 6a 30 87 bf 22 14 4a
3d 68 9e 79 bd 88 fd c9 f7 ef 35 e8 8c 0e f0 29
Key material offset: 8
AF stripes: 4000 Also deine Passphrase erstmal zusammen mit dem zufälligen Salz 696598x durch die Hashfunktion. Mit dem Ergebnis wird das Keymaterial entschlüsselt. Das ergibt den eigentlich zur Verschlüsselung verwendeten Master Key. Der kann nun folgendermaßen überprüft werden (luksDump Auszug): MK bits: 256
MK digest: 61 5e c4 a4 8f 25 3d 39 02 a0 53 4c b7 9e cf 5f 78 25 a7 8d
MK salt: 47 6d d5 38 74 1b 4d 10 3f 04 f1 85 ca 00 bf 19
56 99 92 0d c8 5c fa 35 bc e0 b9 f2 02 d0 56 ec
MK iterations: 174125 Also diesmal der Masterkey zusammen mit dem zufälligen Salz 174125x durch die Hashfunktion. Am Ende hast du dann den Hash (digest). Wenn der stimmt, dann war der Masterkey (wahrscheinlich) richtig, sonst nicht. Damit ein falsches Passwort trotzdem akzeptiert wird, müsstest du eine Kollision finden, was unwahrscheinlich ist.
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Danke, jetzt fange ich an zu verstehen wozu einige der anderen Funktionen in Nettle gut sind. Da habe ich wohl noch eine Menge Arbeit vor mir, bis ich das wirklich umsetzen kann.
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Es tut mir Leid, dass ich dies noch einmal ausgraben muss. Nachdem ich zwischenzeitlich abgelenkt war, habe ich mich wieder mit diesem Thema beschäftigt. Aber auch nach intensivem Studium bin ich nicht wirklich weiter gekommen. Mein Problem ist dabei, dass die Erklärungen / Beispiele nicht auf meinen Anwendungsfall anwendbar erscheinen. Ich habe den Eindruck, dass da immer ein Kommunikationskanal zwischen A (Alice) und B (Bob) gesichert werden soll. Aber es geht nie um eine zu verschlüsselnde Datei auf dem Rechner des Anwenders. Also, wenn ich z.B. mittels PBKDF2 (Nettle) einen Schlüssel generieren will, wird immer auch ein Salt gefordert. Dieser muss natürlich auch geheim bleiben. Ich kann ihn aber nicht in der Datei abspeichern, da er dann einem Angreifer bekannt währe, jedenfalls dann, wenn mein Programm Open-Source währe. Andererseits muss dieser Salt Wert beim Entschlüsseln ja wieder verfügbar sein. Ich sehe noch nicht, wie man diese Anforderung erfüllen kann. Bei einem Server kann man ja die KW Hash-Werte und die Salt-Werte an unterschiedliche Orten Speichern und ein Angreifer sieht nur die Kennwort-Eingabe. Aber wie soll das bei einer Verschlüsselten Datei auf einem Einzelplatzrechner funktionieren? Ich sehe noch nicht, wie das gehen kann. Was habe ich da nicht gesehen oder verstanden?
|
senden9
Anmeldungsdatum: 8. Februar 2010
Beiträge: 965
Wohnort: Österreich
|
So weit ich das System kenne muss der salt keineswegs geheim sein.
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Darüber sind die Meinungen sehr geteilt. In mindestens einem Wikipedia Artikel (Den ich jetzt aber nich wieder finde), wird dies aber auch behauptet. Im von mir gerade verlinktem Artikel heißt es allerdings: Wenn der verwendete Salt einem Angreifer bekannt ist, erhöht er nicht die Sicherheit bei einem Angriff auf dieses Passwort.
Wenn der Salt bekannt ist, kann ein Angreifer, der über ein entsprechendes Programm verfügt, einfach eine neue 'Rainbow Table' für das entsprechende Salt generieren. Wenn Salt unbekannt ist, muss er dies für alle möglichen Salt's machen.
Auch Bruce Schneier äussert sich in seinem Buch 'Angewandte Kryptographie' 1996 in entsprechender Weise. Von daher sehe ich den Salt-Wert nur dann als Möglichkeit, wenn auch der Programmcode geheim bleibt. → Security by Obscurity
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7655
|
Bei LUKS siehst du das Salt einfach so im luksDump (siehe oben). Das geheimzuhalten geht dann schon so in die Richtung von plausible deniability.
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Das würde jetzt aber bedeuten, das ein Bruce Schneier übermäßig paranoid ist? Oder die genannten Anforderungen gelten nicht für Dateien auf einem Anwender PC. Meine momentane Anwendung ist im weitern Sinne dem bekannten Programm "NoteCase" nachempfunden. Vielleicht sollte ich mir mal dessen Quelltext ansehen (was ich bisher bewusst vermieden hatte). Vielleicht benötigt man für die Verschlüsselung einzelner Dateien andere Methoden. Andererseits stellt sich da auch die Frage, wieviel Sicherheit benötigt wird, ausgedrückt in der Zeit, die zum Knacken mit üblicher Hardware erforderlich ist. Also, wenn ein Salt nicht geheim gehalten werden muss, kann ich auch komplett darauf verzichten. Ich frage mich jetzt, ob die etablierten Programme das machen. Es geht ja auch darum, das wenn einem Angreifer eine Datei vorliegt, er beliebig viele Versuche hat, das Passwort per 'Brute Force' Angriff zu entschlüsseln. Bei Open Source weiss er dann auch, wo der Hash Wert und ein evtl. angewendeter Salt zu finden ist. Ich wette darüber wüde sich die NSA freuen. Ich frage mich jetzt aber auch, ob es eine Lösung währe, vom Anwender zu verlangen 2 Passwörter einzugeben (einer quasi als Salt). Möglicherweise ist das aber nur eine verkleidete Verlängerung des eigentlichen Passworts...
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7655
|
Dakuan schrieb: Es geht ja auch darum, das wenn einem Angreifer eine Datei vorliegt, er beliebig viele Versuche hat, das Passwort per 'Brute Force' Angriff zu entschlüsseln.
Ja, wenn einem Angreifer der LUKS Header vorliegt, ist das ja auch so. Der Angriff an sich muss dann eben entsprechend rechenaufwendig sein (durch entsprechend viele Iterationen). Nur ohne Salt könnte dieser teure Vorgang eben einmal gemacht werden und dann auf alle LUKS Header der Welt angewendet werden, also im Prinzip eine LUKS-Rainbow-Table. Mit Salt musst du jeden LUKS Header aufs neue knacken.
Ich frage mich jetzt aber auch, ob es eine Lösung währe, vom Anwender zu verlangen 2 Passwörter einzugeben (einer quasi als Salt).
Lösung für was? Das Salz erledigt seine Aufgabe ja auch so schon. Ich glaube du hast da nur was falsch interpretiert... Ist dein Problem vielleicht daß du überall das gleiche Passwort hast? Das wäre ein Fall wo auch das LUKS Salz dann nichts mehr hilft, wenn du das Passwort von einem LUKS Header geknackt hättest, und zig andere deiner LUKS Header das gleiche Passwort haben, dann nutzt es diesen Headern natürlich auch nichts mehr daß sie ein anderes Salz haben.
|