Re: Verschlüsselung in Lenny
On Mon, 29 Dec 2008 15:55:35 +0100
Dirk Salva <dsalva@gmx.de> wrote:
> Gibt es einen Vergleich bzgl. der Sicherheit der beiden Systeme? Mir
> nutzt eine Verschlüsselung meines /home auf meinem EeePC mal so goar
> nüscht, wenn die jeder Flughafendepp in Amiland aushebeln kann - mal so
> salopp formuliert. dm-crypt (und natürlich auch truecrypt) sollte
> also schon hinreichend sicher sein...
Einen direkten Vergleich kenn ich jetzt nicht, aber im Prinzip gibt es da nicht viel zu sagen.
reines dm-crypt hat wie TC keine header - damit lässt sich schwerer behaupten, zufällig erscheinende Daten wären ein verschlüsseltes Volume.
Allerdings wenn man die Konfiguration in z.B. /etc/crypttab speichert, um nicht jedes mal per Hand Parameter einzugeben, dann ist es nicht viel versteckter als bei LUKS, wo ein LUKS-Header mit Verschlüsselungsparametern am anfang des Volumes geschrieben wird.
Wie geht TC vor? Es stellt sich extra "blöd" an und versucht alle möglichen Kombinationen von Keysize/Verfahren/Hash-Algo/etc. Dadurch braucht es keine Parameter aber installiertes TC kann schon dadrauf hindeuten, dass da was verschlüsselt ist und da man nicht jedes mal alles per Hand machen will (vor allem nicht für /home) wird auch irgendein Skript dadrauf hindeuten, dass /home-Volume z.B. verschlüsselt ist.
Unter dem Strich wahrscheinlich garkein Mehrgewinn an Sicherheit, dadurch, dass man keine Heder hat.
Was TC und pures dm-crypt nicht haben, ist die Möglichkeit mehrere Zugänge zu haben. Mit LUKS kann man für das Volume bis zu 9 Passphrasen/Keys definieren und diese löschen/ändern. Beim TC hat man da nur einen. Bei mehreren Benutzern ist LUKS evtl. vorteilhafter, da man jedem andere Passphrase geben kann.
Als Verschlüsselung bietet TC mehr Kombinationen, aber sonst die selben Verfahren wie dm-crypt (LUKS tut hier nichts zur Sache). Das sind standard AES und dann noch Twofish und Serpent. In TC sind Kaskaden möglich, was rein theoretisch sicherer sein kann, aber auch viel langsamer, deshalb man es eh kaum nutzen dürfte.
Die Algos sind sonst gleich. Interessant sind auch IV-Methoden. Bei TC wurde in letzter Zeit sehr oft gewechselt, CBC (-plain) -> LRW -> XTS. Ähnlich bei dm-crypt. Hier hat man aber zwischendurch noch cbc-essiv verwendet. CBC(-plain) soll man nicht mehr verwenden, da es sogenante watermark-attacs erlaubt. Mit etwas mehr Aufwand gilt das auch für LRW. Das war auch der Grund, warum es gewechselt wurde.
DAS IST AUCH DER GRUND, warum man unter Umständen später genötigt wird es neu zu verschlüsseln (wahrscheinlich geht es dann wiederum nicht in-place). Ob das bereits beim nächsten Distributionswechsel ist oder erst nach 10 Jahren, kann niemand sagen.
Etch hatte z.B. höchstens cbc-essiv. Nach Upgrade auf Lenny wäre es nicht schlecht auf XTS zu wechseln, aber hier ist es kein Muss. AES gilt relativ als sicher und vielleicht wird XTS halten, was es verspricht.
dm-crypt selbst und LUKS werden sehr wahrscheinlich weiter gepflegt.
Bei TC sah das bisher so aus, dass nach Einführung neuerer IV-dings-verfahren die alten nicht mehr zur Erstellung benutzt werden konnten, sondern nur zum öffnen bestehender Container. Ich weiß es gerade nicht, aber ich glaube die ganz alten Verfahren wurden dann mit übernächster major-Version fallen gelassen. Man müsste das auch tun, sonst gibt es irgendwann zu viele Kombinationen, die man mit gegebener Passphrase für ein Volume prüfen müsste (TC nimmt keine Parameter entgegen, sondern stellt diese per Brute-Force fest).
Was man noch vergleichen könnte, wären verschiedene Hash-Verfahren. Alle nutzen mehr oder weniger die üblichen Hash-Verfahren und man kann es sowohl unter TC als auch dm-crypt noch selber wählen, wenn man nicht den Standard wählen will.
Also Fazit:
Sicher verschlüsseln heißt immer auf der Hut sein und wenn irgendwo in Algorithmen Schwächen entdeckt werden dann auf sicherere Algorithmen umsteigen. dm-crypt wurde letztens um LUKS erweitert; in Zukunft gibt es vielleicht weitere Erweiterungen, aber es wird weiterhin gepflegt und unterstüzt und das wird wohl so bleiben. Man wird aber u.U. dennoch nach gewisser Zeit umverschlüsseln müssen und da gibt es unter Linux eher nicht die Möglichkeit es in-place oder noch besser online zu machen.
(jetzt habe ich viel mehr geschrieben, als ich wollte)
Reply to: