Entwickler-Ecke
Freeware Projekte - Xor- Ordner- Verschlüsselung
IhopeonlyReader - Mo 09.09.13 19:02
Titel: Xor- Ordner- Verschlüsselung
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
jaenicke - Mo 09.09.13 21:26
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...
IhopeonlyReader - Mo 09.09.13 22:24
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?
jaenicke - Di 10.09.13 09:49
 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.
IhopeonlyReader - Di 10.09.13 14:20
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?
IhopeonlyReader - Di 10.09.13 14:52
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 :D : Quelltext gelöscht, da dieser vollkommen falsch war und sonst nur als "falsches" Vorbild dienen würde
Marc. - Di 10.09.13 15:12
| IhopeonlyReader hat folgendes geschrieben : |
Zeiten nach Tests:
600 KB in 100 MS |
600KB in 100 Microsoft? :gruebel: 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. :nixweiss: 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.
IhopeonlyReader - Di 10.09.13 15:41
ja, ich meine ms. Sorry aber Groß und Kleinschreibung daran muss ich mich noch gewöhnen :D
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) )
IhopeonlyReader - Di 10.09.13 16:51
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 :D 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
FinnO - Di 10.09.13 16:53
Nicht ganz. Denn das SI Kilo wird mit einem kleinen k abgekürzt.
IhopeonlyReader - Di 10.09.13 22:13
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"
Anwender - Mi 11.09.13 17:01
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 :P)
| 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? :D
(die verwenden auch geringere Schüsselräume)
| Zitat: |
| hat jemand verbesserungsvorschläge? |
ja, Open Source :D
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)
jfheins - Mi 11.09.13 18:50
Hättest du mal bloß nicht die verschlüsselte Datei hier gepostet... Das Passwort ist "delphi" :P
(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.
IhopeonlyReader - Mi 11.09.13 20:52
| 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 :D 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 :D )!
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? :D
(die verwenden auch geringere Schüsselräume) |
Woher weißt du das :O
| Anwender hat folgendes geschrieben : |
| ja, Open Source :D |
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 :D
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.
jaenicke - Mi 11.09.13 21:39
| 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.
IhopeonlyReader - Mi 11.09.13 21:51
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?
jaenicke - Do 12.09.13 05:29
| 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.
richy-f - Do 12.09.13 13:01
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
jfheins - Do 12.09.13 13:05
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.
IhopeonlyReader - Do 12.09.13 14:19
| jfheins hat folgendes geschrieben : |
| 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. |
das ist das was ich meine, BUCHSTABEN!
Es werden nunmal bei Passwörtern eigentlich bestimmte Zeichen nie verwendet, bitte schaut euch mal folgende Liste an:
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
| 1: ; 2: ; 3:
4: ; 5: ; 6:
7: ; 8: ; 9:
10:
; 11: ; 12:
13:
; 14: ; 15:
16: ; 17: ; 18:
19: ; 20: ; 21:
22: ; 23: ; 24:
25: ; 26: ; 27:
28: ; 29: ; 30:
31: ; 32: ; 33: !
34: "; 35: #; 36: $
37: %; 38: &; 39: '
40: (; 41: ); 42: *
43: +; 44: ,; 45: -
46: .; 47: /; 48: 0
49: 1; 50: 2; 51: 3
52: 4; 53: 5; 54: 6
55: 7; 56: 8; 57: 9
58: :; 59: ;; 60: <
61: =; 62: >; 63: ?
64: @; 65: A; 66: B
67: C; 68: D; 69: E
70: F; 71: G; 72: H
73: I; 74: J; 75: K
76: L; 77: M; 78: N
79: O; 80: P; 81: Q
82: R; 83: S; 84: T
85: U; 86: V; 87: W
88: X; 89: Y; 90: Z
91: [; 92: \; 93: ]
94: ^; 95: _; 96: `
97: a; 98: b; 99: c
100: d; 101: e; 102: f
103: g; 104: h; 105: i
106: j; 107: k; 108: l
109: m; 110: n; 111: o
112: p; 113: q; 114: r
115: s; 116: t; 117: u
118: v; 119: w; 120: x
121: y; 122: z; 123: {
124: |; 125: }; 126: ~
127: ; 128: €; 129:
130: ‚; 131: ƒ; 132: „
133: …; 134: †; 135: ‡
136: ˆ; 137: ‰; 138: Š
139: ‹; 140: Œ; 141:
142: Ž; 143: ; 144:
145: ‘; 146: ’; 147: “
148: ”; 149: •; 150: –
151: —; 152: ˜; 153: ™
154: š; 155: ›; 156: œ
157: ; 158: ž; 159: Ÿ
160: ; 161: ¡; 162: ¢
163: £; 164: ¤; 165: ¥
166: ¦; 167: §; 168: ¨
169: ©; 170: ª; 171: «
172: ¬; 173: ; 174: ®
175: ¯; 176: °; 177: ±
178: ²; 179: ³; 180: ´
181: µ; 182: ¶; 183: ·
184: ¸; 185: ¹; 186: º
187: »; 188: ¼; 189: ½
190: ¾; 191: ¿; 192: À
193: Á; 194: Â; 195: Ã
196: Ä; 197: Å; 198: Æ
199: Ç; 200: È; 201: É
202: Ê; 203: Ë; 204: Ì
205: Í; 206: Î; 207: Ï
208: Ð; 209: Ñ; 210: Ò
211: Ó; 212: Ô; 213: Õ
214: Ö; 215: ×; 216: Ø
217: Ù; 218: Ú; 219: Û
220: Ü; 221: Ý; 222: Þ
223: ß; 224: à; 225: á
226: â; 227: ã; 228: ä
229: å; 230: æ; 231: ç
232: è; 233: é; 234: ê
235: ë; 236: ì; 237: í
238: î; 239: ï; 240: ð
241: ñ; 242: ò; 243: ó
244: ô; 245: õ; 246: ö
247: ÷; 248: ø; 249: ù
250: ú; 251: û; 252: ü
253: ý; 254: þ; 255: ÿ |
Welche Zeichen davon verwendet ihr in euren Passwörtern wirklich? Damit man eben diese anderen Zeichen (die die nie benutzt werden) nicht ausschließen kann, wollte ich diese direkt aus der Schlüsselerstellung rausnehmen.
So können auch 87 Bit schlüssel entstehen.. Das führt dazu, dass man es schwerer nach Buchstaben aufteilen kann. denn ein 87 Bit schlüssel wäre ein 696 Bit Schlüssel. Denn ab dann wiederholt sich der Schlüssel erst Byteweise, und soviel ich weiß arbeiten entschlüssel Byteweise und nicht Bit-Weise!
Ich könnte es auch so umbauen, dass ihr am Anfang ein Passwort eingebet, es dann in Bits umgewandelt wird (ihr seht nicht mehr Hallo sondern entsprechend 01101000 01000001 ... ) dann könntet ihr einzelne Bits ersetzten.
| richy-f hat folgendes geschrieben : |
| Ansonsten wäre es auch interessant, wenn du erzählst wie du verschlüsselst. |
Naja, der string wird als ByteArray betrachtet und dann wird Byte für Byte vom Bytearray mit Byte für Byte von der Datei ge-Xor-t. Ist der ByteIndex über dem High(ByteArray) dann wird der Schlüssel erneut verwendet.
Beispiel:
Schlüssel/ Passwort: A ( Code: 65 -> ByteArray hat eine Länge von 1)
Zu Verschlüsselnde Wort: Aber (länge 4)
Wort in Bits ausgedrückt: 01000001 01100010 01100101 01110010
Schlüssel ( entschprechend oft hintereinandergehängt):
01000001 01000001 01000001 01000001
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
| 01000001 xor 01000001 = 0000 0000
01100010 xor 01000001 = 0010 0011
01100101 xor 01000001 = 0010 0100
01110010 xor 01000001 = 0011 0011
//Verschlüsselte Text:
00000000 00100011 00100100 00110011 (0-35-36-51)
//als String
#$3 //Wobei 0 nichts anderes als "nichts" oder halt "StringEnde" bedeutet |
IhopeonlyReader - Do 12.09.13 16:03
Weiterer Vorschlag (vorallem für externe Speichermedien):
Ein String-Randomen ( zwischen 1 und 100 mb )
BeispielCode zum erzeugen der Strings:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
| var S: String;
Size, C: Cardinal;
FS: TFileStream;
const
MinSize = 1024*1024 * 1; MaxSize = 1024*1024 *100; begin
Randomize;
if SD.Execute then
begin
Size := Random( MaxSize-MinSize+1 ) + MinSize;
setlength( S, Size );
For C:=1 to Size do
S[C] := Char( Random(255)+1 );
FS := TFileStream.Create( SD.Filename, fmCreate or fmShareDenyWrite );
try
FS.WriteBuffer( Size, SizeOf(Size) );
FS.WriteBuffer( Pointer(S)^, Size*SizeOf(Char) ); finally
FS.Free;
setlength( S, 0 );
end;
end; end; |
Beim entschlüsseln müsste man dann (wenn extern-Medium-cryption an ist) die "Passwort" Datei laden. Und zusätzlich sein Passwort eingeben.
Hierdurch wäre sozusagen ein OneTimePad erstellt, dass dafür sorgt, dass man bestimme Ordner nur auf dem einem bestimmen PC öffnen kann, außer jemand merkt sich einen Schlüssel aus zwischen 1 und 100 Millionen Zeichen, wofür er teilweise nichtmal namen kennt :D
Für lokale Ordner würde dies natürlich nicht viel bringen, da das Pw ja auf dem Computer "unverschlüsselt" vorliegt. Da ist es mit und ohne "extern-cryption" genau so sicher wie mit.
jfheins - Do 12.09.13 16:28
Der Post zeigt, dass du dich entweder wesenlich mehr oder wesentlich weniger mit Verschlüsselung beschäftigen solltest ;-)
Random() ist nämlich nur ein PRNG, und kann mit 2^32 verschiedenen Anfangswerten geseedet werden. Ist dieser Startwert bekannt, können alle anderen Werte berechnet werden. Also egal wie lang du deine "Schlüsseldatei" machst, sie enthält nur 32bit Information, der Rest ist redundant.
IhopeonlyReader - Do 12.09.13 18:08
deswegen CodeBeispiel !das es endgültig nach dem Prinzip funktioniert, wie es dort aufgeführt wird.
Und ich dache Random würde über die Systemzeit laufen, seit wann ist es eine "festgelegte Reihenfolge" (wenn auch 1 von 2^32) ?
Wo steht das?
Sonst würde ich gerne selber ein Random bauen, auf Kenntnis von Systemzeit, "normalem Random", Hardware, offene Prozesse, Resourcenverbrauch eines Prozesses (zufällig?) was weiß ich nicht was. Hauptsache es ist nicht direkt "zurückverfolgbar"...
aber es geht um die Idee :)
Und auch so (mit diesem code) wäre die Datei sicherer verschlüsselt als ohne diese extern-verschlüsselung.
jaenicke - Do 12.09.13 20:33
| IhopeonlyReader hat folgendes geschrieben : |
| Und ich dache Random würde über die Systemzeit laufen, seit wann ist es eine "festgelegte Reihenfolge" (wenn auch 1 von 2^32) ? |
Es legt nach einem solchen Algorithmus den Startwert fest. Und von da aus ist die Reihenfolge dann fest.
Setz einfach mal RandSeed auf einen bestimmten Wert. Du wirst sehen, dass du immer die gleichen Zufallszahlen der Reihe nach bekommst.
Zufällig sieht das normalerweise nur aus, weil dieser RandSeed zufällig festgelegt wird. Deshalb sollte man auch nur einmal Randomize aufrufen und nicht während das Programm läuft immer wieder, weil man sonst noch weniger Zufall drin hat.
In der Doku, wo sonst? ;-)
http://docwiki.embarcadero.com/Libraries/XE5/de/System.RandSeed
Anwender - Fr 13.09.13 11:24
| BenBE hat folgendes geschrieben : |
| Tut mir leid, das so sagen zu müssen, aber auf schlechte Crypto bin ich allergisch. |
Zuspieler der NSA würden sich allerdings sehr freuen ;D
IhopeonlyReader - Fr 13.09.13 13:55
| BenBE hat folgendes geschrieben : |
| Tut mir leid, das so sagen zu müssen, aber auf schlechte Crypto bin ich allergisch. |
ok, der Thread heißt
| Zitat: |
| Xor- Ordner- Verschlüsselung |
und nicht
| Zitat: |
| NSA sicherer Ordner Verschlüsselung |
Dem Threadthema habe ich denke ich angemessenes Programm vorliegen.
Natürlich wäre es schön, gerade nachdem man erfahren hat wie viel die NSA ausspioniert (dass es rausgekommen ist finde ich gut :D ).
Dass man deshalb gerne ein solch "NSA-sicheres" Programm hätte, verstehe ich, deshalb werde ich ab jetzt weitere Sicherheitsmaßnahmen einbauen und das ganze "sicherer" machen, ggf. könntest du direkt helfen (wenn du Lust hast). Das werde ich als "neues" Projekt/ Exe anhängen, da es vom Thema abweicht. Ggf. werde ich einen neuen Thread eröffnen.
IhopeonlyReader - Sa 14.09.13 22:18
was sind für euch sichere Verschlüsselung, die eingebaut werden sollten? RSA, (Caesar, OneTimePad, Vigenere... )
BenBE - So 15.09.13 00:12
Für den Anfang sollten folgende reichen:
- Salsa20/12 mit Poly1305
- ECDH über GF(p), sei p >> 2^512
- Keccak als Stream-Cipher, gern auch mit 31*31 Planes, l=8, n=64 und r=1024
- Rjindael+Serpent+Twofish mit unabhängigen Keys
IhopeonlyReader - Mo 16.09.13 16:20
danke,
liege ich richtig in der Annahme, dass eingebaute Standard-Verschlüsselungen nichts bringen?
Also einen Schlüssel der IMMER mit drübergelegt wird...
Eventuell könnte man dadurch die Entropie erhöhen, wenn man das Programm allerdings besitzt würde es keine Sicherheit bringen, ist das richtig?
IhopeonlyReader - Mo 16.09.13 20:36
Salsa20/12 mit Poly1305 versteh ich leider nicht :(
ECDH über GF(p), sei p >> 2^512 das ist so wie ich das mitgekriegt habe werden a und b von verschiedenen Personen vorgegeben, wenn das ganze wie bei mir aber lokal ist, wird nur a oder b benötigt. wenn p>>2^512 dann muss ich uBigNum verwenden richtig?
Was soll ich mit der riesen Zahl bzw. dem 512 Bit-langem Schlüssel machen? xorn? Porgrammieren könnte ich es...
Keccak als Stream-Cipher, gern auch mit 31*31 Planes, l=8, n=64 und r=1024 mhhh.. sorry das ich nur bei Wikipedia schaue, aber dort ist es meiner Meinung nach blöd erklärt, und nach der Definition soll l zwischen (einschließlich) 0 und 6 liegen. Aber genau, verstehe ich das auch nicht, zumindest nicht so dass ich direkt lostippen könnte.
Rjindael+Serpent+Twofish mit unabhängigen Keys... was meinst du mit unabhänige keys? usereingabe, konstant, vom Programm erzeugt und abgespeichert?
Serpent kann implementiert werden, da es als Unit öffentlich zur Verfügung steht.
Tut mir leid, aber ich habe mich mit solchen "arten" noch nicht auseinandergesetzt. Vielleicht kann das jemand anderes mal mit eigenen Worten erklären? oder sind sie so komplex, dass sie eig. keiner "mal eben" tippen könnte und man immer fertige Units hernimmt?
richy-f - Mi 18.09.13 14:43
Die ganze Diskussion zeigt aufjedenfall, dass ein bißchen Lektüre nicht schaden würde, wie der ein oder andere schon angemerkt hat.
Ganz gut für den Einstieg war dieses Buch, hab ich mir zur Vorlesung gekauft :
http://www.amazon.de/Introduction-Modern-Cryptography-Principles-Protocols/dp/1584885513
Ansonsten gibt es auch viele Scripte zu Signal & Codierungstheorie sowie dann insbesondere zu PKK etc. online im Web zum Download
Einfach nur mit xor zu verschlüsseln mit einem festen Passwort lässt sich aufjedenfall wirklich einfach knacken, wie Ende Seite 1 schon jmd erklärt hat. Für die Passwortlänge gibts auch spezielle Tricks und Möglichkeiten diese rauszufinden. Danach braucht man nur ausreichend Chiffretext und dröselt es in Häufigkeitsanalysen für jede Bitposition auf.
Das ganze mit einer Stromchiffre zu machen ist eben wie schon angemerkt auch nur begrenzt sicher. Nutzt man eigentlich nur für Daten die man übermittelt und kurzzeitig sicher sein sollen. Aber nichts für ne langfristige Ablage als Datei für sensible Daten.
IhopeonlyReader - Mi 18.09.13 16:38
danke, aber mir fehlt die Motivation 500 Seiten in Englischer Fachsprache zu lesen.. lieber deutsche Einfachaltung, wie xor. Die Erklärung ist einfach und verständlich. Viele der "modernen" Crypt-Methoden sind nur deshalb sicher, weil man nicht direkt versteht wie was genau funktioniert.
Wenn man es dann verstanden hat, merkt man das es viele Ansätze gäbe, es zu knacken.
Meiner Meinung nach ist Xor mit einem vernünftigen "random" Schlüssel (der ca 1/10 der Datei groß ist) sicher genug !
Für Stick-Diebe etc. reicht es jedenfalls vollkommen aus. Ebenso für "ich schau mal eben nach" leute. Es dient dazu den "normalen" Bürger von den Dateien fernzuhalten.
Ihr glaubt gar nicht, was ich da schon VIEL SCHLIMMERES gesehen habe. Es gab eine Anwendung mit einem Symbol von einem Ordner. Öffnete man sie zum "ersten" mal, so gab man einen Ordnerpfad an. angeblich war dieser dann sicher :D
Wenn man auf die Anwendung klickte (anstatt Verknüpfung) öffnete sich ein Passwort Dialog. gab man das richtige Passwort ein, so wurde der Ordner geöffnet. Sonst nicht. Allerdings konnte man über den normalen Explorer ebenso ohne Probleme in den Ordner :D und ihr glaubt nicht, wie viel % der Mitbürger das für "sicher" halten würden (meine Schätzung liegt bei 70 bis 80 % )...
BenBE - Do 19.09.13 08:56
| IhopeonlyReader hat folgendes geschrieben : |
| danke, aber mir fehlt die Motivation 500 Seiten in Englischer Fachsprache zu lesen.. lieber deutsche Einfachaltung, wie xor. Die Erklärung ist einfach und verständlich. |
RSA passt auf ein T-Shirt., die wesentlichen Teile sind 2 Formeln und 2 Bedingungen.
Und wenn Du deutsche Fachliteratur lesen willst, nimm Security Engineering in der deutschen Übersetzung; wobei das Original deutlich mehr Spaß macht ;-)
| IhopeonlyReader hat folgendes geschrieben : |
| Viele der "modernen" Crypt-Methoden sind nur deshalb sicher, weil man nicht direkt versteht wie was genau funktioniert. |
Die sind sicher, weil genug Menschen unabhängig von einander gezeigt haben, dass sie sich daran die Zähne ausgebissen haben.
| IhopeonlyReader hat folgendes geschrieben : |
| Wenn man es dann verstanden hat, merkt man das es viele Ansätze gäbe, es zu knacken. |
Bitte unterscheide zwischen "cracked" und "broken". Kleiner, aber SEHR wichtiger Unterschied.
| IhopeonlyReader hat folgendes geschrieben : |
| Meiner Meinung nach ist Xor mit einem vernünftigen "random" Schlüssel (der ca 1/10 der Datei groß ist) sicher genug ! |
Snake Oil.
| IhopeonlyReader hat folgendes geschrieben : |
| Für Stick-Diebe etc. reicht es jedenfalls vollkommen aus. Ebenso für "ich schau mal eben nach" leute. Es dient dazu den "normalen" Bürger von den Dateien fernzuhalten. |
Die Stick-Diebe sind i.d.R. sehr gezielt hinter deinen Daten her und kennen sich da durchaus mit Krypto aus. Und für die anderen, nun ja: Deine Gefahrenanalyse weicht da ein wenig von der Realität ab.
| IhopeonlyReader hat folgendes geschrieben : |
Ihr glaubt gar nicht, was ich da schon VIEL SCHLIMMERES gesehen habe. Es gab eine Anwendung mit einem Symbol von einem Ordner. Öffnete man sie zum "ersten" mal, so gab man einen Ordnerpfad an. angeblich war dieser dann sicher :D
Wenn man auf die Anwendung klickte (anstatt Verknüpfung) öffnete sich ein Passwort Dialog. gab man das richtige Passwort ein, so wurde der Ordner geöffnet. Sonst nicht. Allerdings konnte man über den normalen Explorer ebenso ohne Probleme in den Ordner :D und ihr glaubt nicht, wie viel % der Mitbürger das für "sicher" halten würden (meine Schätzung liegt bei 70 bis 80 % )... |
Hausaufgabe bis nächste Woche: Bringe den Leuten bei, Snake Oil zu erkennen.
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2024 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!