On 12/12/2017 04:41 AM, Arno Wagner wrote: > >> 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. Well, I simplified ti much but the case is: With AES-XTS-plain64 we have 64bit sector sector number as IV. The IV is padded with zeroes to 128bit (AES block size). So the idea is instead of zero padding add random padding, so we have 64bit per sector of random bits. >From the mathematical point of view attacker can computationally get collisison (yes, here the birthday paradox applies) but the mode is still much more safer - not completely IND-CPA but attacker will have to write at least 2^32 sector to the same place to get collision. >From the security point, here we just randomized 64bits that were zeros before, so the mode should not be less secure than aes-xts-plain64. Not sure it is worth it though :) Maybe better idea is to reuse ESSIV, and just feed it not only with sector but also with random IV. (Here it is equivalent to your SHA256 idea.) Anyway, all this was just side effect of availability of per-sector metadata, to show that even AES-XTS can be made IND-CPA secure with additional metadata (in plain words - that even the same data written to the same place will produce randomly looking ciphertext, and that the granularity of XTS mode change disappears, so the major complaints to XTS mode are eliminated here). But, ny main focus is to show that we *need* authenticated encryption even on this layer. Maybe not today, but definitely in future. The above is just interesting side step to this goal. ... >> 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. With 1 second and the current Argon2 code we are not even able to get minimal number of iterations on common systems (set it to 4 for now). So my plan is to wait for some time distros get optimized Argon2 implementation (that will be definitely faster - like 2-4 times thanks to use of SSE etc). And then revalidate this decision. Maybe I forgot to say - you can use PBKDF2 the same way in LUKS2 (and in fact, during conversion from LUKS1 this happens). > 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? I do not have numbers that I can present here - and TBH current state is that seems many people in academy are waiting for something better than Argon2, that is not coming anytime soon. All I can say now is that PBKDF2 is already bad and must be replaced with something better. And Argon2 is winner of password hashing competition, so is a natural candidate here. This is the split what is probably clearly visible - LUKS1 as a conservative option, but with risk of algorithms that nears to the end of its "secure life" and new concepts in LUKS2, with risk that we are one of the first users of them and something could go wrong. So the major design goal was to have possibility to switch easily to something different. And nobody had any real-world numbers that we can trust. (I tried to measure KDF for disk encryption, there is some crappy paper on it from me, but these numbers are not usable - it was like a magic eye what we can really expect here.) Ok, maybe some request here: If there is anyone from "academy" who things that can contribute (and publish) to independent analysis of FDE concepts background (mainly to the proof of security of some authenticated modes in FDE context and also regarding the memory-hard KDF, please contact me (please use my university mail). Thanks, Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
