On Mon, Dec 11, 2017 at 15:04:26 CET, Milan Broz wrote: > On 12/11/2017 01:12 PM, Geo Kozey wrote: > >> 1) aes-xts-plain64 with hmac-sha256 or hmac-sha512 as the authentication tag. > >> (Common FDE mode + independent authentication tag. Authentication key > >> for HMAC is independently generated. This mode is very slow.) > >> $ cryptsetup luksFormat --type luks2 <device> --cipher aes-xts-plain64 --integrity hmac-sha256 > >> > > > > I see this part changed from last RC release. So no more random IV for aes-xts? > > Is it still possible to disable integrity with "--integrity none" option to have > > equivalent of LUKS1 ciphers used along with other LUKS2 features like argon2? > > Yes, this part need explanation... > > First, integrity protection is not mandatory, default is still > aes-xts-plain64 (length preserving encryption without integrity > protection. (And should remain this way.) > > The "--integrity none" switch is used only if you need to add some > metadata per sector for example for random IV) but without any integrity > mode. Makes sense to me. You may want the metadata for other reasons but not the random IV. > For the XTS and random IV (non-authenticated encryption) change: > The reason I removed this example is that I did quite serious mistake here. > While replacing IV with random helps, it also removes dependence on sector > position - so with aes-xts-random attacker can move ciphertext+storedIV to > another position and it will be decrypted properly. Hahaha, nice ;-) A classic. Happens to the best of us. > We need some random+plain64 IV variant to achieve this - it is easy to > implement, I will probably add it to dm-crypt later (at least for modes > that takes 128bit IVs). You should be careful that you do not get some birthday paradox here were it effectively only takes 32 bits of guessing to change the sector number. Use sector number extended to 128 bit (zeros) and 128 bit random and then just append them and put them through SHA256? That should give a guessing effort of 2^64 and may often not be possible at all if the 64 bit zeros in the sectior number input part are enforced. Well, that part needs to be done carefully in any case. > TL;DR; aes-xts-random should not be used for disk encryption. > (You can configure it but it is not secure). > > For authenticated modes it is not a problem, because sector is part of > additional authenticated data, so moving sector will cause integrity > failure. Obviously so, if implemented righ. And pretty clear how to do it. Maybe the easiest way is to drop the standalone random IV altogether and use authenticated mode for "random IV" as well. > >> For now, default LUKS2 PBKDF algorithm is Argon2i (data independent > >> variant) with memory cost set to 128MB, time to 800ms and parallel > >> thread according to available CPU cores but no more than 4. > > > > Is above actual after: > > https://gitlab.com/cryptsetup/cryptsetup/commit/3c2f92a7afc2ae4c99fa937f1b189bc1375374ad > > Ah, yes. Again, my fault to forgot to mention this. > > Default for Argon2i is now 1GB of memory and 2 seconds iteration time (can > be changed during compilation time or later on commandline). The memory > is trimmed to 1/2 of detected physical memory (with minimum 128MB). > (Otherwise OOM killer hits cryptsetup.) > > If you read Argon2 RFC draft, > > https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/ you can see this > recommendation: > > "Key derivation for hard-drive encryption, that takes 3 seconds on > a 2 GHz CPU using 2 cores - Argon2id with 4 lanes and 6 GiB of RAM." > > This memory amount is insane default for most of systems. Also I disagree > with Argon2id as a default (but again, you can change it). So final > parameter set was decision after some test runs on real systems. TBH we > need real users to validate that it works nicely. (Note that memory/time > influences each other. RFC recommendation above is just impossible to > achieve on slower systems - even if you have a lot of RAM.) > > So I just prefer that we decrease limit later (if it is too high) to > saying that the parameters were inadequate. > > (And also I welcome any security audit here!) I think you choice is a good first selection. Whether it is 6GB and 3 seconds or 1GB and 2 seconds is, in the end, likely pretty irrelevant. Even 128MB should be non-critical. I would however advise to go down to 1 second to be in line with classic LUKS and prevent an effect where people avoid LUKS2 "because it is slower". Again, this will make very little difference. Overall, this is just a factor of around 70 and that is well within the variation technology development can have in the next few decades. Things need to have way more security margin than that even with the lowest settings (128MB + 1 second) or the whole design has a problem. Do you have some attack-effort estimates for different parameter sets? > Also note, that Argon2 benchmark, as it is now implemented, tries to > prefer running time to amount of memory - so if your system is slow, it > will decrease amount of memory here. > > Also, I strongly recommend that --enable-libargon2 option is used and > system-wide and optimized Argon2 implementation is used (internal bundled > version is reference code that is compilable everywhere but it is slow.) > Not all distros have it though. > > I hope I will write some more info about some LUKS2 and integrity > protection aspects (and there should be FOSDEM talk). Looking forward to that! Regards, Arno -- 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 http://www.saout.de/mailman/listinfo/dm-crypt
