FileCrypter 4.0

[Luckie]

FileCrypter 4.0

Features

• Verschlüsselungsalgorithmus: AES/Rijndael (Implementation von Hagen Reddmann - Delphi Encryption Compendium, DEC)
• Verschlüsselungstiefe mindestens 128 Bit (abhängig von Passwortlänge)
• Verbesserte Passwortsicherheit gegenüber Version 3.0
• Überprüfen des Passwortes beim Verschlüsseln durch Wiederholen der Eingabe
• Einschätzung der Sicherheit des Passwortes
• Optional sicheres Löschen der Quelldatei mit der Gutmann-Methode
• Anzahl der Überschreibvorgänge wählbar
• Fortschrittsanzeige beim Ver- und Entschlüsseln und beim Löschen.

Und um Fragen vorzubeugen, bezüglich der Verschlüsselungstiefe zitiere ich Hagen mal persönlich:

Zitat:

Sehr schwierige Frage. Ich könnte Topdown vorgehen und ausgehend vom Passwort bis in die Basics der Kryptographie alles erklären, oder ich gehe Bottomup vor, erkläre die Basics der Kryptographie und lande am Schluß bei der Passwortsicherheit. Für beides schreibe ich ein Buch mit mehr als 500 Seiten Wink

Man kann das Ganze nicht in zwei Sätzen formulieren, ausser man stellt quasi Behauptungen in den Raum.

Die Gesamtsicherheit einer Verschlüsselung definiert sich aus
- Wissen, und zwar wissenschaftlich mathematisch beweisbares Wissen, zu allererst die Logik
- der mathematisch berechnenbaren Komplexität von benutzten informationstheoretischen Verfahren (zb. AES, MD5, KDFs usw.), der Komplexität der benutzten Passwörter (meint die Bitgröße aber auch die Komplexität eines Rateversuches, also das die Passwörter nicht einfach das Geburtsdatum sind oä.)
- der technologischen und wissenschaftlichen Möglichkeiten als minimale Komplexitätschranke die für einen Angriff notwenig sind. Dh. je mehr die Mathematiker forschen je mehr Wissen erlangen sie und entwickeln immer bessere Verfahren um Kryptographie zu knacken. Das Gleiche gilt für die Entwicklung neuer Technologien, zb. FPGAs oder Quanteninformtik. Das alles fast man unter Kryptoanalyse zusamen und stellt den wissenschftlichen Forschungszweig dar der quasi der Kryptographie als Wissenschaft gegenüber steht.

Die Frage ob nun 128 Bit oder 256 Bit sicher sind, ob sie überhaupt sicher sind kann man also nicht nur an diesen Zahlen festmachen. Alleine schon das Verhalten der Benutzer kann Sicherheit sehr einfach zerstören, indem sie die Pin der EC Karte hintendrauf schreiben. Dann ist es egal ob bei der EC Karte 128Bit oder sogar 1024 Bit oder Milllionen-Bit Verschlüsselungen benutzt werden.

Heutzutage sagt man das 128 Bit Kryptographie sehr sicher ist. Das heist

1.) der komplette kryptographische Sicherheitspfad ist 128 Bit sicher. Angefangen beim Passwort das vergleichbar stark sein sollte wie ein 128 Bit echter Zufallswert bis hin zum 128 Bit Verschlüsselungsalgorithmus. Nun, KEINES der menschlich gewählten Passwörter kann jemals so sicher sein wie ein 128Bit Echt-Zufallspasswort.

2.) das nach heutigem Wissenstand es keine mathematischen und technologischen Verfahren gibt die eine Verschlüsselung nach Punkt 1.) in erträglich kurzer Zeitspanne knacken können.

So, die Fragestellung ansich zielt aber auf einen Penislängenvergleich ab. 256 sind mehr als 128 und demnach kann ich besser Frauen befriedigen. Alles Quatsch wie wir wissen.

Das A&O was es wirklich sicher macht, was uns wirklich Sicherheit gibt das unsere Daten gut geschützt sind ist: Wissen. Bei der Fragestellung ob nun 128 Bit weniger sicher ist als 256 Bit, wissen wir im Grunde reingarnichts. Wir wissen nicht welche Algortihmen benutzt werden, wir wissen nicht mit welchen Passwörtern der Benutzer arbeitet usw. usw. Ergo können wir diese Frage niemals korrekt beantworten. Wir können nur antworten:

Eine 256 Bit Verschlüsselung ist dann um ein Vielfaches, nämlich 2^128 mal, sicherer als eine 128 Bit Verschlüssellung wenn alle anderen nicht genannten Rahmenbedingungen im gleichen Verhältnis ebenfalls sicherer sind. Na super.

Wir könnten auch antworten:

Wir könnten annehmen das die 256 Bit starke Verschlüsselung unter sehr ungünstigen Rahmenbedingungen benutzt wurde im Vergleich zur 128 Bit Verschlüsselung mit idealen Rahmenbedingungen. In diesem Moment ist die 128 Bit Verschlüsselung im Besten Fall exakt 2^128 mal sicherer als die 256 Bit Verschlüsselung. Nämlich zb. exakt dann wenn dem Angreifer das 256 Bit Passwort bekannt ist. Na toll.

Die Sicherheit eines Gesamtsystemes ist also von sehr verschiednene Faktoren abhängig, primär aber immer von dem uns zur Verfügung stehendem Wissen.

Ein zu kurzes Passwort ist deshalb unsicher weil:

1.) man es leichter erraten kann
2.) man es leichter Durchprobieren kann
3.) man es leichter in einer Datenbank speichern kann

Obige Punkte sind sortiert in der Reihenfolge des Erfolges eines Angriffes, wobei Erraten am längsten dauert und eine effiziente Wörterbuchattacke am schnellsten geht.

Um solch ein Passwort vor Wörterbuchangriffen zu schützen benutzen wir einen Zufallssalt und eine KDF -> Key Derivation Function -> Schlüsselableitungsfunktion. Diese hat drei Aufgaben

1.) einen auf die maximal verarbeitbare Passwortlänge des Ciphers abgestimmten pseudozufälligen Sessionkey zu erzeugen um die maximal mögliche Sicherheit des Ciphers ausnutzen zu können.
2.) um das Passwort zu schützen, wenn es einem Angreifer gelungen sein sollte einen Sessionkey zu knacken. Der Schutz besteht darin das wir 1. eine Hashfunktion benutzt haben die verhindern soll das man vom Sessionkey zum Passwort berechnen kann und 2. weil wir einen Zufallswert mit einberechnet haben der den Angriff nur zu einem spezifischen Sessionkey ermöglicht der zum Zufallssalt gehört. Anderer Zufallssalt ergibt anderen Sessionkey und somit muß ein Angreifer erneut die Hashfunktion brechen um an's reale Passwort zu kommen.
3.) Verhinderung einer Wörterbuch Attacke indem man alle möglichen Paswörter als Datenbank vorrausberechnet, bzw. genauergesagt deren Hash=Sessionkey. Wird ein Zufallswert in der KDF benutzt so verhindert das diese Wörterbuch Angriffe sehr effizient.

Mit heutigen menschlichen Passwörtern ist es im Grunde egal ob wir AES mit 128 Bit oder 256 Bit arbeiten lassen. Die Passwörter selber, selbst mit KDFs zusammen, ist weit weniger sicherer als 128 Bit. Man müsste einen Phantasietext mit ca. 128*3.6/8=58 Buchstaben benutzen. Hast du jemals so lange Passwörter benutzt ?

Denkt man man wäre clever weil man 128/256 echte Zufallspaswörter benutzt dann täuscht man sich. Denn man muß irgendwo diese nicht merkbaren Passwörter speichern. Also benutzt man einen sogennaten Passwortsafe, speichert darin verschlüselt diese super guten Passwörter und schützt sie wiederum mit einem viel zu kurzen menschlichen Passwort. Bums, und schon ist die Sicherheit viel gernger als ohne diesen Passwortsafe. Denn dieser Safe speichert ganz viele solcher Passwörter mit einem unsicheren Passwort geschützt. Knacke ich diesen Safe habe ich mehr Zugangsberechtigungen als ohne diesen Safe.

Wie du siehst, die heutigen kryptographischen Algortihmen wie AES + SHA1 + KDF + Zufallsgeneratoren sind selbst mit 128 Bit Sicherheit in 99.99% aller Anwendungsfälle weiteraus sicherer als die damit benutzten Passwörter der Menschen. Sich nun wegen 256 Bit kontra 128 Bit zu streiten ist gelinde gesagt am Thema vorbei.

Hast du schon mal OphCrack benutzt um deine Windows-Login -Passwort zu knacken ? Diese Software knackt in Minuten den LM_Hash der Loginpasswörter. Das geht weil die Entwickler bei M$ geschlafen haben (wahrscheinlich unter Zwang) und eben keine KDF mit Zufallssalt benutzt haben. Ob nun Windows dafür mit 128 Bit oder 256 Bit arbeitet, ob wir 64 Bit oder 256 Bit Passwörter benutzt ist dabei egal. Das Verfahren ist absichtlich schlecht konstruiert und deshalb unsicher.

Shit, meine PN wird länger und länger und ich komme trotzdem nicht auf den Punkt.

Ach, arbeite dich selber in die Kryptographie ein, denn nur dann hast du selber alles Wissen um zu wissen was sicher sein wird und was nicht. Das beste wird sein auf entsprechende Literatur zu verweisen. Ich kann es auf jeden Fall nicht in par Sätzen erklären Wink

Gruß Hagen

Und

Zitat:

Um deine Frage kurz und bündig zu beantworten:

Wenn du wie von mir empfohlen mit DEC arbeitest und entsprechende KDFs mit Zufallssalt benutzt dann beträgt die Länge des Sessionkeys exakt der maximalen Länge des benutzbaren Passwortes der Verschlüsselungsfunktion. Wenn also AES maxmal 256Bit große Passwörter benutzt dann wird das mit der KDF auch ausgenutzt, auf's Bit exakt. Wenn man RC4 benutzt dann sind es 1024 Bit, was aber nicht heist das das dann sicherer ist als AES, da RC4 eben algorithmisch betrachtet nicht so komplex ist wie AES. Aber DEC mit KDFs benutzt bei RC4 eben 1024 Bit große Sessionkeys. Wenn bei beiden Verfahren das Passwort aber nur "a" ist dann sind beide eben auch unsicher.

Da wir einen 128Bit=16Bytes Salt benutzen beschränkt sich die Sicherheit vor Wörterbuchattacken auch nur auf 128 Bit. Aber was heist dies nun ? Es heist das ein Angreifer 2^128 * 2^128 Salt|Passwortkombinationen in der DB speichern müsste, mit jeweils 256 +128+128 Bit=64Bytes pro Datensatz, also im schlechtesten Falle hat diese Datenbank eine Größe von 64*2^128*2^128 Bytes = 2^262 Bytes , ausrechnen kannste das selber. Das ist eine gigantische Komplexität, praktisch selbst in vielen Jahren nicht durchführbar, ergo sicher.

Gruß hagen

[HalloDu]

Also sobald ich das Programm starten möchte, meldet er mir, dass ihm die FastMM_FullDebugMode.dll fehlt.
Da scheint wohl jemand den FastMM in den uses vergessen zu haben

[Luckie]

Nein. Ich habe nur vergessen die Compiler-Switches von Debug auf Release zu stellen. Und die Sourcen fehlen auch noch sehe ich gerade.

So, jetzt sollte alles passen.

[Sultan]

Hi
Danke für dein tolles exampel.
Habe mir dec 5.1c besorgt und instaliert wie in der readme.
Habe dann versucht deinen source zu compeliren,aber ich erhalte diese errormeldung.

[Fehler] DECUtil.pas(239): Undefinierter Bezeichner: 'CRC32'
[Fataler Fehler] Encrypt.pas(20): Verwendete Unit 'DECUtil.pas' kann nicht compiliert werden

Dabei kann ich Hagen seine exampels von Dec 5.1 compeliren ohne fehler?
Könntest du mir bitte weiter helfen.
Ps zu deinem Programm läüft echt spitz
Mfg
Sultan

[Luckie]

Aber nicht hier in diesem Thread.

[Luckie]

Neue Version verfügbar. Die Anzahl der Überschreibvorgänge lässt sich jetzt wählen. Voreingestellt ist 35 mal, weil das die empfohlene Anzahl ist.

Aktuelle Version im ersten Posting.