staging.inyokaproject.org

auftisch schrieb:

Vorher muss das entsprechende Gerät mit umount /dev/sda9 entbunden werden, sonst funktioniert's nicht.

Genau das gleiche Problem hatte ich auch. Schade eigentlich, dass man für diesen Hinweis erst noch zwei Seiten dieser Diskussion durchlesen muss. Habe es einfach mal eingefügt.

Ich mache das normalerweise auch so (also Device verschlüsseln und dann verschlüsselten Container mit /dev/zero überschreiben).

Auf einem langsameren System (einem NAS) mit mehreren TB RAID hat mir das dann doch zu lange gedauert, so daß ich mich auf die Suche nach einer schnelleren Alternative gemacht habe. Da bin ich dann bei Python / Numpy hängen geblieben. Das gibts in jeder Distri, nur nicht in jedem Livesystem, muss halt ggf. installiert werden. Numpy/Random ist in C implementiert und daher recht schnell.

python -u -c $'import sys,numpy\nwhile True: sys.stdout.write(numpy.random.bytes(1000000))' | dd of=/dev/sdx bs=1M

Das macht die Verschlüsselung nachher nicht schneller, aber für Video vom NAS gucken reichen mir 30MB/s, aber 2 Tage aufs Überschreiben mit Pseudozufall warten wenns auch mit 100MB/s geht muss ja nicht sein... 😉

Hi frostschutz,

auch wenn die Rückmeldung wohl reichlich spät kommt, kannst du das als zweiten Absatz ins Wiki aufnehmen (genauso mit dem Kommentar wegen Performance und evtl. Nachinstallieren)?

Gruss Lasall

Ich würde den Artikel eher löschen / in den Daten sicher löschen Artikel integrieren, da steht im Moment ja gar nichts drin.

Und wenn dann nicht mit meiner Python Lösung (viel zu kompliziert) sondern mit 'shred -n 1 /dev/sdx'. shred verwendet auch einen Pseudo-Zufallszahlengenerator der entsprechend schnell sein sollte. Eine 1GB Datei in /dev/shm/ (RAM) überschreibt shred bei mir in 0.7 Sekunden. Das reicht für Festplatten und SSDs, Datendurchsatz auf meinem Netbook und NAS muss ich noch testen... in jedem Fall ist es schneller als Nullen zu verschlüsseln.

Vielleicht habe ich am Wochenende Zeit einen neuen Artikel zu schreiben, wie macht man das am dümmsten, alles in der Baustelle?

Als Vorbild für einen neuen Artikel würde ich http://en.gentoo-wiki.com/wiki/Secure_deletion nehmen (der Artikel ist auch von mir, muss aber auch mal überarbeitet werden).

Hi frostschutz,

du schriebst:

[...]

Vielleicht habe ich am Wochenende Zeit einen neuen Artikel zu schreiben, wie macht man das am dümmsten, alles in der Baustelle?

Der Artikel Daten sicher löschen ist ja eine Übersichtsseite, deswegen sollte da wenn möglich auf konkrete Ansätze verzichtet werden. Es existiert ja schon der Artikel Shell/shred. Meinst du, dass es sich anbietet, Änderungen dort einzufügen und dass der Ansatz in diesem Artikel hier obsolet ist? Oder soll der Übersichtsseitenstatus von "Daten sicher löschen" entfernt werden und du passt dort alles an? Sage mir bitte Bescheid, wie du vorgehen möchtest und welche(n) Artikel du in die Baustelle möchtest.

Als Vorbild für einen neuen Artikel würde ich http://en.gentoo-wiki.com/wiki/Secure_deletion nehmen (der Artikel ist auch von mir, muss aber auch mal überarbeitet werden).

Klasse 👍 !

Gruss Lasall

Ich würde dann alles auf der Daten sicher löschen Seite machen, wenn das keine Übersichtsseite bleiben soll. Wenn ich das machen soll, versuche ich das übers Wochenende hinzubekommen.

In dem shred Artikel steht auch daß das Generieren von Zufallszahlen länger dauert, das ist zwar einerseits richtig (PRNG braucht sicher etwas mehr CPU als einfach nur Nullen zu schreiben), andererseits impliziert es aber daß es langsamer ist als die Festplatte selber und das stimmt (zumindest auf meinem Hauptsystem mit einer Intel E8400) nicht. Hat shred vielleicht früher mal ausschließlich /dev/urandom benutzt oder woher kommt das. Ich teste das nachher mal auf meinem Ubuntu Netbook... performanztechnisch dürfte so ein Intel Atom heute wohl am unteren Ende liegen, wenn es dort schneller als die eingebaute SSD ist dürfte es wohl für alle Systeme passen

Hi frostschutz,

die Baustelle/Daten sicher löschen steht und bitte nimm dir soviel Zeit wie du brauchst ☺ . Falls das im shred-Artikel inkorrekt ist, einfach anpassen.

Gruss Lasall