Diskussion:Dm-crypt

Aufwand Löschen/Wiederherstellen defekte Platte

Der Aufwand, die Daten auf einer defekten Platte zu löschen ist minimal (im Vergleich zur Wiederherstellung): Platte aufschrauben, Magneten über die Platten ziehen. Oder irre ich? 85.179.70.128 21:31, 24. Apr. 2008 (CEST)

Korrekt. Ich hab den Absatz mal umgeschrieben. --h3ndrik 03:46, 7. Mai 2008 (CEST)

Technisch ja, organisatorisch ist es aber zusätzlicher Aufwand 141.113.85.91 (14:00, 19. Jul 2010 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Alternative?

Ich weiß nicht so recht, ob es korrekt ist TrueCrypt als Alternative zu dm-crypt aufzuführen. Unter Linux nutzt TrueCrypt nämlich selbst dm-crypt im Hintergrund.

Mich überzeugt es auch nicht, dass LUKS hier noch einmal als Alternative angeführt wird, nachdem es wenige Absätze vorher noch als Ergänzung zu dm-crypt vorgestellt wurde. Ich schlage daher vor, den Satz zu löschen, wenn niemand »echte« Alternativen zu dm-crypt mit Linux kennt oder vernünftige Gründe anführt, TrueCrypt und LUKS da stehen zu lassen. Sollte hier in den nächsten Tagen keine abweichende Auffassung vertreten werden, werde ich das machen.--Marcel Keienborg 10:35, 8. Feb. 2009 (CET)

Links zu LUKS

Warum wird hier zu LUKS verlinkt, wenn LUKS auf Dm-crypt weiterleitet? Das finde ich ehrlichgesagt etwas irreführend, weil es suggeriert, daß Weitere Informationen zu LUKS vorhanden sind. Es wird auch von anderen Artikeln aus auf dm-crypt UND LUKS verlinkt. Wäre es da nicht besser, die Weiterleitung wegzulassen?

Ich habe den Link entfernt. -- Stefan Birkner 23:26, 13. Jan. 2009 (CET)

glaubhafte Abstreitbarkeit

hi, kann mir mal irgendjemand sagen warumm man abstreiten sollte das man daten verschlüsselt hat. Verschlüsselung ist doch nicht verboten und im zwiefel für den Angeklagten. wiso ist das ein nachteil. -- Treaki 18:59, 21. Apr. 2010 (CEST)

Starke Verschlüsselung ist in Deutschland derzeit nicht gesetzlich verboten, das ist richtig. Gilt das für alle Länder der Erde? Zudem könntest du auch einfach von jemandem erpresst werden, um den Kryptoschlüssel rauszurücken. Dann ist es unter Umständen von Vorteil, wenn du glaubhaft(!) abstreiten kannst, dass die Festplatte verschlüsselte Daten enthält.

Natürlich ist es wenig plausibel, wenn man abstreiten will, dass die einzige Festplatte in einem Büro-PC (möglicherweise illegal) verschlüsselten Daten enthält, und man behauptet, dass sie nur mit Zufallsdaten überschrieben worden sei.

Bei meiner Sammlung alter, ausgemusterter, teilweise defekter, Festplatten hingegen ist es schon eher plausibel, wenn ich sage, dass ich die alle mit Zufallsdaten überschrieben habe, sowohl um die alten Daten zuverlässig zu löschen, als auch um zu testen, ob die Platte defekte Sektoren aufweist. Tragen diese (angeblich) ausgemusterten Festplatten jedoch alle einen LUKS-Header, ist die Behauptung mit den Randomdaten nicht mehr plausibel.

Zudem steht im LUKS-Header auch, welcher Kryptoalgorithmus verwendet worden ist. Falls dieser Algo eines Tages sich als schwach erweist, ist es für Angreifer sehr rasch möglich, etwa die Header aller beschlagnahmten Festplatten in der Asservatenkammer nach der Verwendung dieses Algorithmusses zu scannen. Deutlich(!) schneller jedenfalls, als ein Brute-Force-Angriff auf einen unbekannten Algorithmus.

Auch wenn man sich nie auf Security by obscurity allein verlassen sollte, sie kann – ebenso wie Steganographie – aber zumindest dabei helfen, dass man gar nicht erst einen Verdacht auf sich zieht. --RokerHRO 22:17, 21. Apr. 2010 (CEST)

Vor einiger Zeit gab es beispielsweise Medienberichte (u.a. bei Heise IIRC), wonach die US-Grenzschutzbehörden befugt seien, Festplatten von Einreisenden zu durchsuchen oder gar zu beschlagnahmen, alleine deswegen, weil sie verschlüsselte Daten enthält. Da soll es wohl auch tatsächlich zu der einen oder anderen Beschlagnahme gekommen sein. Da wäre es schon hilfreich, wenn man den Eindruch erweckt, keine verschlüsselten Daten auf der Platte zu haben, gell? --Marcel Keienborg 09:34, 22. Apr. 2010 (CEST)

Zum Beispiel. Wobei da eine Festplatte voller angeblicher Randomdaten auch schon verdächtig genug wäre, denk ich mal. Das ist genauso verdächtig wie eine Platte mit LUKS-Header. Aber eine unscheinbar (aber nicht auffallend unbenutzt!) wirkende Windows-Installation, wo irgendwo eine Datei Hochzeitsvideo.wmv rumliegt, wo dann ab Dateioffset 102400 keine Videodaten mehr sind, sondern ein Kryptocontainer beginnt, dürfte nur schwer zu enttarnen sein, außer eben der Kryptocontainer fängt mit einer LUKS-Signatur an. </paranoia> --RokerHRO 10:55, 22. Apr. 2010 (CEST)

Backups / Editwar

(aus meiner Diskussionsseite hier her kopiert)

Lieber "RokerHRO" Vielleicht solltest du dich mal darüber informieren was Backups oder 1:1 - Kopien sind, wie diese funktionieren und wieviel das mit diversen Daten innerhalb der Platte zu tun hat - nämlich überhaupt nichts. Ich kann jede beliebige Platte kopieren, jederzeit und mit jedem Dateisystem. Wenn du das bezweifelst dann würde ich dich bitten erstmal Infos zu sammeln statt [einfache Wahrheiten vertuschen zu wollen]

Ich kann bei LUKS-verschlüsselten Partitionen nicht die Original-Partition 1:1 in einen verschlüsselten Container auf der gleichen Partition packen, da in dem verschlüsselten Container weniger Platz ist. Den verschlüsselten Container kann man anschließend natürlich 1:1 umherkopieren. Darum ging es aber gar nicht. --RokerHRO 21:05, 1. Apr. 2011 (CEST)

Das ist natürlich erneut grober Schwachsinn - natürlich kann man dasm, ganz problemlos sogar sofern n Bytes Speicherplatz verfügbar ist - n soll hier für die Nutzdaten inkl. aller tollen Header und Keyfiles stehen.

Übrigens macht ein Backup auf der selben Festplatte und im selben Container (!!) recht wenig Sinn - das is zualledem ein recht unrealistisches Szenario

Wie willst du ein Dateisystem, das 1000 Blöcke auf einer Partition (die ebenfalls 1000 Blöcke groß ist) in-place in einen LUKS-Container packen, wenn durch LUKS 16 Blöcke belegt werden und somit nur noch 984 Blöcke im Container zur Verfügung stehen? --RokerHRO 21:16, 1. Apr. 2011 (CEST)

Stichwort "Nutzdaten" - bitte informiere dich über elementarste Dinge der Informatik bevor du nen Edit-War anzettelst, danke. Wenn du diese 1000 Blöcke tatsächlich belegt hast ist immernoch eine Kompression möglich. Und hier noch einmal, bitte lies das GANZ GENAU : Ein Backup findet definitionsgemäß nicht auf dem selben Medium statt

Der Bezug zu Backups war folgender: Eine 2-TB-Platte kann man nicht auf eine 2. identische 2-TB-Platte (sektorweise) backuppen, wenn man das Backup verschlüsseln möchte (weil es z.B. außer Haus lagert) und es dafür in einen LUKS-Container packt. Und nein, Kompression ist keine Lösung, da a) Kompression keinen wahlweisen Zugriff mehr gestattet und b) bei Multimediadaten keine effektive Datenreduktion mehr bringt, da diese Daten inkompressibel sind. --RokerHRO 21:21, 1. Apr. 2011 (CEST)

Die Nutzdaten sind praktisch immer kleiner als der Container - selbst wenn nicht dann lassen sich Daten ausnahmsfrei komprimieren - in jedem Fall. Dass Kompression einen wahlweisen Zugriff unterbindet ist natürlich ebenso Unfug, der Zugriff benötigt lediglich zusätzliche Operationen. Die Effizienz von Kompressionen ist wohl hier vollkommen uninteressant - es gibt im Übrigen keine "inkompressiblen" Daten, das ist physikalisch unmöglich - ich kann einen kompletten Datensatz von 1 TB mit einem einzigen Byte substituieren - dazu muss meine Symboldatenbank eben mind. 1 TB groß sein (nicht signierter Beitrag von 95.89.176.229 (Diskussion) 21:40, 1. Apr. 2011 (CEST))

Ob die Nutzdaten komprimierbar sind oder nicht, spielt bei sektorweisen Kopien (ja, dafür gibt es durchaus sinnvolle Anwendungsfälle) keine Rolle. Denn Kompressionsverfahren, die wahlfreien Zugriff auf einzelne Datenblöcke erlauben, benötigen zusätzliche Verwaltungs-Daten, in denen der Offset und/oder die komprimierte Länge jedes Datenblocks vermerkt sind (siehe z.B. cloop). Zudem sind die Blockgrößen der meisten modernen Kompressionsalgorithmen deutlich größer (32 KiB (gzip), 900 KiB (bzip2) oder noch mehr (LZMA)) als die 512 oder 4096 Bytes der Festplatte bzw. des Dateisystems. Das verkompliziert den Zugriff auf komprimierte Medien noch weiter und wird daher nur in besonderen Fällen gemacht, etwa bei Live-CDs/-DVDs, wo man möglichst viele Daten auf den Datenträger packen will.

Wenn du aber eine bessere Fomulierung für die Aussage, die ich mit dem Aufzählungspunkt ausdrücken wollte, kannst du sie gerne hier vorschlagen. Ich bin für Verbesserungen offen. :-)

--RokerHRO 13:00, 2. Apr. 2011 (CEST)

Da Wikipedia sich mittlerweile wieder lächerlich macht und zu archaischen Systemen zurückkehrt (automatische Sichtung, Aussperrung n. registrierter Nutzer, Edit-Wars von Fachfremden) hat das hier keinen Sinn ... ich denke, ich weiss nun warum Wiki mittlerweile an vielen Gymnasien und einigen Hochschulen verboten ist, vielen Dank. Übrigens wurde eine Verbesserung von dir selbst wieder rückgängig gemacht, danach hast du deinene kleinen Freund in der Administration geholt, vermutlkich hast du nichtmal gelesen was ich verbessert hat. Gut, ich stimme dann der allgemeinen Auffassung über Wiki zu - Spenden fallen somit auch weg, danke für die Klarstellung und viel Spaß noch in Eurem exklusiven Club. (nicht signierter Beitrag von 95.89.177.145 (Diskussion) 15:38, 2. Apr. 2011 (CEST))

Okay, es kommen keine fachlichen Beiträge mehr. Schade. :-( --RokerHRO 18:42, 2. Apr. 2011 (CEST)

Dieser Abschnitt hat leider nicht zur Verbesserung des Artikels beigetragen und braucht daher nicht archiviert werden.

Angreifbarkeit

Die in dieser Sektion angeführten Angriffe stimmen so nicht direkt. Mit dm-crypt kann man alle möglichen Modi verwenden, die heute eingesetzten (von Distributoren voreingestellt) und empfohlenen Modi (LRW/XTS) haben die aufgeführten Probleme allerdings nicht. (nicht signierter Beitrag von 92.231.125.150 (Diskussion) 21:06, 25. Okt. 2011 (CEST))

Welche Angriffe genau meinst du? Dass der Wasserzeichenangriff nicht mehr relevant ist, steht ja schon drin. Alle anderen Szenarien sind IMHO unabhängig vom Verschlüsselungsalgorithmus und -modus. --RokerHRO 14:48, 26. Okt. 2011 (CEST)

Allgemeinheiten im Abschnitt „Nachteile“

Die genannten Nachteile beim Datendurchsatz sind nicht spezifisch für dm-crypt. Warum werden sie hier erwähnt? Und wenn der Rechner schneller ist, ist der Verschlüsselung schneller. Bitte mehr unspezifische Weisheiten :-P. (nicht signierter Beitrag von 91.66.35.11 (Diskussion) 11:43, 7. Sep. 2013 (CEST))

Ich hab die Formulierung erweitert. So besser? --RokerHRO (Diskussion) 23:17, 8. Sep. 2013 (CEST)

Zitat:'benötigen Platz auf dem Datenträger; damit ist keine sektorweise 1:1-Kopie in verschlüsselte LUKS-Container (z. B. für Backups) gleicher Größe möglich' Ergibt für mich keinerlei Sinn. Natürlich ist die Größe des luksCOntainers die Payload+HEader und natürlich hat ein 1:1 Backup genau die Größe des Containers. 79.232.67.183 00:37, 2. Okt. 2014 (CEST)

Weil LUKS – im Gegensatz zu plain dmcrypt – eben einen Header benötigt, ist der für Nutzdaten zur Verfügung stehende Bereich auf dem Datenträger kleiner. Damit kann man einen (unverschlüsselten) Datenträger mit x Byte Nutzdaten nicht 1:1 in einen LUKS-Datenträger umwandeln, weil eben dann nur noch x-LuksHeaderSize für Nutzdaten zur Verfügung stehen, oder eben der Container, weil er eben größer ist, nicht mehr auf das gleiche Medium passt.

Wenn dir eine bessere Formulierung für diesen Sachverhalt einfällt, darfst du den Satz gerne umformulieren.

--RokerHRO (Diskussion) 11:29, 2. Okt. 2014 (CEST)

Durchsatz

Bei typsichen PCs liegt der Verschlüsslungsdurchsatz der CPU weit über der schreibleisutng der Festplatte (Lediglich bei einigen Schwachbrünstigen Notebooks mit schnellen SSDs ist das anders). Da dm-crypt priorisiert läuft sinkt der Datenduchsatz deswegen gar nicht. Lediglich wenn man während dem Schreiben ein Progamm, dass die CPU auch voll ausnutzen könnte (Was bei typischen Home anwendern mittlerweile auch relativ selten ist) wird deises etwas langsamer laufen. Das sollte man vielleicht irgend wie anmerken. Weiß aber nicht ob das zu weit geht. --Fabiwanne (Diskussion) 14:40, 22. Mai 2014 (CEST)

Quelle fehlt

Aus "Verschlüsselungsparameter / Beispiele": "Twofish-Algorithmus im ECB-Modus (nicht empfehlenswert)" - Warum nicht? Quelle? (nicht signierter Beitrag von 85.216.93.94 (Diskussion) 17:43, 7. Dez. 2014 (CET))