Suche gutes Porgramm zum löschen der Festplatte

Andyman

Vielleicht irre ich mich aber diese Programme sind alle für Windows ich benutze jedoch ein Linux-OS sind diese dann trotzdem voll funktionsfähig?

hustbaer

Die sind nicht alle für Windows. Das Active KillDisk z.B. tut booten, setzt vermutlich auf einer Mini-Linux Distro auf.

volkard

Unter Linux nimm einfach dd.
Es ist nicht bekannt, daß man 7-mal überschreiben müßte. Aber wenn Du vorsichtig sein willst, überschreibe zweimal mit Zufall und zum Abschluß nochmal miz nullen.

Jo, bin mir auch sicher, dass ich mal gelesen habe, dass das mit den 7x Schwachsinn ist. Einmal komplett überschreiben und das sollte echt reichen, außer für ein Hightech Labor vielleicht.

volkard

Ich schätze, falls es solche Labore schon gibt, daß es preiswerter ist, den ganzen Andyman zu kaufen, statt für seine Platten das Labor anzuwerfen.

Bei alte Festplatten (~10MB Kapazität) kann man herausfinden was dort vorher gestanden hat. Da macht 7 Überschreiben Sinn. Möglicherweise ist man in 30 Jahren soweit und kann das gleiche mit heutigen Tetrabyte Festplatten auch machen. Aber in 30 Jahren interessiert sich wohl niemand mehr für Deine DLs und Urlaubsfotos.

Mach einfach wie Volkard gesagt hat ein: dd if=/dev/zero of=/dev/xxxx
Wobei xxxx Dein HD ist

volkard

Ich schlug sogar zweimal
dd if=/dev/urandom of=/dev/xxxx
davor vor, um sein Gewissen total zu beruhigen.

Christoph

volkard schrieb:

Ich schlug sogar zweimal
dd if=/dev/urandom of=/dev/xxxx
davor vor, um sein Gewissen total zu beruhigen.

/dev/urandom ist leider unglaublich lahm auf einem normalen Linux-Kernel und nutzt auch nur einen einzigen CPU-Core. Dafür sind die Pseudo-Zufallsdaten aus /dev/urandom angeblich von sehr hoher Qualität.

Die Platte verschlüsseln und dann von /dev/zero auf die verschlüsselte Platte zu schreiben führt auch dazu, dass sehr gute Pseudo-Zufallsdaten auf der Platte landen, aber mit einem Vielfachen der Geschwindigkeit von /dev/urandom.

Mehr als einmal überschreiben halte ich aber immer noch für überflüssig. Das Thema kommt hier jedes Jahr einmal auf und bisher konnte niemand einen auch nur ansatzweise glaubwürdigen Beleg dafür liefern, dass einmal Überschreiben nicht ausreicht.

Statt manuell zu Überschreiben kann man der Platte aber auch den "ATA secure erase"-Befehl schicken. Dieser Befehl löscht die Platte nicht nur vermutlich schneller, sondern soll auch die Chance erhöhen, dass Ersatz-Sektoren auch überschrieben werden.

volkard

Christoph schrieb:

/dev/urandom ist leider unglaublich lahm auf einem normalen Linux-Kernel

echt?

~ $ dd if=/dev/zero of=/dev/zero count=100000
100000+0 records in
100000+0 records out
51200000 bytes (51 MB) copied, 0.133768 s, 383 MB/s

~ $ dd if=/dev/urandom of=/dev/zero count=100000
100000+0 records in
100000+0 records out
51200000 bytes (51 MB) copied, 15.804 s, 3.2 MB/s

Jup, "unglaublich lahm" trifft es genau.

SeppJ

Dann hast du dein System schon seit langem, laufen. urandom sollte echte Zufallszahlen aus dem Treiberrauschen erzeugen und ist entsprechend zu /dev/random oder /dev/zero wirklich lahm. Kann sogar blockieren und wartet dann bis die Maus (oder ähnlicher Entropiequellen) benutzt werden. Ist aber unter anderen Systemen als echtem "Linux" teilweise anders.

volkard

Umgekehrt. /dev/random sollte echte Zufall liefern. /dev/urandom sollte das schon wesentlich entspannter handhaben. Ich hätte nicht gedacht, daß urandom dennoch so unentspannt ist.

Christoph

volkard schrieb:

Jup, "unglaublich lahm" trifft es genau.

Ja, ich fand das auch schwer zu glauben und musste das mehrmals auf verschiedenen Systemen testen, bevor ich es akzeptiert habe.

Dass /dev/urandom unter Linux so lahm ist, war aber wohl schon immer so. Ich bin bei weitem kein Kryptografie-Experte, aber wenn ich Platten mit Zufallszahlen überschreiben möchte, mache ich normalerweise das, was ich im letzten Post angedeutet habe:
1. Platte mit verschlüsselt mounten mit aus /dev/random generierten Schlüssel.
2. /dev/zero auf die verschlüsselte Platte kopieren.
3. Unmounten, d.h. der Schlüssel ist weg.

Das normale Festplatten-Verschlüsselungssystem von Linux (dmcrypt) hat zur Zeit keine in diesem Kontext relevanten Sicherheitslücken, von denen ich wüsste. Das heißt nach Schritt 3 ist für einen Angreifer mangels Schlüssel nicht feststellbar, mit was die verschlüsselte Platte überschrieben wurde. Insbesondere ist nicht unterscheidbar, ob die verschlüsselte Platte mit /dev/zero oder ob die unverschlüsselte Platte mit Zufallsdaten überschrieben wurde. Wär das unterscheidbar, wär das nämlich eine gravierende Lücke in dmcrypt und würde Aufsehen erregen.

Deswegen denke ich, dass das den Zweck von "mit Zufallsdaten überschreiben" erfüllt.

Das ist aber vor allem dann nützlich, wenn man die Platte später verschlüsselt benutzen möchte. Denn wenn man die Platte dann vorher nicht mit Zufallsdaten komplett überschreibt, kann ein Angreifer ungefähr sehen, wieviel Daten man schon auf die Platte geschrieben hat, ohne dass er den Schlüssel besitzt. Fast alle nicht angefassten Sektoren enthalten bei einer fabrik-neuen Platte nämlich nur 0en.

Ich schreib das hier nochmal, weil ich erschreckend finde, auf wievielen Blogs und Anleitungen für verschlüsselte Partitionen man den Ratschlag findet "überschreib die Platte vorher mit /dev/urandom". Wenn man merkt, dass das je nach CPU knapp eine Woche dauert, brechen das bestimmt viele ab und lassen das Überschreiben mit Zufallsdaten weg, auf Kosten der Sicherheit.

(Das beste war ein Blog, wo jemand allen ernstes dokumentiert hat, wie man /dev/urandom von verschiedenen anderen PCs per netcat auf den Ziel-PC leiten kann und das dann mit mehreren parallelen dd-Jobs auf die Platte schreibt, damit das in vernünftiger Zeit fertig wird, weil jedes /dev/urandom einzeln halt nur 5-10MB/s liefert. "If all you have is a hammer, everything looks like a nail.")

volkard

Christoph schrieb:

normalerweise das, was ich im letzten Post angedeutet habe:
1. Platte mit verschlüsselt mounten mit aus /dev/random generierten Schlüssel.
2. /dev/zero auf die verschlüsselte Platte kopieren.
3. Unmounten, d.h. der Schlüssel ist weg.

Wobei es vielleicht auch angemessen sein könnte, /dev/zero über aescrypt zu leiten und auf die Platte zu schreiben. Gegebenenfalls mit einem kilobyte Zufall am Anfang und einem zufälligen Schlüssel aus /dev/random.

Christoph

volkard schrieb:

Christoph schrieb:

normalerweise das, was ich im letzten Post angedeutet habe:
1. Platte mit verschlüsselt mounten mit aus /dev/random generierten Schlüssel.
2. /dev/zero auf die verschlüsselte Platte kopieren.
3. Unmounten, d.h. der Schlüssel ist weg.

Wobei es vielleicht auch angemessen sein könnte, /dev/zero über aescrypt zu leiten und auf die Platte zu schreiben. Gegebenenfalls mit einem kilobyte Zufall am Anfang und einem zufälligen Schlüssel aus /dev/random.

Was genau meinst du mit aescrypt?

Bei Schritt 1 dachte ich an das Programm cryptsetup, nicht loop-aes oder so. Denn die älteren Programme haben Lücken in ihren AES-Implementierungen, oder zumindest mögliche Schwachstellen. Wie eigentlich fast immer bei AES-Schwachstellen geht es dabei um die Initialisierungsvektoren, die bei früheren Implementierungen vorhersagbar waren, weil einfach die Sektor-Nummer als IV genommen wurde. Das hat sich als nicht so sicher herausgestellt. Deswegen ist seit einigen Linux-Versionen ein "aes-essiv"-Cipher der default, und nicht mehr nur "aes" oder "aes-plain".

edit: /dev/zero über ein Programm, das behauptet AES zu machen, direkt auf die Platte schreiben, halte ich für unsicherer, eben weil ich kein Kryptografie-Experte bin und nicht weiß, was da alles schiefgehen kann. Ich weiß, dass bei Kryptografie die unerwartetesten Dinge zu einer Sicherheitslücke werden können. Bei dmcrypt hab ich mehr Vertrauen, dass die Implementierer wissen was sie tun.

volkard

Christoph schrieb:

genau meinst du mit aescrypt?

Irgendein Programm, das Streams mit aes verschlüsselt. Hatte gerade nur das da http://www.aescrypt.com/linux_aes_crypt.html gefunden.

Natürlich unpraktisch, wenn nur eine CPU heizt und die AES-Hardware nicht angesprochen wird. Ich müßte mal messen, wenn ich wieder in linux boote.

Christoph

volkard schrieb:

Christoph schrieb:

genau meinst du mit aescrypt?

Irgendein Programm, das Streams mit aes verschlüsselt. Hatte gerade nur das da http://www.aescrypt.com/linux_aes_crypt.html gefunden.

Ah, OK. Das hatte ich am Ende meines letzten Postings vermutet und mit einem edit noch hinzugefügt.

volkard schrieb:

Natürlich unpraktisch, wenn nur eine CPU heizt und die AES-Hardware nicht angesprochen wird. Ich müßte mal messen, wenn ich wieder in linux boote.

Das auch ein Punkt, der für dmcrypt spricht.

volkard

Christoph schrieb:

edit: /dev/zero über ein Programm, das behauptet AES zu machen, direkt auf die Platte schreiben, halte ich für unsicherer, eben weil ich kein Kryptografie-Experte bin und nicht weiß, was da alles schiefgehen kann. Ich weiß, dass bei Kryptografie die unerwartetesten Dinge zu einer Sicherheitslücke werden können. Bei dmcrypt hab ich mehr Vertrauen, dass die Implementierer wissen was sie tun.

Eine Idee, was bei zufälligem Vorlauf und zufälligem Schlüssel schiefgehen könnte?
Hier hätte ich keine Angst.

Christoph

volkard schrieb:

Eine Idee, was bei zufälligem Vorlauf und zufälligem Schlüssel schiefgehen könnte?

AES ist nicht AES, das ist der entscheidende Punkt hier, denk ich. "AES" ist nur die halbe Sache. Was dazugehört ist, in welchem Modus AES eingesetzt wird und wie aus dem Passwort die Initialisierung der AES-Routine gemacht wird. Bei beidem kann man viel falsch machen, aber ich trau mir bei meinem momentan Kenntnisstand nicht zu zu beurteilen, ob eine gegebene Implementierung dabei einen subtilen Fehler macht oder nicht.

Letztendlich bleibt mir als Kryptografie-Laie nur die Möglichkeit, die Vertrauenswürdigkeit von Implementierungen durch äußere Merkmale abzuschätzen. Deswegen halte ich die FreeBSD-Implementierung (geli) sogar für noch einen Tick vertrauenswürdiger als die Linux-Implementierung (dmcrypt). Aber auch zu dmcrypt, unter anderem weil es schon so lange im Mainline-Kernel ist, hab ich viel mehr Vertrauen als zu anderen Programmen, an denen am Ende nur eine einzige Person gearbeitet hat.

volkard

AES ohne Hardwareunterstützung macht bei mir 50MB/s, halb so schnell wie die Platte, wenn ich mich recht erinnere.
Was ich eigentlich brauche, ist ein kryptofester Pseudozufallszahlengenerator. Sowas wird sich finden lassen.

EXDW

Idee von mir, statt die Platte mit Zufallszahlen komplett überschreiben zu lassen, lasst einfach Wikipedia Seiten so lange auf platte abspeichern bis sie voll ist, und danach eine Formatierung. Wenn dann jemand Wiki Seiten wiederherstellt ist das irrelevant

Also kurz gesagt, die Platte einfach mit irrelevanten Daten voll schreiben lassen vor der Formatierung