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@xxxxxxxx > https://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
