LUKS2 (in zys-format invocation of the corresponding cryptsetup
version) uses Argon2i password-based key deriviation function and
automatically tunes the iteration count/memory cost to be under 2000
milliseconds.
Note that this is timed on the target's machine, and attacker's
machines can be more powerful than that. For example, I created a LUKS
volume on ThinkPad X200 (old hw, but still popular in Coreboot /
Libreboot circles), and a 4 years old Xeon workstation was able to
mount 8 bruteforce-luks passwords/sec against it. (Whereas, for a LUKS
volume generated on the same Xeon machine the passwords/second were
just 2.)
The keyspace of 10^16 recovery keys would mean ~39 610 109 CPU years,
so probably out of reach for current botnets. However, this estimate:
- does not take in account potential improvements in attacker's
capabilities. E.g. Argon2 GPU implementation exists
<https://gitlab.com/omos/argon2-gpu/> (but is yet to be incorporated
into something like hashcat); the author estimates the Nvidia
Tesla/Xeon speed-up to be around 4-6x.
- leaves little margin of error for compromised entropy. For example,
if someone saw first 4 digits of my recovery code, the remaining
keyspace would shrink by 10000x.
So while not threatening in any concrete way, I'd definitely love for
the default to be higher :-) For comparison, BitLocker recovery keys
are 48 decimal digits (not sure how much of it is pure key material
though).
There is, of course, also a balance of security and usability: can
users accurately write down a high-entropy string? Maybe one could get
inspiration from the cryptocurrency world where 12 words from BIP39
wordlist contain 128 bits of entropy (incl 4 bits of checksum), and
can be asked to be entered back (either in full or via random
spot-checks).
Hi all,
LUKS2 (in zys-format invocation of the corresponding cryptsetup
version) uses Argon2i password-based key deriviation function and
automatically tunes the iteration count/memory cost to be under 2000
milliseconds.
Note that this is timed on the target's machine, and attacker's
machines can be more powerful than that. For example, I created a LUKS
volume on ThinkPad X200 (old hw, but still popular in Coreboot /
Libreboot circles), and a 4 years old Xeon workstation was able to
mount 8 bruteforce-luks passwords/sec against it. (Whereas, for a LUKS
volume generated on the same Xeon machine the passwords/second were
just 2.)
The keyspace of 10^16 recovery keys would mean ~39 610 109 CPU years,
so probably out of reach for current botnets. However, this estimate:
- does not take in account potential improvements in attacker's /gitlab. com/omos/ argon2- gpu/> (but is yet to be incorporated
capabilities. E.g. Argon2 GPU implementation exists
<https:/
into something like hashcat); the author estimates the Nvidia
Tesla/Xeon speed-up to be around 4-6x.
- leaves little margin of error for compromised entropy. For example,
if someone saw first 4 digits of my recovery code, the remaining
keyspace would shrink by 10000x.
So while not threatening in any concrete way, I'd definitely love for
the default to be higher :-) For comparison, BitLocker recovery keys
are 48 decimal digits (not sure how much of it is pure key material
though).
There is, of course, also a balance of security and usability: can
users accurately write down a high-entropy string? Maybe one could get
inspiration from the cryptocurrency world where 12 words from BIP39
wordlist contain 128 bits of entropy (incl 4 bits of checksum), and
can be asked to be entered back (either in full or via random
spot-checks).