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. 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. 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). 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. >> 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!) 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). Anyway, thanks for your comments! Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
