[Whonix-devel] [dm-crypt] Argon2id security margin estimate and LUKS2 usage

[Milan Broz]

Hi,

On 20/08/18 15:33, procmem wrote:
> Hi Milan, Whonix (privacy distro) maintainer here. We are researching
> the best password advice to give to our users and while diceware is a
> great improvement over the status quo, the recommendation by
> cryptographers in light of quantum computing is to choose pass phrases
> with a length equivalent to 256 bits because Grovers will halve the bit
> length. This requires phrases to be 20 words long for 256 bits which is
> excessive IMO and the reason we are looking at key-stretching for
> shorter ones instead.

As Arno said, QC is really not an issue here.

> * What is the time/sec margin added to a password with Argon2id's best
> parameters?

"Best" depends on the context and will change in time (there will be better
optimized implementations, some new problems appear).

The logic here is to provide as much protection to dictionary attacks
as possible, but without completely hurting user experience.
(If you are ok to wait 20minutes for unlocking - you can set it, but for
most of users it means unusable system, etc)

> * Have Argon's parameters been tweaked in the LUKS implementation, to
> account for the 2 public attacks? [0]

Partially yes:

- we use Argon 1.3 version (as implemented by authors)

- minimal iteration count (memory passes) is 4 (the first "attack")

- we cannot use minimal 10 (second "attack"), because on real systems
it would be incredibly slow.
You can use Argon2id though (combination of data dependent and independent
processing). I prefer Argon2i for key derivation, but opinions differ here.

- the reference values suggested in RFC draft are unusable in reality as well
(it could change with optimized implementation though)

(BTW RFC draft expired but Argon2 authors assured me that it is just because
of other priorities - it should be updated soon, I hope.)

> * Are more cryptanalytic attacks expected against it in the future or is
> it extremely unlikely for progress against to be made? (For example
> modern hashes like BLAKE2 or block ciphers like AES are pretty robust
> with no notable attacks for some time)

Always expect it to be broken in future and be prepared to reencrypt your data
and increase/change algorithms in future :-)

You can do both (offline) now with cryptsetup-reecrypt.

> * Can you please give an example of cryptsetup re-encrypt command that
> upgrades an existing LUKS1 system to one that uses Argon with its max
> settings?

I will always avoid describing something as "best" or "max" - it depends.

Cryptsetup set Argon2 internal limit to use maximal 1GB of memory and 4 threads,
but it is just safety margin to be able move device among various systems.

The time (iteration) count is limited only be 32bit integer, so if you wish,
you can set it very high. (And attacker the will just focus on different attack vector
like extracting key from active device or so :)

Keyslot upgrade can be done with the new luksConvertKey command
(you can do the same with cryptsetup-reecrypt if --keep-key option is used).

So, for your use case:

1) Backup your LUKS1 header (for recovery, if anything fails during conversion)

  # cryptsetup luksHeaderBackup --header-backup-file <backup_file> <device>

2) convert LUKS1 device to LUKS2, this will keep keyslot in current configuration,
just it updates metadata format.

  # cryptsetup convert --type luks2 <device>

3a) upgrade keyslot(s) to LUKS2 default and benchmarked parameters
    (it upgrades keyslot with provided password)

  # cryptsetup luksConvertKey <device>

OR

3b) upgrade to explicitly defined parameters (benchmark is skipped so it allows you
to setup very high iteration time or it allows to setup it for different system),
like example here:

  # cryptsetup luksConvertKey --key-slot 1 --pbkdf argon2id --pbkdf-force-iterations 50 --pbkdf-memory 1048576 --pbkdf-parallel 4 <device>

NOTE: cryptsetup will always decrease parameters if they are not possible to use
(more than half of physical memory or not enough cpu cores) or if the exceeds
internal limit (see cryptsetup --help, for now max memory limit is the same as default)

I think we need to change how is user informed here about parameter downgrade, it is only
visible in --debug mode, fro example:
  # Only 2 active CPUs detected, PBKDF threads decreased from 4 to 2.
  # Not enough physical memory detected, PBKDF max memory decreased from 1048576kB to 249392kB.

Milan