mikrocontroller.net

Forum: Offtopic Na also - "sicheres Löschen" ist Quark


Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ...

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Herr Lich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Herrlich:
"In einer wissenschaftlichen Untersuchung hat er"
"und wer weiß wohin gespeichert worden"

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Stefan Helmert (Firma: dm2sh) (stefan_helmert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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....

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Timbo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd T. (bastelmensch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! :-)

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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! :)

Autor: Bernd T. (bastelmensch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Platsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Indem du die ganze Platte verschlüsselst, z.B. mit Truecrypt.
Das geht ja noch langsamer und kompatibel ist das nun auch nicht gerade.

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ist doch egal wie oft du es löscht. einen sicherheitskopie von deinen 
daten hat doch der Hr. Schäuble!

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Onko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soviel Aufwand .....


Ich beame meine Platte einfach in die nächste Sonne und repliziere mir 
dann ne Neue.

Autor: Platsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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..

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Andreas S. (camomile)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
50% ist reiner Zufall. Wenn man ein Bit mit 56%-tiger Wahrscheinlichkeit 
richtig lesen kann, ist man etwas besser, als der Zufall.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das eröffnet ja ganz neue Perspektiven der Datenkompression ;-)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Platsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würde vermuten das es ansonsten eh nur um Kopierschutz geht.

Autor: Platsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Uner Windows kann jedes Programm das nicht mit Gast-Rechten läuft
> dynamisch am Kernel vorbei die Hardware programmieren ...

Ach?

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: Platsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Esko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Platsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).
    // mal nur das wesentliche
    FileStream inStream;
    FileStream outStream;
    byte[] buffer = new byte[1 << 26];
    int rLength;

    inStream = File.OpenRead(args[0]);

    outStream = File.Create(args[1], 1 << 26, FileOptions.SequentialScan);

    while (true) {
        rLength = inStream.Read(buffer, 0, 1 << 26);
        if (rLength <= 0) break;
        outStream.Write(buffer, 0, rLength);
    }
    
    inStream.Close();
    outStream.Close();

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Platsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: Karl-heinz Strunk (cletus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....!

Autor: Karl-heinz Strunk (cletus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl-heinz Strunk (cletus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Aeroengine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: juppi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die höchste Sicherheitstufe ist immer noch
..vor den Speichern LÖSCHEN

MfG

Autor: Platsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich warte immer noch auf den Beweis.

Ja, den fordert das Forum bibeltreuer Christen nach 50 Diskussionsseiten 
zur Darwinschen Evolutionstheorie auch.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Yahoo-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.