http://www.heise.de/newsticker/Sicheres-Loeschen-Einmal-ueberschreiben-genuegt--/meldung/121855
>Wenn es um ein einziges Bit geht, von dem man ganz genau weiß, wo es steht, >dann
kann man es (in einem der genannten Beispiele) mit 56 Prozent >Wahrscheinlichkeit
korrekt rekonstruieren.
Mist ich schaff das immer nur mit einer 50% Wahrscheinlichkeit ...
Na, der Heise-Artikel klingt ja so, als ob sie es schon lange gewusst hätten. Aber genau das Gegenteil ist der Fall: Diverse Heise-Redakteure haben diese Mär selbst gebetmühlenartig in diversen Artikeln wiederholt.
Herrlich: "In einer wissenschaftlichen Untersuchung hat er" "und wer weiß wohin gespeichert worden"
> Aber genau das Gegenteil ist der Fall: Diverse Heise-Redakteure > haben diese Mär selbst gebetmühlenartig in diversen Artikeln wiederholt. Und andere haben die Mär schon lange als solche dargestellt.
Also ich überschreibe die Daten immer 10.000 mal. Dann verbrenne ich den kompletten Computer, zusammen mit der Tastatur, Bildschirm und Maus. Das ganze löse ich dann in Säure auf und verwahre das in einem hochfesten Panzertresor innerhalb einer unterirdischen Militärbasis, die ständig bewacht wird. Und dann lösche ich noch die index.html auf dem Webserver, wo die Sicherungskopie davon liegt, dann wirds bestimmt niemand mehr finden.
>Und dann lösche ich noch die index.html auf dem Webserver, wo die >Sicherungskopie davon liegt, dann wirds bestimmt niemand mehr finden. Es reicht, die in _index.htm? umzubenennen....
" Also ich überschreibe die Daten immer 10.000 mal. Dann verbrenne ich den kompletten Computer, zusammen mit der Tastatur, Bildschirm und Maus. Das ganze löse ich dann in Säure auf und verwahre das in einem hochfesten Panzertresor innerhalb einer unterirdischen Militärbasis, die ständig bewacht wird. Und dann lösche ich noch die index.html auf dem Webserver, wo die Sicherungskopie davon liegt, dann wirds bestimmt niemand mehr finden. " reicht leider nicht. Das von der Sonne kommende Licht, das du reflektiert hast als du deine Daten eingegeben hat, musst du ebenfalls noch löschen. Sonst könnten dich Ausserirdische mit ihren SuperDuperTeleskopen in par Lichtjahren beobachten.
Das ist doch vollkommen klar. Zumindest jedem, der die zugrunde liegende Technik verstanden hat. Und die Wahrscheinlichkeit von 0.5 (die man ohnehin hat, wenn man per Zufall entscheidet) auf 0.56 zu erhoehen... tolle Studie. Absolut laecherlich :D Und "sicheres Loeschen" ist kein Quark. Quark ist mein Rechner... hehe. Well Spass bei Seite: Unter "sicherem Loeschen" versteht man, dass die zu loeschenden Daten ueberschrieben werden, was bei normalen Loeschaktionen nicht erfolgt, da es natuerlich erheblich laenger dauert und I/O-Leistung im System erzeugt.
Naja, so neu ist das nicht. Das hab ich schon gelesen als ich meinen Lappi vertickt habe. Seitdem überwschreibe ich immer mit 0, das geht am schnellsten.
Moin, Meine (ernst gemeinte) Frage: Ich habe eine Datei blub.xzy im Dateisystem meines Rechners. Wie lösche ich die sicher - d.h. so dass kein CIA-JamesBond der Welt Inhalte daraus rekonstruieren kann? Bedenkt bitte auch (wie im Artikel beschrieben) dass diese Date ja zig-Mal hin-und-her kopiert worden ist und dass diese Datei z.B. im Office-REDO-irgendwas-Buffer meiner Office-Version 4711 steht... Ich möchte allerdings nicht meine komplette Platte löschen sondern will morgen auch nocch mit meinem Rechner arbeiten können ??? Meine These: Das geht nicht ! Es lässt sich immer was finden ! Gruß Andreas
Timbo wrote: > Naja, so neu ist das nicht. Das hab ich schon gelesen als ich meinen > Lappi vertickt habe. Seitdem überwschreibe ich immer mit 0, das geht am > schnellsten. Oh Mist, und ich Idiot überschreibe immer alles mit 1 und muß ewig warten! Hätte ich mir ja auch selber denken können! :-)
>Oh Mist, und ich Idiot überschreibe immer alles mit 1 und muß ewig >warten! Hätte ich mir ja auch selber denken können! :-) Überschreib's doch einfach mit '2', das geht doppelt so schnell! :)
Thilo M. wrote: >>Oh Mist, und ich Idiot überschreibe immer alles mit 1 und muß ewig >>warten! Hätte ich mir ja auch selber denken können! :-) > > Überschreib's doch einfach mit '2', das geht doppelt so schnell! :) Da denkst Du aber falsch mein Freund! Habs eben probiert, mit "2" gehts doppelt so langsam. Mein Bruder behauptet zwar es war halb so schnell´, aber der hatte ja noch nie recht! :-) OK, jetzt muß ich nur schauen wie ich unter den vielen 2ern meine Daten wieder zurückbekomm... ;-)
gast wrote: > Ich möchte allerdings nicht meine komplette Platte löschen sondern will > morgen auch nocch mit meinem Rechner arbeiten können ??? Indem du die ganze Platte verschlüsselst, z.B. mit Truecrypt. > Meine These: Das geht nicht ! Es lässt sich immer was finden ! Finden läßt sich schon was, aber nur wenn man den Schlüssel kennt...
>Indem du die ganze Platte verschlüsselst, z.B. mit Truecrypt.
Das geht ja noch langsamer und kompatibel ist das nun auch nicht gerade.
ist doch egal wie oft du es löscht. einen sicherheitskopie von deinen daten hat doch der Hr. Schäuble!
Platsch wrote: >>Indem du die ganze Platte verschlüsselst, z.B. mit Truecrypt. > Das geht ja noch langsamer und kompatibel ist das nun auch nicht gerade. Kompatibel zu was? Im Übrigen kostet Sicherheit halt ihren Preis... Allerdings ist der nur mäßig hoch: Ich habe eine virtuelle Linux-Maschine mit voll verschlüsselter Platte, die fällt nicht durch besondere Langsamkeit auf.
Soviel Aufwand ..... Ich beame meine Platte einfach in die nächste Sonne und repliziere mir dann ne Neue.
>Kompatibel zu was? Zur restlichen Software. Die Verschlüsselung deckt ja nur die Zugriffe über den Kernel-Treiber. Programmen steht es aber frei, Zugriffe auf die Festplatte darüber oder eigenständig abzuwickeln (also über eigene dynamisch bindbare Treiber). Dann ist deine Verschlüsselung: 1. vor'n Arsch 2. absturzgefährdet weil möglicherweise eine Inkompatibiltät zwischen den Zugriffsmodulen besteht Das kannst du auch bei Truecrypt in den Bugfixes (natürlich zarter formuliert) nachlesen. (Die Mühe macht sich aber offensichtlich keiner.) Du hast also bei proprietärer Software keine Gewährleistung das es funktioniert sowohl hinsichtlich Sicherheit wie auch Kompatibilität, denn du kannst nicht sehen, wie die Programme die Zugriffe starten. So hat die Tatsache das Truecrypt Open-Source ist, weniger mit freier Lesbarkeit, als vielmehr mit der Abwendung von Regressansprüchen zu tun. (Es heisst ja auch nicht umsonst "letzte stabile lauffähige Version" und das sollte doch zu denken geben..) >Im Übrigen kostet Sicherheit halt ihren Preis... Du sagst es. Geiz ist geil ist hier wirklich fehl am Platz..
Platsch wrote: >>Kompatibel zu was? > > Zur restlichen Software. Die Verschlüsselung deckt ja nur die Zugriffe > über den Kernel-Treiber. Ja wie denn sonst? > Programmen steht es aber frei, Zugriffe auf die > Festplatte darüber oder eigenständig abzuwickeln (also über eigene > dynamisch bindbare Treiber). Dann ist deine Verschlüsselung: > 1. vor'n Arsch > 2. absturzgefährdet weil möglicherweise eine Inkompatibiltät zwischen > den Zugriffsmodulen besteht Das hat weniger mit der Verschlüsselung zu tun, als mit Kompromittierung des Systems. Eine Alternative wären selbstverschlüsselnde Laufwerke - die scheint es bisher überwiegend in einer Form zu geben, die jeder 2. Semester Informatik knacken kann. Aber wenn man sowas ordentlich macht, dürfte das Problem gelöst sein...
> Programmen steht es aber frei, Zugriffe auf die > Festplatte darüber oder eigenständig abzuwickeln (also über eigene > dynamisch bindbare Treiber). Nein, unter einem Betriebssystem steht das Programmen eben nicht frei.
Das ist wohl eine Frage von Zugriffsprivilegien. Wenn es einer schafft, sich die System-Privilegien von Windows zu verschaffen, dann wird er wohl können. Aber das ist ein Problem der Systemkompromittierung...
Hat sich jemand mal das paper angeguckt? Ich habs grade nur überflogen, aber ich glaube mal eher, die zusammenfassung von heise ist etwas bescheiden... und wieso kann ich nicht eine wahrscheinlichkeit von über 50% haben? Klar ich habe eine von 50%, wenn ich vorher nichts über den Zustand weiss, aber hier geht es doch darum, dass die messung zu 56% richtig liegt
50% ist reiner Zufall. Wenn man ein Bit mit 56%-tiger Wahrscheinlichkeit richtig lesen kann, ist man etwas besser, als der Zufall.
Oder mal anders ausgedrückt, ein Zehntel der Information bleibt nach dem Überschreiben übrig. Um festzustellen ob sich eine bekannte Datei auf der Festplatte befindet sollte das zum Beispiel reichen - vorausgesetzt, man würde die komplette Festplatte erst mal auf diese Weise auslesen.
Das eröffnet ja ganz neue Perspektiven der Datenkompression ;-)
Ups, da hab ich in meinem vorigen Beitrag eine Null unterschlagen. Bei 44% Fehlerrate ist die Kanalkapazität 0.01 Bit/Symbol, d.h. 1% der Information bleibt übrig. Nichtsdestotrotz würden sich damit bekannte Dateien aufspüren lassen. Dass das Auslesen der kompletten Festplatte auf diese Weise ein immenser Aufwand ist steht natürlich auf einem anderen Blatt (wie viel genau steht leider nicht im Heise-Artikel, und das Original kostet).
Man könnte ja Zypries/von der Leyen den Tipp geben, von der Computerindustrie zu verlangen, daß Bits auf Festplatten, die Kinderp*rnos codieren, mit einem besonderen Tag zu versehen sind, damit sie auch nach einmaligem Überschreiben der Platte noch sicher erkannt werden können.
@uhu >Ja wie denn sonst? >Das hat weniger mit der Verschlüsselung zu tun, als mit Kompromittierung >des Systems. Du hast wirklich eine sehr subtile Art immer Recht behalten zu wollen. Ob du wirklich verstanden hast um was geht? Kaum. >Das ist wohl eine Frage von Zugriffsprivilegien. Wenn es einer schafft, >sich die System-Privilegien von Windows zu verschaffen, dann wird er >wohl können. Das kommt davon, wenn man es höchsten bis zum Anwendungsprogrammierer geschafft hat. @ Rufus >Nein, unter einem Betriebssystem steht das Programmen eben nicht frei. Was für eine qualifizierte Aussage. Wir reden hier von Windows und nicht von einem Unix ähnlichen Betriebssystem. So schnell kannst du gar nicht gucken wie du unter Windows Zugriff auf den Iopl-Ring erhältst. Die meisten Programme lassen sich ohnehin nicht mit Gast-Zugriff ausführen.
Das ist Unsinn. Auch bei Windows muss jedes Programm den "Umweg" über das Dateisystem gehen, sonst ist sowieso alles kaputt. Und TrueCrypt/PGPDisk/... arbeiten unterhalb der Dateisystemebene.
Würde vermuten das es ansonsten eh nur um Kopierschutz geht.
>Das ist Unsinn. Auch bei Windows muss jedes Programm den "Umweg" über >das Dateisystem gehen, sonst ist sowieso alles kaputt. Und >TrueCrypt/PGPDisk/... arbeiten unterhalb der Dateisystemebene. Mach dir doch mal die Mühe die Problem-Liste von Truecrypt durchzuarbeiten. Da steht doch drin das einige Programme nicht funktionieren. Dazu zählen z.B. das Partitionsprogramm von Win2k, Kopierschutzsysteme wie z.b. FlexM (z.B. in Modelsim) sowie einige Defragmentiertools (es gibt auch Programme die eigenständig ihr Dateisystem im Hintergrund optimieren). Uner Windows kann jedes Programm das nicht mit Gast-Rechten läuft dynamisch am Kernel vorbei die Hardware programmieren und das gewährleistet weder Sicherheit noch Kompatibilität. Unter Linux ist das anders. Hier wird jedes Porgramm gezwungen über die Kernelfunktionen auf die Hardware zuzugreifen. Braucht man eine neue Schnittstelle, so muss sie erst in den Kernel compiliert werden und dies ist bei Windows natürlich nicht möglich. Bietet der Windowskernel nicht die entsprechene Funktion, wie z.b. Zugriffe auf Sektorebene anstatt Cluster, so kann jedes Programm dieses Funktion eigenständig am Kernel (bzw. Standardtreiber) herum ausführen und seine Daten manipulieren.
> Uner Windows kann jedes Programm das nicht mit Gast-Rechten läuft > dynamisch am Kernel vorbei die Hardware programmieren ... Ach?
@Platsch: Defragmentierung läuft unter Windows nur über eine OS-Schnittstelle. Aber ich bin gespannt auf deine Applikation, die einen Treiber lädt und einen Sektor auf die Platte schreibt...
@Uhu >Defragmentierung läuft unter Windows nur über eine OS-Schnittstelle. ... >Aber ich bin gespannt auf deine Applikation, die einen Treiber lädt und >einen Sektor auf die Platte schreibt... Es gibt Programme die Speicherplatz über das Filesystem defragmentiert reservieren um dann linear sehr schnelle Zugriffe am Kernel vorbei auszuführen (z.B für Auslagerungen). Das funtkioniert mit jedem Filesystem. Reicht das für dich? Individuelle Probleme erfordern individuelle Lösungen und was technisch möglich ist, wird auch gemacht. Deine Frage ist einfach falsch formuliert.
@Platsch: Du verbreitest hier absoluten Quark. >Es gibt Programme die Speicherplatz über das Filesystem defragmentiert >reservieren um dann linear sehr schnelle Zugriffe am Kernel vorbei >auszuführen (z.B für Auslagerungen). Quatsch mit Soße. Nenn doch mal so ein Programm, dass nicht über die Windows-Schnittstellen auf die Sektoren zugreift. Die überwiegende Mehrzahl der Programme greift sowieso Dateiweise auf die Festplatte zu.
>Quatsch mit Soße. Schön das du dich auskennst. >Nenn doch mal so ein Programm, dass nicht über die Windows-Schnittstellen >auf die Sektoren zugreift. Das ist nicht so einach möglich da der Code bei Winodws nicht quelloffen ist. Videosoftware mit hohem Durchsatz kommt um diese Methode aber nicht herum. >Die überwiegende Mehrzahl der Programme greift sowieso Dateiweise auf >die Festplatte zu. Du sagst es und ein Teil tut es eben nicht (oder nur teilweise ohne das du davon etwas merkst.) Du bist nicht der erste der ein Problem damit hat, die Hosen herunterlassen zu müssen und sich dagegen versucht mit Händen und Füssen zu wehren. Ein Filesystem bringt aufgrund seiner Natur nur ein Bruchteil der Durchsatzleistung einer Festplatte. Das kannst du gerne selbst austesten. Mehr als 20 Mbyte pro Sekunde, wirst du auch bei grossen Dateitransfers nicht schaffen. Eine Festplatte schafft aber dauerhaft zwischen 80-120. Man muss sie physisch nur richtig ansprechen, so, wie man es über den Windowskernel eben (aus vielschichtigen Gründen die ich hier nicht näher erläutern möchte) nicht kann.
Platsch wrote: > Das kannst du gerne selbst > austesten. Mehr als 20 Mbyte pro Sekunde, wirst du auch bei grossen > Dateitransfers nicht schaffen. Eine Festplatte schafft aber dauerhaft > zwischen 80-120. Man muss sie physisch nur richtig ansprechen, so, wie > man es über den Windowskernel eben (aus vielschichtigen Gründen die ich > hier nicht näher erläutern möchte) nicht kann. Was ist das für ein Schwachsinn? Hab das hier mal kurz getestet (ältere Samsung SpinPoint) Kopieren des Win7Beta-ISOs (3357288448 Bytes) 53 MByte/s, was in etwa der mittleren Leserate laut h2benchw entspricht (und auch zur Lage der Partitionen passt).
1 | // mal nur das wesentliche
|
2 | FileStream inStream; |
3 | FileStream outStream; |
4 | byte[] buffer = new byte[1 << 26]; |
5 | int rLength; |
6 | |
7 | inStream = File.OpenRead(args[0]); |
8 | |
9 | outStream = File.Create(args[1], 1 << 26, FileOptions.SequentialScan); |
10 | |
11 | while (true) { |
12 | rLength = inStream.Read(buffer, 0, 1 << 26); |
13 | if (rLength <= 0) break; |
14 | outStream.Write(buffer, 0, rLength); |
15 | }
|
16 | |
17 | inStream.Close(); |
18 | outStream.Close(); |
> Das kannst du gerne selbst > austesten. Mehr als 20 Mbyte pro Sekunde, wirst du auch bei grossen > Dateitransfers nicht schaffen. Eine Festplatte schafft aber dauerhaft > zwischen 80-120. Man muss sie physisch nur richtig ansprechen, so, wie > man es über den Windowskernel eben (aus vielschichtigen Gründen die ich > hier nicht näher erläutern möchte) nicht kann. Da spricht jemand, der sich mit Windows auskennt. Einen ziemlich hohen Datendurchsatz erreichen unter Windows die Funktionen, die vom Kernel zum Ein- und Auslagern von virtuellem Speicher im Rahmen des Paging verwendet werden. Diese verwenden selbstverständlich auch die geladenen Treiber und greifen nicht unter deren Umgehung auf Festplatten zu -- wäre bei der Vielzahl verwendbarer Festplattencontroller auch annähernd unmöglich umzusetzen. Diese Funktionen zum Ein- und Auslagern von virtuellem Speicher können aber auch von normalen Programmen verwendet werden - und erreichen auch dort ganz erheblichen Durchsatz. Das geschieht über einen Mechanismus namens memory mapped files, mit dem Dateien über den virt. Speichermanager in den Arbeitsspeicher gemappt werden. Das ist übrigens auch eine recht elegante Methode, große Dateien zu lesen, ohne sie zu lesen; man kann aus C heraus direkt mit normalen Pointeroperationen auf den Dateiinhalt zugreifen. Zuständige Funktionen in der Win32-API: http://msdn.microsoft.com/en-us/library/aa366537(VS.85).aspx http://msdn.microsoft.com/en-us/library/aa366761(VS.85).aspx Ja, genau diese Funktionen werden auch für shared memory zwischen unterschiedlichen Prozessen verwendet. Windows ist, allen Unkenrufen zum Trotz, nicht nur Mist.
Ob man auf eine Datei memory-mapped oder per stream zugreifet, macht für Bulk-Operation praktisch keinen Performance-Unterschied. Zwar werden beim Stream-Zugriff die Daten öfters im RAM zwischen Kernel- und Userspace hin und her kopiert, aber RAM ist vergleichsweise schnell zu Festplatten-IO. Mapping ist in erster Linie ein anderes (in vielen Fällen besseres) Programmiermodel für Dateien, speziell dann, wenn viele Prozesse (koordiniert und shared) auf die gleiche Datei zugreifen, z.B. mehrere Datenbankprozesse.
Für wirklich Paranoide nicht zu empfehlendes Paper von Ken Thompson http://cm.bell-labs.com/who/ken/trust.html oder http://csrc.nist.gov/publications/history/karg74.pdf
Also eins muss man euch lassen Leute, hartnäckig seit ihr! Von dynamischen Treibermodellen unter Windows und seinen Vorzügen hat noch keiner von euch gehört geschweige denn, es benutzt. (Aber die Nachteile scheint ihr alle zu kennen.) Wundert mich nicht, denn sonst hätte ich hier schon längst einen Parallelportreiber gefunden. Der ist an einem Vormmitag programmiert und 5 mal schneller als ein Zugriff über Dll und Kernel. Na denn, schönen Tag noch..
Michael G. wrote: > Das ist doch vollkommen klar. Zumindest jedem, der die zugrunde liegende > Technik verstanden hat. Und die Wahrscheinlichkeit von 0.5 (die man > ohnehin hat, wenn man per Zufall entscheidet) auf 0.56 zu erhoehen... > tolle Studie. Absolut laecherlich :D Es gab kryptanalytische Angriffe auf Codebücher, bei denen man davon ausgegangen ist, dass die Zufallszahlen auf einer Schreibmaschine erzeugt wurden. Annahme: Immer ein Buchstabe von der linken Hälfte, dann einer von der rechten und so weiter. Das hat dann am Ende zum Ziel geführt. 0,56 ist zu 0,50 schon eine Menge. Wenn du BMP-Bilder hast, werden die dadurch sogar schon wieder leicht lesbar....!
Unbekannter wrote: > Na, der Heise-Artikel klingt ja so, als ob sie es schon lange gewusst > hätten. Aber genau das Gegenteil ist der Fall: Diverse Heise-Redakteure > haben diese Mär selbst gebetmühlenartig in diversen Artikeln wiederholt. Nein. Heise hat AFAIK immer gesagt, dass man Zufallsdaten nehmen soll um die Platte zu überschreiben. Und das wenigstens zweimal tun soll.
Karl-heinz Strunk wrote: > Nein. Heise hat AFAIK immer gesagt, dass man Zufallsdaten nehmen soll um > die Platte zu überschreiben. Und das wenigstens zweimal tun soll. Ach verdammt. Selbst im Artikel schreiben die ja, dass ein einfaches DD hilft und erwähnen nicht einmal die Zufallsdaten....
Platsch wrote: > Also eins muss man euch lassen Leute, hartnäckig seit ihr! Von > dynamischen Treibermodellen unter Windows und seinen Vorzügen hat noch > keiner von euch gehört geschweige denn, es benutzt. (Aber die Nachteile > scheint ihr alle zu kennen.) Wundert mich nicht, denn sonst hätte ich > hier schon längst einen Parallelportreiber gefunden. Der ist an einem > Vormmitag programmiert und 5 mal schneller als ein Zugriff über Dll und > Kernel. Und du glaubst wirklich, das man so einen Pfusch auch mit Storage-Treibern machen kann? Ich warte immer noch auf den Beweis. Aber stattdessen spuckst du nur große Bögen...
Ich dreh einfach ne selbstschneidende Schraube durch die komplette Festplatte wenn ich sie an der Arbeit ausmustern soll, ist zwar nicht 1000% sicher aber sein wir mal ehrlich, wer von euch hat so brisantes Material gespeichert das sich hier noch eine Rekonstuktion lohnt?
Die höchste Sicherheitstufe ist immer noch ..vor den Speichern LÖSCHEN MfG
>Ich warte immer noch auf den Beweis.
Ja, den fordert das Forum bibeltreuer Christen nach 50 Diskussionsseiten
zur Darwinschen Evolutionstheorie auch.
Platsch wrote: >>Ich warte immer noch auf den Beweis. > > Ja, den fordert das Forum bibeltreuer Christen nach 50 Diskussionsseiten > zur Darwinschen Evolutionstheorie auch. Behauptungen aufstellen, andere mit > Das kommt davon, wenn man es höchsten bis zum Anwendungsprogrammierer > geschafft hat. abkanzeln und sich dann mit solchen Unverschämtheiten rausreden wollen... Offensichtlich hast du keine blasse Ahnung von dem, womit du dich hier aufbläst.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.