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@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
