Habt ihr eure SSD verschlüsselt?
-
Immerhin gibt es bei einer SSD keine Garantie, dass die Daten auch gelöscht werden.
Selbst wenn man die SSD vollschreibt, gibt's ja noch die Wear Leveling Puffer die die alten Daten enthalten könnten.
-
Facehugger schrieb:
Selbst wenn man die SSD vollschreibt, gibt's ja noch die Wear Leveling Puffer die die alten Daten enthalten könnten.
Und um an die zu kommen, müsste man ganz schön Aufwand betreiben.
-
Hi schrieb:
Facehugger schrieb:
Selbst wenn man die SSD vollschreibt, gibt's ja noch die Wear Leveling Puffer die die alten Daten enthalten könnten.
Und um an die zu kommen, müsste man ganz schön Aufwand betreiben.
Dafür gibt's doch sicher ByPass Schnittstellen für den Hersteller, vergleichbar mit SPI, mit der er dann auf die HW direkt zugreifen kann.
Und ich kann mir gut vorstellen, dass solche Geräte auch den Geheimdiensten und den Forensiklaboren der Polizei zur Verfügung gestellt werden.Außerdem gibt es Webseiten, wie dieser Wikipedia Artikel aufzeigt,
bei dem man schon durch den bloßen Besuch soviel strafrechtlich relevantes in seinen Browsercache geladen bekommt, dass das schon ausreicht, wenn man nur ein Bildchen davon auf der SSD findet.
http://de.wikipedia.org/wiki/Rotten.com(PS: tut euch selbst den gefallen und besucht auf keinen Fall die Webseite, über die die WP hier spricht)
Obwohl man nach A sucht, bekommt man zwangsläufig B zusätzlich aufgezwungen und das kann man nicht verhindern und es ist leider nicht die einzigste Webseite*.
Wer z.b. nach Informationen über die ISIS oder Syrien sucht läuft Gefahr, auf solchen Seiten zu landen und dann Zeugs in den Browsercache geladen zu bekommen, das man nie im Leben freiwillig auf der SSD haben will.
* Viele der anderen Webseiten kennt man auch gar nicht, also weiß man auch gar nicht, wo man möglichst nicht drauftreten sollte. Die obige hat es ja immerhin in einen Wikipedia Artikel geschafft, sie ist also bekannt genug so das sie eigentlich fast jeder der das Internet etwas besser kennt, kennen sollte, aber das gilt halt nicht für den Rest.
Wie will man sich also davor schützen? Der Browser läd das Zeugs ja von selber runter, da hilft faktisch ja eigentlich nur eine Verschlüsselung.
-
Wer benutzt heutzutage noch unverschlüsselte Medien?
-
oenone schrieb:
Wer benutzt heutzutage noch unverschlüsselte Medien?
Ich habe bisher meine Festplatten nicht verschlüsselt, weil die Verschlüsselung immer auch eine potentielle Gefahr darstellt, dass man seine Daten verliert.
Beispiel:
Wenn bei einer unverschlüsselten Festplatte bei einem Datenblock ein Bit kippt, dann sind die Daten zwar fehlerhaft, aber die Chance, dass man sie noch lesen kann, ist je nach Datentyp durchaus gegeben.
Textdateien lassen sich z.b. immer lesen und man kann an die Information immer noch herankommen, auch dann, wenn da ein Bit im Datenblock gekippt ist.
Dann ist ein Buchstabe halt ein anderer, aber die restlichen Informationen sind weiterhin zugänglich.
Bei ZIP Dateien kommt man auch noch an die Daten ran, da ZIP Reparaturmöglichkeiten bietet.
Und bei Bildern oder Videodaten besteht ebenfalls die Möglichkeit, dass man noch an alle diese Daten herankommt. Denn wenn da nur ein Bit gekippt ist, dann ist halt nur ein Pixel kaputt oder bei verlustbehafteten Formaten wie z.B. JPEG hat man dann nur einen JPEG Artefakt im Bild, der stört, aber das restliche Bild bleibt erhalten.Wenn man aber Verschlüsselung einsetzt, dann gilt dies alles nicht mehr.
Wenn bei einem Datenblock ein Bit kippt, dann kann die Verschlüsselungssoftware
diesen Datenblock nämlich nicht mehr entschlüsseln.
Die Entschlüsselung schlägt fehl und alle Daten, die in diesem Block enthalten waren, gelten als verloren.Deswegen setzte ich bisher keine generelle Verschlüsselung auf Partitionsebene ein,
weil der Datenverlust bei einem Verlust eben wesentlich größer ist.Und bei Verschlüsselungsverfahren wie z.B. mit GnuPG ist nicht nur ein Datenblock kaputt, sondern die gesamte verschlüsselte Datei. GnuPG arbeitet nämlich nicht Blockweise, sondern nimmt die ganze Datei als Einheit und kennt dabei keine Redunanz oder Fehlerkorrektur.
Defekte Blöcke sind also die größte Gefahr, bei der Verwendung von verschlüsselten Partitionen.
Ein weiteres Manko ist sicherlich die Reparaturmöglichkeit von derartigen Systemen oder Partitionen, wenn man da z.B: von außen mit einer Rettungs CD oder Live-CD ranmuss und dann alle Verschlüsseltungstools schon haben muss, um an die Daten zu kommen.
Allerdings fehlen mir hierzu die Erfahrungswerte.
Wie man an eine verschlüsselte Windowspartition herankommt, wüsste ich z.B. nicht.Aus obigen Gründen verlangt der Einsatz von Verschlüsselungssoftware auch mehr Disziplin bei Backups.
Ich mache diese eher von der Datenmenge und Datenwichtigkeit abhängig, als von zeitlichen Abständen.
Insofern müsste ich da meine Gewohnheiten ändern und von der Philosophie "Backups bei Bedarf" auf "Backups in zeitlich geregelten Abständen" umsteigen.Bei Festplatten war die Verschlüsselung nie besonders wichtig, weil es eben, wenn es mal dringend notwendig wurde, weil man z.B. auf so eine Seite wie oben unfreiwillig draufgekommen ist, die Festplatte immer richtig löschen konnte.
Und wenn man Verschlüsselung benötigt hat, dafür gab es dann ja Containerdateien, so dass man sich die Verschlüsselung auf Partitionsebene sparen konnte.Im Vordergrund stand nämlich immer der unproblematischere Zugriff auf die Partitionen, wenn irgend ein Defekt auftrat.
Mit dem Einsatz von Verschlüsselten Partitionen sieht das ganz anders aus.
Aber ihr könnt gerne mal eure Erfahrung dazu posten, was passiert ist, wenn eure Verschlüsselte Partition Defekte aufwies oder Daten verlor.
-
Es gibt sowas wie Hamming Codes die mit geringem Aufwand und Speicherverbrauch einzeln kippende Bits korrigieren können.
Ich habe letztens eine Arbeitsfestplatte verloren. Ohne Verschlüsselung würde ich sie niemals zu einem HW Experten schicken, mit dem ganzen Zeugs drauf. So gesehen rettet Verschlüsselung auch Daten.
-
Facehugger schrieb:
Die Entschlüsselung schlägt fehl und alle Daten, die in diesem Block enthalten waren, gelten als verloren.
Die Entschlüsselung "schlägt" nicht "fehl", aber es kommt ein ganzer Block Müll raus.
Wobei ein ganzer Block meist 128~256 Bit bedeutet. Also nicht unbedingt SO viel. In einem JPEG richtet das auch nicht nennenswert mehr Schaden an als ein einzelnes gekipptes Bit.
-
hustbaer schrieb:
Facehugger schrieb:
Die Entschlüsselung schlägt fehl und alle Daten, die in diesem Block enthalten waren, gelten als verloren.
Die Entschlüsselung "schlägt" nicht "fehl", aber es kommt ein ganzer Block Müll raus.
Wobei ein ganzer Block meist 128~256 Bit bedeutet. Also nicht unbedingt SO viel. In einem JPEG richtet das auch nicht nennenswert mehr Schaden an als ein einzelnes gekipptes Bit.Von wo hast du die Daten mit nur 128-256 Bit Blockgröße?
AFAIK sind das 512 Byte große Blöcke und nicht nur 512 Bit oder gar nur 128 Bit.
Und bei 512 Bytes geht eben schon sehr viel verloren.
-
Facehugger schrieb:
AFAIK sind das 512 Byte große Blöcke und nicht nur 512 Bit oder gar nur 128 Bit.
Nenn mal ein einziges (gängiges!) Verfahren, bei dem die Blockgröße 512 Bit ist. Es wäre sogar schon überraschend, wenn du eines nennen könntest, bei dem die Blockgröße >128 Bit ist (mir fallen da nur exotische AES-Varianten aus dem Originalpaper ein, die aber niemand nutzt, um mal eine Antwort vorweg zu nehmen).
PS: Ich ahne schon, gleich kommt Threefish als Antwort. Als Zusatzangabe sind daher 3 Personen auf der Welt zu nennen, die den Algorithmus praktisch benutzen, um die Gängigkeit des Verfahrens zu belegen.
-
AFAIK verschlüsselt Truecrypt in 512 Byte große Blöcke.
Ich denke du machst den Fehler, dass du die Verschlüsselungsstärke mit der Blockgröße verwechselst.
-
Facehugger schrieb:
Ich denke du machst den Fehler, dass du die Verschlüsselungsstärke mit der Blockgröße verwechselst.
Selber!
PS: Du hast nun bereits 2x deine Antworten mit "AFAIK" eingeleitet. Ist es dir nicht in den Sinn gekommen, deine Annahmen mal eben zu googeln, wenn dir zwei Leute sagen, dass du falsch liegst?
-
SeppJ schrieb:
Facehugger schrieb:
Ich denke du machst den Fehler, dass du die Verschlüsselungsstärke mit der Blockgröße verwechselst.
Selber!
PS: Du hast nun bereits 2x deine Antworten mit "AFAIK" eingeleitet. Ist es dir nicht in den Sinn gekommen, deine Annahmen mal eben zu googeln, wenn dir zwei Leute sagen, dass du falsch liegst?
Dann liefer einfach eine Quelle.
Und Kommentare als Beweis anzuführen, das kann ich auch, hier bitte:
http://www.readmore.de/forums/91-technik/60-software/85688-ssd-und-truecrypt&page=1#p2990495
-
Facehugger schrieb:
SeppJ schrieb:
Facehugger schrieb:
Ich denke du machst den Fehler, dass du die Verschlüsselungsstärke mit der Blockgröße verwechselst.
Selber!
PS: Du hast nun bereits 2x deine Antworten mit "AFAIK" eingeleitet. Ist es dir nicht in den Sinn gekommen, deine Annahmen mal eben zu googeln, wenn dir zwei Leute sagen, dass du falsch liegst?
Dann liefer einfach eine Quelle.
Ich? Du bist doch derjenige, der ein "AFAIK" als Tatsache hinstellt. Ich habe dich aufgefordert, ein einziges gängiges Blockchiffre mit >128-Bit Blöcken zu nennen. Ich habe dir sogar zwei genannt, die aber absolut ungängig sind. Was meinst du wohl, welche Blockgrößen alle gängigen Verfahren haben? 128 Bit und weniger! Woher ich das weiß? Aus deren Dokumentation! Warum ich die nicht verlinke? Weil es derart trivial ist, diese zu finden, dass jeder Leser dieses Threads sie längst gefunden hat, fast so schnell wie das Klicken auf einen Link. Alle Leser außer dir. Und das ist ein schwerer Vorwurf in einer Sachdiskussion, denn du bringst Vermutungen und Hörensagen, wo andere mit Fakten kommen.Und Kommentare als Beweis anzuführen, das kann ich auch, hier bitte:
Geht's dir noch gut? Wer führt hier Kommentare als Beweis an? Einzig alleine du! Du hingegen kannst anscheinend nicht einmal die handfesten Dokumentationen zu den von dir selber genannten Programmen lesen (Trucrypt benutzt 128 Bit-Blöcke, wie im Kapitel "Encryption Algorithms" des Handbuchs zu lesen ist). Oder Wikipedia. Oder überhaupt.
-
SeppJ schrieb:
Was meinst du wohl, welche Blockgrößen alle gängigen Verfahren haben? 128 Bit und weniger! Woher ich das weiß? Aus deren Dokumentation!
...
Du hingegen kannst anscheinend nicht einmal die handfesten Dokumentationen zu den von dir selber genannten Programmen lesen (Trucrypt benutzt 128 Bit-Blöcke, wie im Kapitel "Encryption Algorithms" des Handbuchs zu lesen ist). Oder Wikipedia. Oder überhaupt.Vielleicht versuchst du auch mal die Dokumentation die du wohl, wie du vorgibst, gelesen hast, auch zu verstehen anstatt hier nur irgendetwas falsches zu behaupten.
Lies dazu mal folgendes:
The second property requires dividing the disk into several sectors, usually 512 bytes (4,096 bits) long, which are encrypted and decrypted independently of each other. In turn, if the data is to stay confidential, the encryption method must be tweakable; no two sectors should be processed in exactly the same way. Otherwise, the adversary could decrypt any sector of the disk by copying it to an unused sector of the disk and requesting its decryption.
The third property is generally non-controversial. However, it indirectly prohibits the use of stream ciphers, since stream ciphers require, for their security, that the same initial state not be used twice (which would be the case if a sector is updated with different data); thus this would require an encryption method to store separate initial states for every sector on disk—seemingly a clear waste of space. The alternative, a block cipher, is limited to a certain block size (usually 128 or 256 bits). Because of this, disk encryption chiefly studies chaining modes, which expand the encryption block length to cover a whole disk sector.
http://en.wikipedia.org/wiki/Disk_encryption_theory#Problem_definition
Es wird also anders als du behauptest, der gesamte Block (bzw. Sektor, was ich damit meinte) verschlüsselt und obwohl die Schlüsselgröße nur 128 oder 256 Bit beträgt, durch die Verkettung durch den chaining mode, also der voneinander abhängigen aneinanderreihung der Sektor als ganzes Verschlüsselt.
Das Resultat ist genau das was ich gesagt habe.
Wenn in deinen 512 Bytes irgend ein Bit kaputt ist, dann entstehen durch den Chaining Mode Folgefehler und die Restlichen Daten sind nicht mehr lesbar.
Wenn das ganz am Anfang passiert, dann ist der ganze Block (Sektor) mit einer Größe von 512 Bytes kaputt und nichts anderes habe ich behauptet.
Man verliert also nicht nur ein paar Bit, sondern eben sehr viele Bytes.Ich weiß ja, das Verschlüsselung kein einfaches Thema ist, aber man sollte schon ein bischen davon verstehen wenn man so redet wie du es hier versucht hast.
Du und hustbear lagen also mit der Aussage, das der Datenverlust gering sei, falsch.
-
SeppJ schrieb:
genannten Programmen lesen (Trucrypt benutzt 128 Bit-Blöcke, wie im Kapitel "Encryption Algorithms" des Handbuchs zu lesen ist). Oder Wikipedia. Oder überhaupt.
Genau, TrueCrypt benutzt nur Blöcke. Türlich ist das nicht sicher, weil es ja gerade nur Blöcke sind.
~(Hab die Woche zu viele YouTube-Videos geschaut mit so V-Theorien.)~
-
Ich vergaß:
SeppJ schrieb:
Und Kommentare als Beweis anzuführen, das kann ich auch, hier bitte:
Geht's dir noch gut? Wer führt hier Kommentare als Beweis an? Einzig alleine du!
Nein, du stützt dich auf das Kommentar von Hustbaer, du hast nämlich geschrieben:
Ist es dir nicht in den Sinn gekommen, deine Annahmen mal eben zu googeln, wenn dir zwei Leute sagen, dass du falsch liegst?
Du nutzt also das Kommentar von hustbaer um deiner Aussage Ausdruck verleihen.
Das der es dann aber auch nicht besser kann, ist schade.
-
Facehugger schrieb:
Das Resultat ist genau das was ich gesagt habe.
Nein! Wie kommst du zu dieser Idee? Hast du den Artikel überhaupt gelesen oder einfach nur selektiv zitiert, was dir passt? Selbst das was du zitierst, belegt deine Aussage nicht. Du hast den Text nicht verstanden, was die Blöcke bedeuten. Der Block der Plattenverschlüsselung ist da zwar 512 Bit lang, aber wenn ein Bit kaputt ist, geht trotzdem nur der Subblock des eigentlich unterliegenden Blockchiffre kaputt und der ist 128 Bit groß. Denn der Klartext wird letztlich immer noch mit blockweise (128 Bit) mit dem unterliegenden Blockchiffre verschlüsselt, es werden bloß noch zusätzliche Operationen ausgeführt, die von der Position des Klartextblocks innerhalb des Superblocks abhängen (512 Bit). Und zwar unabhängig vom Klartext im Rest des Superblocks! Entsprechend kann aus einem einzelnen Unterblock (und der Position im Superblock) auch wieder der Klartext hergestellt werden, selbst wenn im Rest des verschlüsselten Superblock Fehler auftreten. Ich weiß nicht, wie du den Artikel verlinken kannst und das nicht sehen kannst. Das ist doch "nur" das Thema des Artikels.
(Anmerkung: Bei CBC gehen zwei Blöcke kaputt, da doch etwas Information des Vorgängerblocks einfließt. Also gehen 256 Bit* kaputt. Jetzt kapierst du vielleicht auch, wo hustbaer seine Zahlen her hat. Der kennt sich nämlich aus. Truecrypt benutzt übrigens eine XEX-Variante, kein CBC, aber das tut nix zur Sache. Alle Cypher-Block-chaining-Verfahren sind fehlerresistent und verlieren im schlimmsten Fall nur 2 Unterblöcke. Die Leute, die sich das ausgedacht haben, sind schließlich nicht doof. Beispielsweise kann beim genannten CBC der Nachfolger des Nachfolgers des fehlerhaften Blocks anhand der beiden umgebenden Blöcke zu 100% wieder hergestellt werden.)Wenn du einfacheres Lesematerial brauchst, kannst du ja mal die Truecrypt-FAQ (Original aus bekannten Gründen leider nicht mehr verfügbar) (What will happen when a part of a TrueCrypt volume becomes corrupted?) lesen oder eine der Zusammenfassungen auf Wikipedia.
Ich weiß ja, das Verschlüsselung kein einfaches Thema ist, aber man sollte schon ein bischen davon verstehen wenn man so redet wie du es hier versucht hast.
Du und hustbear lagen also mit der Aussage, das der Datenverlust gering sei, falsch.Wow, jetzt hast du dich aber ganz schön in die Nesseln gesetzt. Du hast gerade selber einen Artikel verlinkt, in dem erklärt wird, dass du Scheiße laberst. Ich stehe auch darüber, dir hier sämtliche deiner unnötigen Anfeindungen+ aus diesem Thread noch einmal genüsslich unter die Nase zu reiben, von denen du gerade bewiesen hast, dass sie auf dich und nur auf dich zutreffen.
volkard schrieb:
Genau, TrueCrypt benutzt nur Blöcke. Türlich ist das nicht sicher, weil es ja gerade nur Blöcke sind.
Sachlich richtige Aussage (unter Einbeziehung von Ironie), aber Thema verfehlt. Note Sechs. Denn trotz des Chainmodus bleibt die unterliegende Struktur des Blockchiffre erhalten und jeder einzelne fehlerfrei Block kann unabhängig von den anderen Blöcken wieder hergestellt werden. Und mehr als einen normalen Blockchiffre in einem Chaining-mode benutzen Truecrypt & co. nicht, nein. Ausgenommen natürlich KRYPTO 2.0.
*: Genau genommen sind nur 129 Bits kaputt bei einem Bitfehler. Denn im Folgeblock ist nur genau das eine Bit des Klartextes kaputt, welches im (verschlüsselten) Vorgängerblock kaputt war. Aber ich bin mal so großzügig, das als 256 kaputte Bits zu zählen, damit du mehr von dem verstehst, was dir hustbaer vor so langer Zeit erklären wollte.
+: Zugegeben benutze ich in diesem Beitrag auch nicht (mehr) die feine englische Art. Aber du hast es echt verdient bei deinem provokativem Geschreibsel.
-
Hat hier jemals jemand bei einer Festplatte oder SSD einen einzelnen Bitfehler erlebt?
Ich kenne nur, dass direkt ganze Sektoren kaputtgehen, aber nicht, dass falsche Daten kommen. Ich wüsste auch gar nicht, wie das passieren könnte, denn die Festplatte hat intern doch auch schon Fehlerkorrekturcodes, wird also einzelne Bitfehler sicher bemerken.
Das einzige Szenario, dass ich mir vorstellen kann, ist, dass die Daten schon mit gekipptem Bit an die Festplatte zum Schreiben gesendet wurden. Dagegen gibt es aber genug Maßnahmen, die man unternehmen könnte.
-
Facehugger schrieb:
Ich habe bisher meine Festplatten nicht verschlüsselt, weil die Verschlüsselung immer auch eine potentielle Gefahr darstellt, dass man seine Daten verliert.
Dafür gibt's Backups. Oder deine Daten sind es eh nicht Wert zu verschlüsseln.
