ubuntuusers.de

LUKS: --iter-time hat keine Auswirkung auf Anzahl der Iterationen

Status: Gelöst | Ubuntu-Version: Kubuntu 19.10 (Eoan Ermine)
Antworten |

guy.brush

Anmeldungsdatum:
13. Februar 2011

Beiträge: 216

Wohnort: Earth

Hallo,

ich bin gerade dabei, einen Laptop mittels LUKS + LVM nach System verschlüsseln zu verschlüsseln. Da der Laptop ca. 10 Jahre alt ist, wollte ich nachgucken, wie viele Iterationen er durchführt und evtl. die --iter-time höher setzen.

Ich verwende

sudo cryptsetup luksFormat --cipher=serpent-xts-plain64 --key-size=512 --hash=sha512 --iter-time=X --verify-passphrase

Egal, welchen Wert ich für --iter-time verwende, ob z.B. 2000, 5000, 10000 oder 30000, wenn ich mir mit sudo cryptsetup luksDump /dev/sda2 den Header anschaue, steht dort unter

Tokens:
Digests:
  0: pbkdf2
       Hash: sha512
       Iterations: Y

für Y immer ein ähnlicher Wert. Die Wartezeit nach dem Eingeben des Passworts ist allerdings durchaus die von mir angegebene Zeit (nicht nachgemessen, aber wird zumindest länger 😉).

1) Warum ist das so? Bug or feature?

2) Wie bekomme ich die gewünschte Anzahl an Iterationen denn hin?

3) Wie viele Iterationen sollte es denn sein, um sicher genug zu sein? (Dazu konnte ich bisher nichts herausfinden.)

4) Zusatzfrage: Ist serpent bei LUKS mind. genau so sicher wie aes? (Ein sudo cryptsetup benchmark brachte für serpent merklich bessere Ergebnisse als aes.)

Liebe Grüße

guy.brush

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9739

Wohnort: Münster

guy.brush schrieb:

[…] 1) Warum ist das so? Bug or feature?

Feature. Die Option --iter-time (oder auch -i) hat gar nichts mit der Anzahl der Iterationen für den kryptographischen Prozess zu tun, sondern hierbei handelt es sich um eine Wartezeit nach der Passwort-Eingabe. Während der Wartezeit wird nichts getan, außer zu warten. Es ist eine Maßnahme gegen Wörterbuchattacken. (--iter-time sollte vielleicht treffender --idle-time heißen.)

2) Wie bekomme ich die gewünschte Anzahl an Iterationen denn hin?

Welche Anzahl wünschst Du Dir denn und warum willst Du nicht die Standardeinstellungen von LUKS verwenden?

3) Wie viele Iterationen sollte es denn sein, um sicher genug zu sein? (Dazu konnte ich bisher nichts herausfinden.)

Das steht in der Manpage unter "Notes on Password Processing for Luks": "The default setting of one second is sufficient for good security."

4) Zusatzfrage: Ist serpent bei LUKS mind. genau so sicher wie aes?

Das widerspricht den Forenregeln!

Die Algorithmen Serpent und Rijndael (der sich jetzt AES nennen darf) sowie drei weitere waren Finalisten im Wettbewerb bzw. Auswahlverfahren zum "Advanced Encryption Standard". Rijndael hat gewonnen. Das spricht keinesfalls gegen die kryptographische Qualität von Serpent, welche im Wettbewerb sogar besser als Rijndael angesehen wurde, aber:

  1. Implementierungen in Hardware von Serpent sind schneller als solche von Rijndael, Rijndael ist aber schnell genug.

  2. Implementierungen in Software von Serpent sind erheblich langsamer als solche von Rijndael, Rijndael ist schnell genug, Serpent jedoch nicht.

Das zweite Ergebnis bedeutete den Sieg von Rijndael (= jetzt AES) über Serpent.

(Ein sudo cryptsetup benchmark brachte für serpent merklich bessere Ergebnisse als aes.)

Diese Beobachtung bedeutet: Entweder benutzt Du Hardware für die Kryptographie oder Du vergleichst die beiden Algorithmen unter unfairen Bedingungen, weil die Parameter nicht identisch eingestellt sind.

guy.brush

(Themenstarter)

Anmeldungsdatum:
13. Februar 2011

Beiträge: 216

Wohnort: Earth

Feature. Die Option --iter-time (oder auch -i) hat gar nichts mit der Anzahl der Iterationen für den kryptographischen Prozess zu tun, sondern hierbei handelt es sich um eine Wartezeit nach der Passwort-Eingabe. Während der Wartezeit wird nichts getan, außer zu warten. Es ist eine Maßnahme gegen Wörterbuchattacken. (--iter-time sollte vielleicht treffender --idle-time heißen.)

Hm... Hast du dafür eine Quelle? Es widerspricht zumindest dem, wie ich die Sache verstehe:

Unter 2.1 und dort 4.

Arch Wiki

Hier unter "Stretching - PBKDF2 kostet Zeit und Rechenpower"

Aus der Manpage zu cryptsetup:

       Passphrase  processing:  Whenever  a  passphrase  is added to a LUKS header (luksAddKey, luksFormat), the user may specify how much the time the passphrase processing
       should consume. The time is used to determine the iteration count for PBKDF2 and higher times will offer better protection for low-entropy passphrases, but open  will
       take longer to complete. For passphrases that have entropy higher than the used key length, higher iteration times will not increase security.

       The  default setting of one or two seconds is sufficient for most practical cases. The only exception is a low-entropy passphrase used on a device with a slow CPU, as
       this will result in a low iteration count. On a slow device, it may be advisable to increase the iteration time using the --iter-time option  in  order  to  obtain  a
       higher iteration count. This does slow down all later luksOpen operations accordingly.

cryptsetup --help liefert unter anderem:

Default compiled-in metadata format is LUKS2 (for luksFormat action).

Default compiled-in key and passphrase parameters:
        Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF for LUKS1: pbkdf2, iteration time: 2000 (ms)
Default PBKDF for LUKS2: argon2i
        Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4

Welche Anzahl wünschst Du Dir denn und warum willst Du nicht die Standardeinstellungen von LUKS verwenden?

Ich dachte an eine Zahl > 1 Mio. Im Header steht aber etwas von < 100k. Beim Benchmark sieht es ähnlich aus wie hier unter "Stretching - PBKDF2 kostet Zeit und Rechenpower", lediglich die Werte sind etwas niedriger, weil langsamere CPU.

Der Grund ist, dass es heißt, bei langsameren CPUs könnte man den Wert etwas erhöhen. Immerhin ist der Laptop ca. 10 Jahre alt. Siehe oben in den Links und der Manpage, aber auch z.B. hier unter 5.13.

Dabei ist mir halt aufgefallen, dass die Anzahl der Iterationen sich nicht nennenswert verändert, aber genau das will man ja erreichen.

Das steht in der Manpage unter "Notes on Password Processing for Luks": "The default setting of one second is sufficient for good security."

Bei mir steht das etwas anderes (siehe oben). Afaik wurde die Zeit irgendwann einmal auf 2 Sekunden angehoben. Hast du vielleicht eine ältere Version?

Das widerspricht den Forenregeln!

Ok, Entschuldigung!

Diese Beobachtung bedeutet: Entweder benutzt Du Hardware für die Kryptographie oder Du vergleichst die beiden Algorithmen unter unfairen Bedingungen, weil die Parameter nicht identisch eingestellt sind.

Es ist ein Lenovo Thinkpad, zumindest nie gekauft in Hinblick auf Krypto-Hardware. Der Benchmark wird von cryptsetup ja mitgeliefert und ist daher hoffentlich fair. Da auf dem Laptop gerade kein OS installiert ist, konnte ich den Benchmark nur von einem Live-USB-Stick-System aus testen.

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9739

Wohnort: Münster

guy.brush schrieb: […]

Aus der Manpage zu cryptsetup:

       Passphrase  processing:  Whenever  a  passphrase  is added to a LUKS header (luksAddKey, luksFormat), the user may specify how much the time the passphrase processing
       should consume. The time is used to determine the iteration count for PBKDF2 and higher times will offer better protection for low-entropy passphrases, but open  will
       take longer to complete. For passphrases that have entropy higher than the used key length, higher iteration times will not increase security.

[…]

Das ist der wichtige Satz. Benutze ein gutes Passwort (Sollte man immer tun, wenn man Vertraulichkeit wertschätzt!) und verwende für die Wartezeit den Standardwert von 1 oder 2 Sekunden anstatt ein schlechtes Passwort durch den Reißwolf zu würgen!

[…] Der Grund ist, dass es heißt, bei langsameren CPUs könnte man den Wert etwas erhöhen.

Schlangenöl ersetzt kein gutes Passwort!

guy.brush

(Themenstarter)

Anmeldungsdatum:
13. Februar 2011

Beiträge: 216

Wohnort: Earth

Du meinst, ein Passwort mit mehr als 256 / 8 = 32 Zeichen? (Bestehend aus den 95 druckbaren Zeichen aus den ersten 128 Zeichen der ASCII Tabelle, nach hier unter 1.2.)

Es geht mir aber mehr darum, dass das mehrfache Hashen/Iterieren eben bei einem absichtlich oder unabsichtlich schlechten oder nicht-optimalen Passwort die Sicherheit erhöht. Und wenn ältere oder langsamere CPUs hier etwas länger brauchen, dann setze ich den Wert eben entsprechen höher. Warum das Sicherheitsnetz nicht verwenden, wenn es schon eins gibt?

Der springende Punkt ist aber eben: Obwohl --iter-time die Anzahl der Iterationen verändern sollte, tut er das bei mir nicht. Oder ich interpretiere den LUKS Header falsch. Oder verstehe etwas anderes nicht richtig. Zudem sind die Iterationen eben < 100k, was meinem bisherigen Verständnis entsprechend eben deutlich zu wenig sind.

Und das möchte ich eben verstehen und lösen. Für den Fall, dass die Iterationen tatsächlich deutlich höher sein sollten, wäre es evtl. nicht sicher genug.

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9739

Wohnort: Münster

guy.brush schrieb:

Du meinst, ein Passwort mit mehr als 256 / 8 = 32 Zeichen? (Bestehend aus den 95 druckbaren Zeichen aus den ersten 128 Zeichen der ASCII Tabelle

Serpent wie Rijndael benutzt Schlüssel der Länge 128, 192 oder 256 Bit, die aus einem Passwort (auch: Passphrase) abgeleitet werden. Durch die Ableitung selbst wird zwar das Passwort verwürfelt, es entsteht aber kein Zufall. Das ursprüngliche Passwort wird also durch noch so viele Runden nicht besser. Das Verwürfeln kostet nur Zeit und das ist der erwünschte Effekt gegen Wörterbuchattacken.

95 Möglichkeiten entsprechen einer Informationsmenge von 6-7 Bit, 32 Zeichen davon entsprechen also 192-224 Bit. Für eine Verschlüsselung mit 128-Bit-Schlüssel wäre also ein solches Passwort gut, bei einem 192-Bit-Schlüssel gerade ausreichend und für einen 256-Bit-Schlüssel eindeutig zu kurz. Ein zu kurzer Schlüssel bedeutet, dass die Leistungsfähigkeit des Algorithmus nicht ausgenutzt wird.

Für einen guten 256-Bit-Schlüssel benötigst Du bei 95 Möglichkeiten pro Byte mindestens 40 Zeichen. Jede praktikable Passphrase ist also im Grunde unzureichend und jede ausreichende Passphrase ist unpraktikabel.

guy.brush

(Themenstarter)

Anmeldungsdatum:
13. Februar 2011

Beiträge: 216

Wohnort: Earth

95 Möglichkeiten entsprechen einer Informationsmenge von 6-7 Bit

Das verstehe ich gerade nicht. Könntest du mir das evtl. kurz erklären? ☺

Jede praktikable Passphrase ist also im Grunde unzureichend und jede ausreichende Passphrase ist unpraktikabel.

Was würdest du demnach vorschlagen?

Bzgl. des ursprünglichen Problems habe ich, vermutlich, die Lösung gefunden. Muss aber noch einmal was nachlesen und testen und melde mich dann dazu.

guy.brush

(Themenstarter)

Anmeldungsdatum:
13. Februar 2011

Beiträge: 216

Wohnort: Earth

So, ein paar neue Erkenntnisse:

Der Auszug aus dem LUKS Header (siehe 1. Post) scheint nichts mit der Passphrase zu tun zu haben. Oder ist zumindest unabhängig von den Werten, die man eingibt. Falls jemand weiß, worauf sich das bezieht, wäre ich daran interessiert. (Auch wenn es nicht ganz so wichtig ist.)

Dann habe ich den Fehler gemacht, zu glauben, bei Argon2i würde es sich um eine simple Hashfunktion handeln. Auch dachte ich, dass ich mittels --hash sha512 eben sha512 als Parameter an PBKDF2 weiterreiche. Aber Argon2i ersetzt PBKDF2 und wird in LUKS2 auch standardmäßig verwendet.

Der LUKS Header ist hierbei etwas verwirrend, weil er etwas ausgibt wie pbkdf: argon2i. Das klang für mich eben danach, dass die vermeintlich simple Hashfunktion argon2i im PBKDF2-Verfahren verwendet wird. Allerdings legt der Befehl --pbkdf=X fest, was für ein Verfahren genommen wird. Möglich Werte sind pbkdf2, argon2i und argon2id.

Bei Argon2i sind allerdings nicht nur die Iterationen wichtig, sondern auch der verwendete Speicher und der Grad der Parallelität (siehe Wikipedia: Argon2). Im LUKS2-Header sind dies wohl time cost, memory, threads. Die Anzahl der Iterationen sind bei Argon2i deutlich weniger als bei PBKDF2.

Das wichtige dabei: --iter-time=X beeinflusst das Ganze und man kann mit mehr höheren Werten hier sehen, wie die 3 erwähnten Werte größer werden. Allerdings brauchten eingestellte 10 sek in Realität knapp 20 sek!

Setze ich --pbkdf=pbkdf2, so erscheinen auch die anfangs gesuchten Iterationen im LUKS-Header, die ebenfalls durch --iter-time=X beeinflusst werden.

Da zumindest die Hauptfrage aus diesem Thema geklärt ist, setze ich das Thema einmal auf gelöst. Für 2 Folgefragen eröffne ich neue Themen.

Antworten |