ubuntuusers.de

Hallo,

möchte mein neues (gebrauchtes) Thinkpad X41 (1,5 Ghz PM LV, 2 GB Ram und langsame HDD) verschlüsseln, wie im WIKI beschrieben (http://verschluesselung.info/linux/ubuntu-dateisystem/ bzw. http://wiki.ubuntuusers.de/System_verschl%C3%BCsseln )

Hat das Auswirkungen auf die Performance d.h. Arbeitsgeschwindigkeit? (Habe das im WIKI-Artikel nicht ganz verstanden)

Grüße,

bloch

Natürlich hat das Auswirkungen auf den IO-Durchsatz, da jedes IO-Operation auf der spezifischen Festplatte über die Verschlüsselungsalgorithmus abgewickelt werden muss. Im normalen Betrieb, also beim Surfen, E-Mails checken, Musik hören, Office-Dokumente bearbeiten, etc. fällt das allerdings nicht ins Gewicht. Ich zumindest spüre an meinem Notebook keinen wirklich Unterschied zu meinem unverschlüsselten Desktop-Rechner. Bei IO-lastigen Aufgaben wie der Stabelverarbeitung großer Bilddateien, oder gar bei CPU- und IO-lastigen Aufgaben wie der Videokodierung dürfte der Performance-Unterschied dagegen deutlich zu spüren sein.

Gibt es eine Möglichkeit das Ganze ressourcenschonender zu machen? Ich hatte mir das - in meiner Unwissenheit - so vorgestellt, dass die Platten beim Hochfahren entschlüsselt werden, dann ganz normal funktionieren (ohne Einbußen) und erst wieder verschlüsselt sind, sobald das System ausgeschaltet wird. Ist das nicht so? Gäbe es eine Möglichkeit das so zu handhaben ohne große Sicherheitsrisiken?

Grüße

bloch

bloch schrieb:

Gibt es eine Möglichkeit das Ganze ressourcenschonender zu machen?

Nein.

Ich hatte mir das - in meiner Unwissenheit - so vorgestellt, dass die Platten beim Hochfahren entschlüsselt werden, dann ganz normal funktionieren (ohne Einbußen) und erst wieder verschlüsselt sind, sobald das System ausgeschaltet wird. Ist das nicht so?

Nein. Denk doch mal bitte kurz darüber nach: Wie sollte den dieses "beim Hochfahren Entschlüsseln" funktionieren?

Hat das Auswirkungen auf die Performance d.h. Arbeitsgeschwindigkeit?

Die Auswirkungen sind marginal. Phoronix hatte mal Benchmarks durchgeführt

http://www.phoronix.com/scan.php?page=article&item=ubuntu_hdd_encrypt&num=1

Auf deinem System wirst du keinen Unterschied merken.

Gibt es eine Möglichkeit das Ganze ressourcenschonender zu machen? Ich hatte mir das - in meiner Unwissenheit - so vorgestellt, dass die Platten beim Hochfahren entschlüsselt werden, dann ganz normal funktionieren (ohne Einbußen) und erst wieder verschlüsselt sind, sobald das System ausgeschaltet wird. Ist das nicht so? Gäbe es eine Möglichkeit das so zu handhaben ohne große Sicherheitsrisiken?

Nein. Die Daten liegen immer verschlüsselt auf der Platte. Wie stellst du dir das denn vor?

Die Phorinix-Benchmarks sind ja wohl ein schlechter Witz. Was sollen in diesem Zusammenhang Spiele, die von Prozessor- und Grafikleistung, aber nur beim Laden von IO abhängen? Gleiches gilt für alle Benchmarks, wo die Verarbeitung der Daten im Vordergrund steht, z.B. beim Encodieren und Komprimieren von Daten. Klar ist der Unterschied da gering.

Außerdem wurde zum Test ein Doppelkernsystem verwendet (X2 4200), dessen Leistung doch deutlich über dem eines P-M 1,5 liegt, zumal sich auch bei Singlethread-Anwendungen die Kerne die Arbeit (Verschlüsseln und encodieren, um ein schlechtes Beispiel zu nennen) teilen können. Das ist beim P-M nicht der Fall.

Wenn man mit aes-xts und 512 Bit verschlüsselt, wie in manchen Anleitungen angegeben, sinkt der Festplattendurchsatz auf bestenfalls etwa 10 MB/s bei meinem P-M 1,7 (Thinkpad T42, schnelle Festplatte). Ähnliche Größenordnungen bekommst Du vermutlich mit Deinem System. 512 Bit sind in jedem Fall overkill, selbst der NSA reichen für die höchste Geheimhaltungsstufe 384. Wenn die Daten nicht auch bei einem Diebstahl des Geräts noch in vielen Jahren vor einer Entschlüsselung durch Organisationen mit großen Ressourcen sicher sein sollen, kann man die Schlüssellänge auf 256 bit reduzieren.

Damit ist auch die gefühlte Arbeitsgeschwindigkeit, die ja auch durch das gelegentliche Starten eines nicht dauerhaft benötigten Programms oder die Aufwachgeschwindigkeit aus Suspend-to-disk beeinflusst wird, absolut annehmbar. Beim meinem ersten Versuch mit versehentlich 512 Bit fand ich das System sehr träge.

droebbel schrieb:

Wenn man mit aes-xts und 512 Bit verschlüsselt

Hast du da eine Quelle zu? AES versteht nur 256-Bit Schlüssel. Ergo ist die einzige Möglichkeit, größere Schlüssel zu verwenden, AES mehrfach ablaufen zu lassen. Das das auf die Performance geht, ist wohl nicht weiter verwunderlich.

der NSA reichen für die höchste Geheimhaltungsstufe 384.

Quelle?

Wenn die Daten nicht auch bei einem Diebstahl des Geräts noch in vielen Jahren vor einer Entschlüsselung durch Organisationen mit großen Ressourcen sicher sein sollen, kann man die Schlüssellänge auf 256 bit reduzieren.

Du sagst das so, als wären 256-Bit Schlüssel schon beinahe gebrochen. Dabei würde selbst der schnellste bekannte Rechner (IBM Roadrunner) mit seiner Spitzenleistung von 1,7 Petaflops (aktuell sind es iirc 1.1 Petaflops) selbst zum Brute-Forcen eines 128-Bit Schlüssels so lange brauchen, dass unser aller Schöpfer in dieser Zeit sein Universum getrost ein paar tausend Mal hätte erschaffen können. Ohne Quantencomputer sind selbst 128-Bit Schlüssel mit Brute-Force-Angriffen nicht innerhalb der Lebenszeit eines Menschen zu brechen. Das kannst du dir selbst ausrechnen ...

Für andere Angriffe ist die Schlüssellänge als solche erstmal nachrangig, da kommt es viel mehr auf die verwendeten Modi an.

Oh, reingefallen, sorry. Was man bei cryptsetup unter der Option -s angibt, ist wenn ich mich recht entsinne seltsamerweise u.U. die doppelte Länge des eigentlichen Schlüssels, zumindest bei XTS. Und kurzerhand hab ich überall die Zahlen verdoppelt. Also: alle meine Schlüssellängen halbieren, dann stimmts.

Was die NSA und AES-192 (!) angeht: http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf

Und was meine vorsichtige Formulierung angeht: die sollte eigentlich im Gegenteil suggerieren, man könne AES-128 in einem solchen Anwendungsfall normalerweise problemlos verwenden.

Nebenbei könntest Du den auch nach meiner Erfahrung recht geringen Performanceverlust der Verschlüsselung durch andererseits durch Wechsel auf ein schnelleres Dateisystem kompensieren. Das Standard-Dateisystem unter Ubuntu, ext3, ist sehr stabil und sicher, aber dafür relativ langsam.

Hier ist ein (englischer) Vergleichstest aus 2006, der allgemein oft zitiert wird:

http://www.debian-administration.org/articles/388

Ansonsten im Forum z.B. mal nach ext3, xfs, jfs oder reiser suchen. Bzw. die entsprechenden Artikel in der Wikipedia.

Ciao

V.

Oder du verschlüsselst dein System nicht, sondern deine Daten. Dann verringert sich nur die Schreib/Lesegeschwindigkeit der Daten, was wenig ins Gewicht fällt. Der Rest ist bei den meisten ohnehin mehr naives Placebo vergleichbar mit einer Panzertür als Haustür bei offener Balkontür. Wirklich gesicherte Systeme sind im täglichen Umgang so unpraktisch und teuer, dass die hier gewünschte Variante mehr Fetisch ist, der die Nerven beruhigt. Gewissermaßen die "Personal Firewall" der Tuxer 😉

Wobei dann allerdings unverschlüsselte Datenreste in diversen Systemordnern und der swap-Partition bleiben können.

Ich habe mein System komplett verschlüsselt (Athlon 64 3200 mit 2 GB RAM bzw. Sempron 3000 mit 1 GB RAM) und kann keine merkbaren Verzögerungen im Betrieb feststellen.

V for Vortex schrieb:

Nebenbei könntest Du den auch nach meiner Erfahrung recht geringen Performanceverlust der Verschlüsselung durch andererseits durch Wechsel auf ein schnelleres Dateisystem kompensieren. Das Standard-Dateisystem unter Ubuntu, ext3, ist sehr stabil und sicher, aber dafür relativ langsam.

Hier ist ein (englischer) Vergleichstest aus 2006, der allgemein oft zitiert wird:

http://www.debian-administration.org/articles/388

Die Ergebnisse dieses Tests sind zumindest für ext3 nicht aussagekräftig, da der Autor sich über die genutzten Optionen ausschweigt. Man erfährt weder, welche Journaling-Strategie für ext3 genutzt wurde, noch ob hashed binary trees für Verzeichnisse aktiviert wurden. Besonders die Nutzung von Binärbäumen wirkt sich positiv auf die Performance bei Verzeichnisoperationen aus.

@V Das ist richtig. Dagegen schützt dieses Vorgehen effektiv. Allerdings würde ich vermuten, dass dein RAM z.B. vollkommen ungeschützt ist.

adun schrieb:

@V Das ist richtig. Dagegen schützt dieses Vorgehen effektiv. Allerdings würde ich vermuten, dass dein RAM z.B. vollkommen ungeschützt ist.

Grenzen des angemessen Machbaren gibt es immer. Wobei man die von mir beschriebene Lücke leicht durch Systemvollverschlüsselung negieren kann. Das obige kaum, oder? Abgesehen davon braucht es meines Wissens einen immensen technischen Aufwand, Datenreste in RAM zu rekonstruieren. Es ist wie bei realen Schlössern: Ein Dieb bekommt letztlich JEDES Schloss auf (oder kaputt). Trotzdem bringen teure Schlösser durchaus einen Vorteil.

Wenn jemand in Deiner Abwesenheit einen Hardware-Spion in Deinen Rechner einbaut, schützt Dich eh nichts.

Ich gebe ja zu, dass das nicht vollkommen sinnlos ist. Man erreicht aber die gleiche Sicherheit durch sinnvolles Rechtemanagement. (Benutzer darf nur in bst. verschl. Bereichen schreiben oder im RAM über /tmp; Systemdienste wie Suchcrawler haben kein Zugang zu /home usw) Das setzt vorraus, dass man sich mit dem Thema beschäftigt und nicht mal auf Verdacht mit Verschlüsselung um sich wirft, das ist aber genau mein Vorwurf. Es wird alles was bei 3 nicht auf dem Baum ist verschlüsselt, ohne Konzepte und Einstellungen zu hinterfragen. Deshalb auch mein vielleicht etwas unfaier Vergleich zu 'Personal Firewall', man schützt sich durch Programme um selbst nicht drüber nachdenken zu müssen. Führt dazu, dass Leute mit guten Anregungen die Sicherheit 'out of box' zu verbessern Unverständnis ernten, denn es ist ja eh "alles" verschlüsselt.