Guten Tag,
ich habe ein Programm geschrieben, dass Alle Dateien in einem vorgegeben Pfad mit "eurem" Passwort verschlüsselt.

So funktionierts:
- Ihr wählt einen Ordner aus (siehe Hinweise)
- Ihr gebt euer Passwort ein
- Ihr drückt auf Encrypt (verschlüsseln) oder Decrypt (Entschlüsseln)

Hinweise:
- Falls ihr den Ordner ändern wollt, klickt doppelt auf das EditFeld wo ihr den Ordnerpfad seht.
- Wählt KEINE ganzen Festplatten aus!
- Wählt keine Ordner aus, indem Dateien geöffnet sind
- Wählt keine Systemdateien aus.


Falls die Verschlüsselung mittendrin aus irgendeinem Grund abbricht, ist Datei wahrscheinlich nicht wiederherstellbar. Falls dies eintreffen sollte, stehe ich dafür nicht gerade.
Für verlorene oder vergessene Schlüssel/ Passwörter übernehme ich ebenfalls keine Haftung.
somit verschlüsselt vorerst nur Kopien!

Wenn das Programm fertig ist, gibt es beim Entschlüssen steigende Töne aus. beim verschlüsseln eine sinkende Tonfolge.

Zur Sicherheit führt das Programm ohne Adminrechte aus, da sonst "ausversehen" Systemdateien verschlüsselt werden könnte.

Die BuffSize beträgt 0.1 GB. Falls eine Datei also > 0.1 GB solltet ihr mindestens 0.1 GB Ram besitzten

Viel Spaß und seit vorsichtig beim Testen

Zeiten nach Tests:
600 KB in 100 MS
55 MB in 6 sek

durchschnittlich pro MB: 9 MB pro sek.


Rev 1: Filestream durch mmf ersetzt, hierdurch ist es wesentlich schneller
Rev 2: -Passwort-Hash(MD5)
- Programm wird nicht standartmäßig geschlossen
- Ebenso kann der Schlüssel (Passwort) beim Verschlüsseln "versteckt" werden.
- Ini-File wird nun verwendet (für Settings und Hashs)
Rev 3: Menüführung (MainMenü) um die in Rev 2 eingeführten "Checkboxen" auszuwählen

Funktionieren tut es, ja. Der Ordner Dialog ohne Eingabefeld ist allerdings grausam. Viel einfacher wäre es, wenn man dort wie üblich auch einen vorher kopierten Pfad einfügen könnte.

Ich habe übrigens gerade mal auf einer SSD ein byteweises xor mit einer MMF ausprobiert, da liege ich bei 1,29 GiB bei 8,5 Sekunden... Ich denke deshalb nach wie vor, dass es sinnvoll ist damit zu arbeiten.

Bei dir sieht man in der aktuellen Implementierung, dass du schrittweise die Daten einliest und alle etwa 100 MiB schreibst. Ich habe es nach 4 Minuten abgebrochen, da war es schätzungsweise bei nicht einmal einem Drittel...

wie groß war denn deine Ordner+Dateien?
Bei 4 min dürften ca 2 GB bearbeitet worden sein...

MMF werde ich mir anschauen... Vielleicht haben noch mehr eine Meinung dazu?

Achja: TFastFileStream hat bei mir eigentlich kein Schnelligkeitsvorteil gebracht, weiß jemand warum?

IhopeonlyReader hat folgendes geschrieben :

Achja: TFastFileStream hat bei mir eigentlich kein Schnelligkeitsvorteil gebracht, weiß jemand warum?

Durch den Overhead, der entsteht, wenn du die Position ständig wechselst... bei MMFs ist es sinnvoller direkt mit dem Pointer auf die Daten zu arbeiten und dann nur danach die Position z.B. mit Inc weiter zu schieben.

hat jemand verbesserungsvorschläge? (abgesehen von der Schnelligkeit?)
Evt. sollte ich Nur Buchstaben zulassen und das ganze dann 6 Bit pro Buchstabe verwenden (6 Bit = 64 möglichkeite
['a'..'z', 'A'..'Z', '?', '!', ',', '.', '-', '_', '+', '#', ':', ';', '*', '~'] wären genau 64 Zeichen (26+26+12x1)
hierdurch wäre der Schlüssel schwerer zu erraten und somit sicherer, da ALLE Kombinaten dann vorkommen.

aber das war nur ein Beispiel, was wären eure vorschläge?

Ist folgendes richtig? (als Kommentar dahinter steht der Vergleich zum "normalen" TFilestream. Als Quelltext steht dort ein mmf
da ich noch nie mit MapFiles gearbeitet habe, bitte ich euch mal rüberzauschen (jaenicke )

Edit Freitag dem 13 : Quelltext gelöscht, da dieser vollkommen falsch war und sonst nur als "falsches" Vorbild dienen würde

IhopeonlyReader hat folgendes geschrieben :

Zeiten nach Tests: 600 KB in 100 MS

600KB in 100 Microsoft? Du meinst sicher ms (Millisekunden).

Macht es Sinn, die zu ver- und entschlüsselenden Daten direkt zu überschreiben?
Wenn ich ein Datei verschlüsselt habe und mit einem falschen Passwort entschlüssel, habe ich, wenn ich mir das falsche Passwort nicht gemerkt habe, die Daten ruiniert. Ist es nicht sinnvoller z.B. vor dem Verschlüsseln einen Hashtag zu generieren, diesen zu speichern und mit dem der in einem temporären Pfad entschlüsselten Datei zu vergleichen, bevor etwas überschrieben wird?

Mich stört es auch irgendwie, dass das Programm nur mit einem Dialog startet und sich nach erfolgreichen oder nicht erfolgreichen Prozedere gleich ohne Vorwarnung schließt.

ja, ich meine ms. Sorry aber Groß und Kleinschreibung daran muss ich mich noch gewöhnen
MS<>MS
Gb<>GB<>gb
gibt es eine Tabelle was was bedeutet?
Gbit oder Gbyte könnte ich verstehen, aber GiB und GB? oder heißt es gb :O

das mit dem Hash für das Passwort / die Passwörter wäre natürlich eine gute Möglichkeit.
Aber ebenfalls wäre es dadurch wesentlich unsicherer, da man viele Wörterkombinationen "testen" könnte und für die zutreffenden paar Dateien testen ob aus dem 3,4,5,6 letzten Bytes 3 Buchstaben und 1 punkt dabei sind.

Natürlich, wenn man sich vertippt ist es blöd, eine Sicherheitsabfrage baue ich deshalb gerne ein.
Einen Hash könnte ich auf "abfrage" mit erstellen lassen oder halt auch nicht (kleines häckchen)
Aber ich verschlüssel bei mir eher Sticks und ich würde Hashs bei dem Verschlüsselungsprogramm ablegen, wird der Stick also woanders entschlüsselt hat dieser diese Sicherheit wiederum nicht.

Dass dich der Programmstart nervt, da es direkt mit einem Ordnerdialog anfängt, verstehe ich.
Aber man will ja einen Ordner entschlüsseln, also muss man sicher einen auswählen, damit Man das nicht vergisst hatte ich das einfach mal an anfang gepackt.

Am Ende schließt sich das Programm, wenn es fertig ist. Das ist richtig.
Ich könnte nach dem "Signalton" das Passwortfenster leeren oder nicht (wie es eingestellt wäre)
anstatt das Programm zu schließen.

Also wird folgendes Verbessert:
- Ordnerabfrage erst später
- Menü mit 3 Checkboxen ( passwort-hash speichern, Programm wenn fertig schließen, Passwort nicht dauerhaft einzeigen (sobald eingelesen editfeld leeren) )

en.wikipedia.org/wiki/Gibibyte

Suchen hilft

ok KiB ist also das Binary-Kilo (1024 = 2^10)
und KB ist das Einheiten Kilo (10^3 = 1000)
ich kannte bisher nur KB für 1024 B aber jetz muss man ja KiB schreiben ,
ich bin mir nichtmal sicher ob Windows sich daran hält, denn 456 KB (466.944 Bytes) stimmt nur dann wenn KiB gemeint sind. Somit hält selbst Windows sich da nicht dran oder verstehe ich das mit KiB und KB falsch?
KB = 1000 Byte;
KiB = 1024 Byte;

Nachtrag: KB stimmt auch wiederum nicht. es müsste kB oder KiB sein. aber KB ist ein mittelding

Nicht ganz. Denn das SI Kilo wird mit einem kleinen k abgekürzt.

die neue Rev 1 basiert nun auf dem von jaenicke vorgeschlagenen mmf.
dadurch ist es erheblich schneller, allerdings auch fehleranfälliger.
Scheinbar "verschwinden" die Lese/Schreib fehler wenn man das mit admin-rechten startet, warum weiß ich nicht, da ich mich mit mmf kaum auseinandergesetzt habe.

Zeit: Encrypt 1,5 GB in 24 sek
Decrypt 1,5 GB in 17 sek
wobei mein Pc nicht der schnellste ist.

die von Marc vorgeschlagenen/verbesserungen werde ich in den nächsten tagen vornehmen.
Aber ich denke allein durch die neue Schnelligkeit lohnt sich ein "update"

1) jau. Closed Source. Mag ich.


2) XOR .. jau ... => s. 1)
die neuen Zufallsgeneratoren arbeiten auch so ;D


3) OK, der Dateiname wird mit gespeichert und verschlüsselt.
ORINGINAL
C:\00\neu.txt
Size: 8094 bytes
Entropy: 4.907217
Mean: 88.710156
Median: 101.000000


C:\001\0--verschlüsselt--.txt
Size: 8103 bytes
Entropy: 5.934476
Mean: 33.073430
Median: 21.000000

nicht so der Bringer. Hätte wenigstens was bei >7,0 erwartet. (7,99-8,0 ist fast unmöglich)
Vermutlich rührt die stärkere Entropie vom mitverschlüsselten Dateinamen her.

Zitat:

mit "eurem" Passwort verschlüsselt

Hey, OK, es verschlüsselt wenigstens mit "MEINEM" Passwort.
Schön, daß es das nicht zuvor im Klartext an Facebookt oder den NSA gesendet hat.

Zitat:

Falls die Verschlüsselung mittendrin aus irgendeinem Grund abbricht,

äh, was aber nicht unbedingt an Deiner Programmierung liegt, hoffe ich? ;D
(OK, der war gemein ... nich übel nehmen )

Zitat:

Evt. sollte ich Nur Buchstaben zulassen

äh, inwiefern erhöht das (x aus 64 Zeichen) die Sicherheit gegenüber 256 Möglichkeiten je Passwortzeichen? Du mußt das Passwort ja nur abfragen, nicht anzeigen.
Sag mal gehörst Du zu den Programmierern bei Microsoft oder NSA?
(die verwenden auch geringere Schüsselräume)

Zitat:

hat jemand verbesserungsvorschläge?

ja, Open Source
besonders, seit nicht mal mehr Zufallsgeneratoren zufällässig zu arbeiten scheinen.


nette Idee, das ganze zu erlernen ...

(Wüsche viel Erfolg. Hoffe, Du nimmst mir die Kommentare nicht übel.)

aber was macht das (Verschlüsseln) heutzutage (11.09.2013 - 17.00-45) noch für einen Sinn?
(=> s. Nachrichten/News)

Hättest du mal bloß nicht die verschlüsselte Datei hier gepostet... Das Passwort ist "delphi"
(Geknackt ohne den Plaintext anzuschauen, nur mit dem Ciphertext)

Um hier den TE nicht im regen stehen zu lassen: Die Analyse funktioniert mit Hilfe einer Häufigkeitsanalyse und der Verteilung der Buchstaben in der Sprache. (Hat hier sogar mit der englischen Verteilung geklappt) Ist natürlich nur Möglich, wenn der Schlüssel wesentlich kürzer ist als der Plaintext.

Anwender hat folgendes geschrieben :

1) jau. Closed Source. Mag ich.

ja, deshalb in dieser sparte

Anwender hat folgendes geschrieben :

2) XOR .. jau ... => s. 1) die neuen Zufallsgeneratoren arbeiten auch so ;D

Ja xor, und die neuen Zufallsgeneratoren arbeiten mit der Systemzeit soviel ich weiß.

Anwender hat folgendes geschrieben :

3) OK, der Dateiname wird mit gespeichert und verschlüsselt.

ja, sonst könnte man jpgs oder so zu leicht entschlüsseln, da man weiß dass es entschlüsselt ein "sinnvolles" bild ergeben sollte..
Manche Dateitypen haben auch "0"-er Reihen. wenn dein Passwort zu kurz ist, hätte man es da eindeutig zu sehen

Anwender hat folgendes geschrieben :

Hey, OK, es verschlüsselt wenigstens mit "MEINEM" Passwort. Schön, daß es das nicht zuvor im Klartext an Facebookt oder den NSA gesendet hat.

Ja, leider ist dort sehr viel rausgekommen Nein es ist gut! Gemacht wird es so oder so. durch snwoden erfahren wir immerhin dass Amerika technisch viel weiter ist als wir und Deutschland wird dadurch nun technisch einen Sprung machen (im Bereich Spionage )!
Wirst du lieber geheim überwacht oder ist es dir lieber, dass du weißt was ca. überwacht wird?

Anwender hat folgendes geschrieben :

äh, was aber nicht unbedingt an Deiner Programmierung liegt, hoffe ich? ;D

Nein, aber falls man von außen zugreift und irgendwie einen "fehler" erzeugt, kann es nunmein sein dass es abbricht. Manchmal auch weil man für Datei 3/5 mehr rechte braucht. Dadurch scheitert dann das "öffnen" und es kann nicht gelesen/geschrieben werden. Datei 1,2 sind nun verschlüsselt 3bis 5 allerdings nicht.

Anwender hat folgendes geschrieben :

äh, inwiefern erhöht das (x aus 64 Zeichen) die Sicherheit gegenüber 256 Möglichkeiten je Passwortzeichen? Du mußt das Passwort ja nur abfragen, nicht anzeigen.

Das anzeigen ist nicht das Problem, sondern dass man bei Passwörtern meistens Wörter nimmt !
Wörter bestehen aus Buchstaben (Aus dem Alphabet)
'A' bis 'Z' sind die ByteWerte 65 bis 90 !
es kann also ausgesagt werden, dass das 1 bit (128) eigentlich nie benutzt wird.
eigentlich werden doch nur a bis z, A bis Z und evt 1 bis 10 verwendet, dass sind 26*2 +10 = 62 Zeichen.
So kann man einzelne Bits ausschließen und Teile wiederherstellen (da bestimme bits immer 0 sind)
Ich würde es gerne so machen, dass eben alle bits gleichwahrscheinlich 0 oder 1 sind.

Anwender hat folgendes geschrieben :

Sag mal gehörst Du zu den Programmierern bei Microsoft oder NSA? (die verwenden auch geringere Schüsselräume)

Woher weißt du das :O

Anwender hat folgendes geschrieben :

ja, Open Source

ist alles quick and dirty. danach verbessert.. das heißt die gui ist ordentlich, aber in der unit wo die Funktionen drin sind ist Unordnung
was du wissen willst kann ich auch nennen oder als quelltext posten. Aber dann halt Teile..

Anwender hat folgendes geschrieben :

besonders, seit nicht mal mehr Zufallsgeneratoren zufällässig zu arbeiten scheinen.

Wie, was :O Also es gibt zufall? Seit wann? Alles ist abhängig von Parametern (bitte keine Quantenmechanik jetzt Leute !, da sind nur die Parameter noch nicht gefunden) auch der von dir erwähnte zufall ist abhängig von Parametern, der Computer nutzt dafür die Computerzeit( Systemzeit)

Anwender hat folgendes geschrieben :

nette Idee, das ganze zu erlernen .. (Wüsche viel Erfolg. Hoffe, Du nimmst mir die Kommentare nicht übel.)

Danke Nein kritische Kommentare sind auch immer willkommen... Wobei meine "Verteidigungsversuche" euch nicht davon abhalten sollen! Bitte begründet nur euer Statement auch
Aber was meinst du mit "nette Idee, das ganze zu erlenrn"?, willst du auch "Verschlüsseln" können?

Anwender hat folgendes geschrieben :

aber was macht das (Verschlüsseln) heutzutage (11.09.2013 - 17.00-45) noch für einen Sinn? (=> s. Nachrichten/News)

Wenn keiner den Schlüssel kennt (wie SSL), ja ich weiß dass es "geknackt" wurde, aber aufgrund von schlechter Schlüsselaufbewahrung !
dann ist es eigentlich Sicher. Natürlich ist es entschlüsselbar, genau wie hashs. Es gibt viele Möglichkeiten (2^(8*Dateigröße in Byte)), da der Schlüssel wahrscheinlich nicht genausolang wie die Datei ist, ist es wesentlich kleiner!
Aber wie gesagt, da man aus dem Dateinamen schon relativ viel interpretieren kann, verschlüssel ich diesen mit. Leider liegt hier das Problem vor, dass in den letzten 4 Zeichen normalerweise 1 Punkt vorliegt. Somit kennt man 1 Byte (Zeichen) aus dem Schlüssel. Verbindet man das mit einem Lexikon und "sinnergebenden" Sätzen, sowie den meist verwendeten Passwörten (dank Facebook und co. sind diese inzwischen sehr genau) ist es schon wieder relativ leicht zu knacken.
Wobei hierfür viel Erfahrung, Rechenpower und natürlich Kenntnisse erforderlich sind.

IhopeonlyReader hat folgendes geschrieben :

Aber wie gesagt, da man aus dem Dateinamen schon relativ viel interpretieren kann, verschlüssel ich diesen mit. [...] Wobei hierfür viel Erfahrung, Rechenpower und natürlich Kenntnisse erforderlich sind.

Eine so simple Verschlüsselung wie du sie im Moment benutzt, konnte man schon vor den ersten PCs knacken, wenn auch mit viel Aufwand. Die Enigma wurde auch geknackt, obwohl das schon deutlich komplizierter war.

Wenn dein Schlüssel lang genug ist nicht !

So, nun ist Rev 2 raus:
- Passwort mit Hash-Schutz (MD5)
- Programm wird nicht standartmäßig geschlossen
- Ini-File wird nun verwendet (für Settings und Hashs)
- Ebenso kann der Schlüssel (Passwort) beim Verschlüsseln "versteckt" werden.

weitere Vorschläge?

IhopeonlyReader hat folgendes geschrieben :

Wenn dein Schlüssel lang genug ist nicht !

Um genau zu sein so lang wie die zu verschlüsselnde Datei, dann ist das Verfahren kryptographisch sicher, sofern dieser Schlüssel auch nur einmal benutzt wird.

Also wie schon erwähnt, den Schlüsselraum zu verkleinern bietet nur die Möglichkeit es noch einfacher zu knacken
Ansonsten wäre es auch interessant, wenn du erzählst wie du verschlüsselst. Wenn es schon mit einer normalen Häufigkeitsanalyse klappt, die nicht mal die Schlüssellänge berücksichtigt, dann ist das ja grad mal das Niveau von einer Verschlüsselung für Grundschüler mit Cäsarchiffre

Sie war nicht ganz einfach: Erst wurde die wahrscheinlichste Passwortlänge ermittelt, und danach anhand der Länge die Häufigkeitsanalyse für jeden Buchstaben separat durchgeführt.