Re: [dm-crypt] Argon2id security margin estimate and LUKS2 usage

[Arno Wagner <arno@wagner.name>]

Hi procmem,

you may want to add a link to the FAQ here:

https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions

It has a lot of basic and advanced stuff people may want to know,
even if it is not updated for LUKS2 yet. 

Regards,
Arno

On Mon, Sep 03, 2018 at 16:35:00 CEST, procmem wrote:
> 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
> > 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier