Comment 7 for bug 1928860

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
  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).