Wieviel Futter braucht geli?!

Rakor

Rakor

Administrator
Teammitglied
Servus zusammen!

Beim Lesen der unterschiedlichen Dokumente zu geli die man so findet stellt man schnell fest, dass die verwendeten Schlüsseldatei sich doch massiv unterscheiden. Das FreeBSD-Handbook legt beispielsweise eine Schlüsseldatei mit "lediglich" 64Byte an. In anderer Doku werden 128kB verwendet... Das ist nun schon ein gewisser Unterschied... ^^
Ich hätt nun mal gesagt 64Byte sind bissl wenig... Aber irgendwann wird's wohl auch für den Rechner etwas anstrengend.

Dann gibt's natürlich noch die Schlüssellänge die mal 128 und mal 256 ist... (ganz abgesehen von der Grundsatzdiskussion AES<->Blowfish...).

Also nun... Was jetzt?! :)

Was sind denn eure Vorschläge?
 
Eigentlich ist es ganz einfach: Erst einmal musst du wissen, dass GELI nicht direkt verschlüsselt. Wenn du "geli init" sagst, wird ein zufälliger Schlüssel erstellt, der mit dem von dir eingegeben Passwort und der Schlüsseldatei verschlüsselt und abgelegt. Wenn du dann "geli attach" sagst, wird dieser Schlüssel mit deinem Passwort und der Schlüsseldatei entschlüsselt, mit dem entschlüsselten Schlüssel dann die Nutzdaten entschlüsselt. (Ich hoffe, dass es nicht zu wirr war). Dadurch wird erreicht, dass du einfach Passwort und Schlüsseldatei ändern kannst, ohne alle Daten neu zu verschlüsseln. Auch kann es daher mehrere Kombinationen aus Passwort und Schlüsseldatei geben.

Also: Das Passwort und die Schlüsseldatei ergeben zusammen den Schlüssel für den eigentlichen Schlüssel zu den Nutzdaten. Wie lang das Passwort und die Schlüsseldatei sind, spielt dabei keine Rolle, da sie mit irgendeinem Verfahren in jedem Fall auf die richtige Länge gebracht werden. Grundsätzlich gilt aber "je länger, umso besser". Ich nehme für die Dateien meist 512 Byte, aber die 64 Byte aus dem Handbuch sollten es auch tun. Aus bitterer Erfahrung würde ich die Datei aber nicht binär speichern, stattdessen die Zufallsdaten per uuencode oder so in ASCII transformieren. Macht's einfacher, die Datei zu mailen und so.

Dann gibt's den Algorithmus selbst und die Algos noch in verschiedenen Geschmacksrichtungen. Grundsätzlich gilt: Hat ein Algorithmus verschiedene Schlüssellängen, macht ein längerer Schlüssel ihn theoretisch sicherer, aber auch langsamer. Ebenso gilt, dass bis heute keiner der von GELI unterstützend Algos gebrochen wurde, egal mit welcher Schlüssellänge. Zumindest weiß man davon öffentlich nichts. :) Daher ist mein Tipp immer "AES", da er einfach der mit Abstand schnellste der angebotenen Algos ist. Punkt. 128 Bit sollten ausreichen, ich nehme meist 256, da in der Praxis der Unterschied in Sachen Geschwindigkeit zu vernachlässigen ist, wenn die CPU denn genug Wumms oder einen Cryptobeschleuniger hat. XTS ist gegenüber CBC zu bevorzugen, da kaum langsamer aber aufgrund der puren Datenmenge angeblich sicherer als CBC.
 
Rakor schrieb:
Dann gibt's natürlich noch die Schlüssellänge die mal 128 und mal 256 ist... (ganz abgesehen von der Grundsatzdiskussion AES<->Blowfish...).
Zum Vergrößern anklicken....

FreeBSD's Security Officer Colin Percival hat mal eine Liste von Tips in Sachen Crypto zusammengestellt, weil er so oft danach gefragt wird. Hinsichtlich der Schlüssellänge von AES sagt er:
Use 256-bit AES keys.
Theoretically speaking, 128-bit AES keys should be enough for the forseeable future; but for most applications the increased cost of using 256-bit keys instead of 128-bit keys is insignificant, and the increased key length provides a margin of security in case a side channel attack leaks some but not all of the key bits.
Zum Vergrößern anklicken....
Das ist für mich ein guter Anhaltspunkt - wenn jemand wie Colin das empfiehlt.
 
Als Referenz:
Bei mir laeuft derzeit ein Raid-Z(1) mit 3x 1TB Platten und einem Intel Core2Duo 3.4Ghz.
Alle Platten sind mit Geli 256bit AES verschluesselt.

Ich kann vom Server (via samba ueber Gbit LAN) Full HD Filme kucken und beide cores sind laut top so bei 98% und 99% IDLE

Kann man denn irgendwie benchmarken, was geli so frisst bei zugriffen?
 
Use 256-bit AES keys.
Theoretically speaking, 128-bit AES keys should be enough for the forseeable future; but for most applications the increased cost of using 256-bit keys instead of 128-bit keys is insignificant, and the increased key length provides a margin of security in case a side channel attack leaks some but not all of the key bits.
Zum Vergrößern anklicken....

Das waere mal zu hinterfragen. Da gab es doch eine Schwachstelle im Algorithmus, welche die Komplexitaet bei 256-bit auf 118 herabsetzt oder war das implementierungsspezifisch/zu theoretisch um praktisch anwendbar zu sein?
 
AES birgt derzeit einen weiteren Vorteil gegenüber Blowfish: Moderne Intel-CPUs bringen ein AES Instruction Set mit, das vom aesni-Treiber angesprochen werden kann. Ist das Modul beim Anlegen einer GELI-Verschlüsselung aktiv, wird automatisch das Instruction Set genutzt (man kann aber nicht beliebig zwischen Hardware- und Softwareimplementierung springen).
 
Das man nicht springen kann, war ein (imo sehr gefährlicher) Bug und ist in dem kommenden 8.3 und 9.0 behoben. Ich habe das bittere Gefühl, dass er uns noch sehr viel Freude machen wird, da betroffene Personen ihren Pool neu verschlüsseln (d.h. Daten runter, GELI reinitialisieren, Daten wieder rauf) dürfen. Der PR dazu ist hier: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/155118
 
Ach, Yamagi, so schlimm kann der Bug ja nicht sein - die haben ja nur eine einzige Ziffer im Source-Code ausgetauscht:
Code: 
- .byte 0x66,0x0f,0x3a,0xdf,0xca,0x20
+ .byte 0x66,0x0f,0x3a,0xdf,0xca,0x40
:D
 
Yamagi schrieb:
Meines Wissens bezogen sich diese Angriffe auf eine verringerte Rundenzahl, sie sind also nur durchführbar, wenn das Chiffrat mit weniger als den normalerweise genutzten 14 Runden erstellt wurde.

EDIT: Die hier meine ich - http://www.schneier.com/blog/archives/2009/07/another_new_aes.html
Zum Vergrößern anklicken....

Es gibt mittlerweile einen "echten" Angriff auf AES, der nicht auf "Mitarbeit" der Implementierung (reduzierte Rundenzahl o. ä.) angewiesen ist: https://research.microsoft.com/en-us/projects/cryptanalysis/aes.aspx

Kurzfassung: Das Brechen eines Schlüssels mit dem Biclique-Angriff geht 4 Mal schneller als reiner Brute Force. Das heißt aber bei AES-256 lediglich, dass die Komplexität von maximal 2^256 auf 2^254 sinkt. Praktisch hat der Angriff daher keine Bedeutung - die schlechte Nachricht für AES ist aber, dass es möglich war, die Komplexität überhaupt zu reduzieren. Damit gilt der Algorithmus selbst als gebrochen.
 
Daemotron schrieb:
Kurzfassung: Das Brechen eines Schlüssels mit dem Biclique-Angriff geht 4 Mal schneller als reiner Brute Force. Das heißt aber bei AES-256 lediglich, dass die Komplexität von maximal 2^256 auf 2^254 sinkt. Praktisch hat der Angriff daher keine Bedeutung - die schlechte Nachricht für AES ist aber, dass es möglich war, die Komplexität überhaupt zu reduzieren. Damit gilt der Algorithmus selbst als gebrochen.
Zum Vergrößern anklicken....
Nein, tut er nicht. Ein Safe ist nicht aufgebrochen, wenn man einen Kratzer in die Tür gemacht hat.

Die Related-Key Attacken die AES-256 auf 2^119 reduzieren sind viel bedenklicher. Zumindest in dem Szenario wäre AES-128 sicherer als AES-256.
 
Allgemeiner Ratschlag ist also:
1. AES ist dennoch (derzeit) sicher und sollte verwendet werden (wegen der erwähnten Vorteile)
1.1 - jedoch lohnt sich 256 nicht, also einfach bei 128 bleiben
2. AES hat seine Zeit gehabt... Nimm lieber: VORSCHLAG_BITTE_HIER.
3. Ne is klar...
 
Ich bleibe bei 1. Selbst wenn du argumentierst, dass AES Kratzer im Lack hat, kann ich noch immer sagen, dass AES auch aufgrund seiner Verbreitung ganz vorn im Kugelhagel steht.
 
Ich kann derzeit auch nur AES empfehlen, wenn es um Einsatzgebiete wie GELI o. ä. geht. Wenn Daten über einen sehr langen Zeitraum geschützt werden müssen (z. B. 50 Jahre), würde ich eher zu Twofish tendieren, der aufgrund seines Aufbaus einen größeren Puffer gegen mögliche Kryptoanalysen hat als AES.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben