PureBoard

Danke KeyKon für das Bild und so....

@AND51...

ich hab echt gedacht ich hab heut was geschafft und weiß ein wenig mehr...
aber egal was du da geschrieben hast..
das war mir zu hoch und mein kopf is jetzt ein Krater ^^

AND51 hat geschrieben:

KeyKon hat geschrieben:lass das proc doch evtl immer gleich 10 oder mehr 16kb päckchen einlesen, das wirkt sich positiv auf die festplattennutzung aus...

Ne, lass mal...
Halte dich lieber an den Befehl FileBufferSize(), denn nur der verwaltet den Buffer für Dateien. Damit kannst du den Buffer auch vergrößern, verkleinern oder ganz ausschalten.

Ein Ausschalten des Buffers dürfte aber auch interessant sein, weil:

Zwar verlängert sich vermutlich die Dauer einer Ver-/Entschlüsselungsoperation, jedoch wird die Originaldatei direkt mit dem Ergebnis überschrieben. Das heißt, es dürfte für Fremde schwieriger werden, an die originale Datei heranzukommen, z. B. mit Recoverytools oder sonstigem Kram. Durch das direkt Überschreiben der Datei geht evtl. auch der Restmagnetismus der alten Version der Datei auf der Stelle der Festplatte verloren, an denen die alte Version der Datei gelegen hat. Für mehr Infos sollte man sich einfach mal anschauen, wie Recoverytools und Shredder arbeiten.
Hoffe, ich hatte wenigstens halbwegs Recht.
Ich sagte, es wird schwieriger, nicht unmöglich. Ich garantiere hier keinen 100%igen Schutz und wollte auch keinen Flame auslösen.
Hoffe, das passte halbwegs zum Thema, was ich gesagt habe.

Meiner Meinung nach gibts für sowas besseres, ich würde die entsprechende Datei dann einach mit TuneUp oder so löschen und dabei halt so 10 fach überschreiben

Aber mal im ernst, wer so viel Sicherheit und Verschlüsselung will nimmt eh eine etwas aufwändigere Software^^

So nun noch ein paar Updates

Update 0.8 -> 0.9

- Geschätzte Dauer (noch im beta stadium)
- Eventmanagment ausgebessert
- Abbruch Button

Update 0.9 -> 0.95

- Doppelte Passwortabfrage beim Verschlüsseln
- kb/s Anzeige (noch im beta stadium)

Hmm, ich glaube dein Programm hat ne Schwachstelle:
Hinter die verschlüsselten Daten scheinen nochmal 16 Nullbytes gehangen zu werden, die ebenfalls mit dem Passwort verschlüsselt werden (vor dem MD5-Hash ganz am Ende der Datei). Damit könnte man ne Known-Text-Attacke durchführen, d.h. versuchen das Passwort zu entschlüsseln, indem man sich einen verschlüsselten Bereich anschaut, dessen Klartext man kennt (halt 16 Nullbytes in diesem Fall).

danke für den Tipp...
nachdem es ja egal ist welche zeichen am ende sitzen kann ich da per zufall das ganze sicherer machen...

aber der MD5 hash dürfte kein sicherheitsrikio mit sich führen oder?
weil damit überprüf ich ob die datei ordnungsgemäß entschlüsselt wurde...

edit1:

und es werden keine 16 nullbytes gesetzt sondern nur die restlichen zeichen die ja von 1 bis 15 reichen aufgefüllt werden ...

aber es ist natürlich ein sicherheitsrisiko

edit2:

den algo kann ich ja wenn wer will auch offen legen weil es ja heisst dass die veröffentlichung des algos nicht die sicherheit gefärden darf ^^

So nun noch ein paar Updates

Update 0.8 -> 0.9

- Geschätzte Dauer (noch im beta stadium)
- Eventmanagment ausgebessert
- Abbruch Button

Update 0.9 -> 0.95

- Doppelte Passwortabfrage beim Verschlüsseln
- kb/s Anzeige (noch im beta stadium)

Update 0.95 -> 0.96

- Nullbyte Fehler beseitigt

Update 0.96 -> 0.97

- Speicherort kann nun festgelergt werden

Jo R4z0r1989,

ist ja ganz nett geworden dein Programm

im Update ist leiner ein BUG, er meldet das das PW beim entschlüsseln falsch wäre.

Außerdem wäre es noch gut, wenn er nachfragen würde ob man eine schon existierende Datei wirklich überschreiben will.

danke werd morgen/heute nachschaun digga ^^

bis dann ^^

R4z0r1989 hat geschrieben:@AND51...

ich hab echt gedacht ich hab heut was geschafft und weiß ein wenig mehr...
aber egal was du da geschrieben hast..
das war mir zu hoch und mein kopf is jetzt ein Krater ^^

Noch mal in vereinfachter Kurzversion:

Eine aus dem Papierkorb gelöscht Datei ist, wie wir alle wissen, nicht wirklich gelöscht, sondern sie liegt immer noch auf der Festplatte. Der von der gelöschten Datei belegte Bereich auf der Festplatte ist aber zum Überschreiben freigegeben.

Solange der Bereich aber noch nicht von einer neuen Datei überschrieben wird, kann man diese wiederherstellen, das machen die bekannten Recoverytools.

Selbst wenn jedoch eine aus dem Papierkorb gelöschte Datei mit neuen Daten überschrieben wird, kann man wahrscheinlich die Datei wiederherstellen. Das liegt an der Art und Weise, wie Festplatten funktionieren und hat etwas mit (Rest-)Magnetismus zu tun. Das ist das, was du ja nicht verstanden hast.

Stell dir folgendes vor: ich schreibe einen text mit Bleistift und drücke dabei ganz doll den Bleistift auf. Du kannst den Text imemrnoch lesen, wenn ich ihn wegradiere (lösche) und sogar noch, wenn ich ihn neu überschreibe (wieder mit Bleistift, aber diesmal nicht so doll aufdrücken). Selbst dann kannst du den alten text noch lesen. Und genau dieses Problem umgehst du, wenn du FileBufferSize() auf 0 setzt.

Wenn du nämlich FileBufferSize() auf 0 setzt, wird die Buffertechnologie ausgeschaltet. Wie in der Hilfe steht werden dann alle Schreiboperationen direkt auf die Festplatte geschrieben. So wird deine Datei direkt überschrieben und Profis können unter Umständen nicht mehr die originale Datei wiederherstellen, weil der Restmagnetismus fehlt.


So, ist leider doch keine Kurzversion geworden, aber ich hoffe, ich konnte es dir verständlicher machen?

Ich glaub ich verstehs noch nicht ganz

aber ich kann ja nich direkt überschreiben weil ja die ersten 16 byte dann erst an 16 stelle geschrieben werden und anderrum die wieder an erster stelle geschrieben werden...

hmm aber vl erklärst du es mir ja noch ein wenig persönlicher in icq wenn du lust hast...