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

[procmem]

Thanks for your great reply Milan and your work on LUKS. Will definitely
document this info on our wiki.

Cheers.


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
>