staging.inyokaproject.org

Hi,

ich denke, den Artikel kann man fürs erste so lassen. Könnte das bitte mal jemand kontrollieren und gegebenenfalls verschieben?

Mit gdecrypt bin ich mir nicht ganz sicher, ich glaube seit Hardy können Luks-Devices auch so schon grafisch ein- bzw. ausgehängt werden. Das werde ich noch mit einer Live kontrollieren, wirklich schaden täte es aber nicht.

Spezifischere Sachen wie mkfs und mount halte ich für unpassend, wäre aber froh über relevante Wikilinks. Einer wie man ein Device formatiert und einer zum "mounten". Ansonsten wird noch in den entsprechenden Systemverschlüsselungsartikeln darauf eingegangen, denke ich.

Verbesserungen und Hinweise sind natürlich stets willkommen.

Gruß unggnu

Habe mal kleine technische Ergänzungen und Dapper vorgenommen.

luksRemoveKey ist nicht veraltet, das ist nur LuksDelKey. Remove entfernt ein Passwort und Killslot einen spezifischen Slot, deswegen ist das im Augenblick falsch rum. Zumindest laut manpage.

Gruß, unggnu

Ah, der Kalk beginnt sich zu setzen.

Ist verbessert.

Ja, sieht gut aus. Ich habe noch zwei Kleinigkeiten geändert. Die GUI-Passage und den Geschwindigkeitshinweis.

Das Problem ist, das ich und kaum einer den Wechsel von 256 auf 128 Bit bei XTS einschätzen kann. Bei AES sollte es nicht wirklich ein Problem sein, auch wenn wesentlich weniger Runden durchgeführt werden, aber zu XTS habe ich nicht wirklich was gefunden. Der Hinweis mit der Systempartition ist ja regelrecht eine Einladung, deswegen habe ich das durch langsamere System ersetzt.

Ursprünglich hatte ich einen Hinweis bezüglich der Sicherheit, die bei der Änderung nicht abgeschätzt werden könnte, aber das wäre auch ein wenig Overkill.

Was meinst/t Du/Ihr?

Gruß unggnu

unggnu schrieb:

Das Problem ist, das ich und kaum einer den Wechsel von 256 auf 128 Bit bei XTS einschätzen kann. Bei AES sollte es nicht wirklich ein Problem sein, auch wenn wesentlich weniger Runden durchgeführt werden, aber zu XTS habe ich nicht wirklich was gefunden.

Es ist eine Methode zur Verknüpfung der Blöcke und beinflusst die Verschlüsselung selbst nicht. XTS ist sicher gegen Wasserzeichenangriffe und AES ist sicher gegen Entschlüsselung, egal ob auf 128 oder 256 bit.

unggnu schrieb:

Der Hinweis mit der Systempartition ist ja regelrecht eine Einladung, deswegen habe ich das durch langsamere System ersetzt.

Genau das war beabsichtigt und das sollte auch wieder rein, weil in den anderen Anleitungen nur auf den Artikel verwiesen werden wird. Die halbe Schlüssellänge sorgt für einen deutlich verbesserten Datendurchsatz (Ein Datendurchsatz schreibend von etwa 25MB/s im Vergleich zu 18MB/s).

Systempartitionen enthalten kurzfristig wertvolle Daten, Datenpartionen langfristig wertvolle. Insofern ist es wichtiger, bei Datenpartionen eine gewisse Sicherheit in der Verschlüsselung einzuplanen.

Beim Lesen war es bei mir knapp 20% schneller. Die Frage ist nur, warum XTS dann auch 256 Bit anbietet, wenn 128 reichen. Es gibt bei XTS ein Limit von einem Terabyte Daten oder so, ab dann würde es unsicherer. Vielleicht tritt das ja bei den 128 früher ein.

Ansonsten kann das mit der Systemverschlüsselung meinetwegen geändert werden.

Vielleicht wäre es mit 384 ja genauso viel schneller, wenn cryptsetup 128 an AES verteilt und die 256 and XTS, ich weiß aber nicht wie das aufgeteilt wird.

Gruß, unggnu

unggnu schrieb:

Die Frage ist nur, warum XTS dann auch 256 Bit anbietet, wenn 128 reichen.

Aus demselben 'Grund', warum auch AES 256 Bit anbietet, wenn momentan 128 ausreichen: Eine Sicherheitsreserve.

Dass bei IEEE P1619 XTS nur symmetrische Schlüssellängen zum Einsatz kommen ist eine Designentscheidung gewesen. Denn längere Schlüssel verbrauchen immer mehr Rechenzeit, aber für Sicherheitsbetrachtungen ist eben quasi das schwächste Glied entscheidend - also gibt es keinen Grund, nur halb zu sparen.

PS: 384 ist 192+192

Da gibt es aber schon einen Unterschied. Soweit ich weiß gibt es zwischen Twofish 128 und 256 fast keine Geschwindigkeitsdifferenz, weil der Algorithmus quasi gleich abläuft. AES hingegen verwendet weniger Runden bei 128 Bit, woher der Geschwindigkeitsvorteil kommt. Das kritisieren einige Kryptoexperten, da AES sonst relativ simpel ist, aber ich kann das nicht wirklich beurteilen.

Das 128 Bit Schlüssel in nächster Zeit nicht knackbar sind sollte außer Frage stehen.

Wenn Du Dich mit XTS auskennst und ein 128 Bit Verwaltungsschlüssel keinen Einfluss auf die ein Terabyte-Grenze hat, habe ich nichts gegen eine Änderung.

Gruß, unggnu

Irgendwie bin ich etwas skeptisch, was genau diese Terrabyte-Grenze bei XTS genau sein soll.

Der Wikipedia-Eintrag ist AFAIS eine 1:1-Kopie aus einem Debian-Bugreport zu dem Thema 'Warum funktioniert 128 nicht' (Weil es 64+64 wäre...) und beruft sich genauso wie derselbige auf den Draft der eben nicht mehr online ist.

Also ich persönlich habe ein sicheres Systempartitionspasswort und deshalb Gdm auf autlogin gestellt. Für mein e-Mail-Programm muss ich dann zwar noch ein Passwort für den Schlüsselbund eingeben, aber das muss nicht so sicher/lang sein. Außerdem könnte man den Schlüsselbund ja auch unverschlüsselt speichern. Dann käme man mit einem Passwort aus, abgesehen von den root-Rechten.

Ich denke die Konstruktion sollte immer noch praktikabel sein und das ist in dem Fall für mich gegeben.

Gruß, unggnu

Wie ich für den allgemeinen Verschlüsselungsartikel vorgeschlagen habe: Nur die System-Partition in die crypttab, der Rest wird von pam-mount mit dem Nutzerpasswort gemacht.

Das wären wieder zwei Passwörter, Boot und Login. Ganz abgesehen davon, das es der Hammer wäre jedes mal für sudo/gksu ein 20 stelliges Passwort einzugeben.

Aber vielleicht könnte man mal das Init-Script im initramfs anpassen, dass es das selbe Passwort für alle cryptab-Partitionen verwendet.

Gruß, unggnu

unggnu schrieb:

Das wären wieder zwei Passwörter, Boot und Login.

Wären es sonst doch auch?

unggnu schrieb:

Ganz abgesehen davon, das es der Hammer wäre jedes mal für sudo/gksu ein 20 stelliges Passwort einzugeben.

Das geht prima. 😛

Also ich persönlich habe ein sicheres Systempartitionspasswort und deshalb Gdm auf autlogin gestellt. Für mein e-Mail-Programm muss ich dann zwar noch ein Passwort für den Schlüsselbund eingeben, aber das muss nicht so sicher/lang sein. Außerdem könnte man den Schlüsselbund ja auch unverschlüsselt speichern. Dann käme man mit einem Passwort aus, abgesehen von den root-Rechten.

Ich denke die Konstruktion sollte immer noch praktikabel sein und das ist in dem Fall für mich gegeben.

Gruß, unggnu