| Autor |
Beitrag |
BenBE
      
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Di 25.03.08 10:51
Die Reihenfolge ist alsch:
1. Programm starten
2. Passwort eingeben
3. Entschlüsseln
4. Prüfen, ob Entschlüsslung korrekt war
...
Ansonsten öffnest Du nämlich Tür und Tor für BruteForcing-Angriffe.
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
Spiritnight 
      
Beiträge: 17
|
Verfasst: Di 25.03.08 11:22
Du meinst also
Passwort eingeben und dann direckt mit dem pass entschlüsseln egal ob richtig oder falsch und dann erst prüfen ob es korrekt war ja ?
Ich danke Dir für den Tip aber ich verstehe Ihn nicht ganz,
Warum verhindere ich damit Bruttoforce:
- Wenn ich erst schaue ob das Passwort richtig ist, testet das BF programm einfach solange bis er hat.
- Wenn ich danach erst prüfe kann er das doch immernoch oder ?
Bitte meine Wiessenlücke füllen ^^
P.S.
Bevor Ihr mich für einen nervenden Ideoten haltet etwas zu mir:
Ich bin in der Ausbildung zum Fachinformatiker für Anwendungsentwicklung 1 Lehrjahr also seid 7 Monaten.
Ich habe bisher nur C/C++ in der Ausbildung gehabt daher steht mein Wissen auf wackligen Beinen.
C Sharp gehört nicht zu meiner Ausbildung und ich versuche es mir selbst beizubringen.
Und will damit sagen das dass was ich hier durch euch gelernt habe mir wirklich sehr geholfen hat und mich nochmal dafür bedanken.
Mfg Martin
|
|
Silas
      
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Di 25.03.08 18:14
Spiritnight hat folgendes geschrieben: | | Wenn ich danach erst prüfe kann er das doch immernoch oder ? |
Ja, aber wenn du zusätzlich zu deinem Programm z.B. 1 kB Daten einmal ver- und einmal entschlüsselt hinterlegst, und dann die entschlüsselten Daten mit dem Klartext vergleichst, weißt du, ob das Passwort richtig war. Dann wird Brute-Forcen so gut wie unmöglich, weil die benötigte Zeit zum bruteforcen ja mit 256^Dateigröße steigt.
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
|
|
BenBE
      
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Di 25.03.08 18:44
Silas hat folgendes geschrieben: | Spiritnight hat folgendes geschrieben: | | Wenn ich danach erst prüfe kann er das doch immernoch oder ? | Ja, aber wenn du zusätzlich zu deinem Programm z.B. 1 kB Daten einmal ver- und einmal entschlüsselt hinterlegst, |
BLOSS NICHT!!! Dann hast Du nämlich ne KnownPlaintext-Attacke drauf und das ganze ist unsicherer als vorher.
Silas hat folgendes geschrieben: | | und dann die entschlüsselten Daten mit dem Klartext vergleichst, weißt du, ob das Passwort richtig war. Dann wird Brute-Forcen so gut wie unmöglich, weil die benötigte Zeit zum bruteforcen ja mit 256^Dateigröße steigt. |
Nicht ganz:
Richtig ist erstmal: Man verhindert damit nicht das Brute-Forcen an sich, aber man macht das ganze so unattraktiv, dass es kein Ernsthafter Angreifer versucht. Ein Programm, wo das z.B. gut gelungen ist, ist WinRAR: Wer dort das Passwort nicht kennt, kan seinen Angriff schon abbrechen, da die schnellsten Rechner (im Heimbereich) bei so etwa 100 Passwörtern bruteforcen pro Sekunde liegen (zum Vergleich: LM-Hashes von Windows-Passwörtern ist man mit guter Hardware bei ~5Mio\s ...)
k, wie man's richtig macht:
Man nehme mit dem Passwort verschlüsselte Daten. Nun generiere man den Hash dieser (unverschlüsselten) Daten. Aus diesem Hash (der hoffentlich lang genug ist), schneidet man beliebige Zeichen raus und speichert die verbleibenden als Referenz.
Wenn jetzt der Hash der entschlüsselten Daten übereinstimmt, weiß man, dass mit hoher Wahrscheinlichkeit das Passwort richtig ist. Diese Rest-Wahrscheinlichkeit kann man mit geeigneten Maßnahmen so stark reduzieren, dass in keinem Fall die korrekte Funktionalität des Programmes gewährleistet ist; im Gegenteil kann man mit dem Validierungsschritt sogar so viele Kollisionen übrig lassen, dass ein Angreifer zwar Kollisionen erzeugen kann, diese aber durch so aufwendige Tests abgefangen werden, dass damit die Erzeugung von Kollisionen für's Bruteforcen beeinträchtigt wird (weil zusätzliche Rechenschritte für einen Angreifer nötig werden).
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
Silas
      
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Di 25.03.08 20:08
BenBE hat folgendes geschrieben: | Silas hat folgendes geschrieben: | Spiritnight hat folgendes geschrieben: | | Wenn ich danach erst prüfe kann er das doch immernoch oder ? | Ja, aber wenn du zusätzlich zu deinem Programm z.B. 1 kB Daten einmal ver- und einmal entschlüsselt hinterlegst, |
BLOSS NICHT!!! Dann hast Du nämlich ne KnownPlaintext-Attacke drauf und das ganze ist unsicherer als vorher. |
Spiritnight möchte sein Programm doch mit AES verschlüsseln. Und AES ist Known-Plaintext-sicher, sonst wäre es doch kein Standard, oder?
Ich dachte so etwas wäre sicherer als ein Hash, weil es gegen Rainbow Tables resistent ist.
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
|
|
BenBE
      
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Di 25.03.08 20:29
Normale Hashes sind auch gegen Rainbow-Tables resistent. Daher saltet man ja
@AES und Sicher gegen Known Plaintext: Warum etwas verschlüsseln, wenn man den Plaintext eh mitliefert? Gegen Dummheit schützt auch die beste Verschlüsslung nicht  Ferner hebelst Du mit dem Mitliefern des Plaintextes den gesamtn Schutz aus - ergo: Dumm gelaufen 
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
Silas
      
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Di 25.03.08 21:14
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
|
|
Spiritnight 
      
Beiträge: 17
|
Verfasst: Di 25.03.08 21:24
ich denke euer Missverständnis liegt an meiner Charaktervariablen ^^
Ich wollte es erst ohne machen dann mit.
Die idee mit dem vorprogramm ist mir gekommen weil ich leider keinen anderen Weg mehr gefunden habe um mein Queltext und den darin enthalten entschlüsselungsalgorythmus zu verstecken.
Ich habe in den letzten Tagen mehr übers aushebeln und knachen gelernt als mir lieb ist  .
Ihr habt mir viele schöne Anreize geliefert wie ich es doch noch hinbekomme und dafür danke ich euch sehr.
Daher ich nun wieder viele neue Ideen habe die ich erstmal umsetzen muss setze ich das Thema aus gelöst.
Vielen lieben Dank an alle beteiligten.
Mfg Martin
|
|
|