On 17/08/18 15:26, Christoph Anton Mitterer wrote: > On Fri, 2018-08-17 at 14:23 +0200, Milan Broz wrote: >>> 1) Is there any current known bug in LUKS2 / AEAD of cryptsetup/dm- >>> crypt/dm-integrity? >> >> There are many bugs, but most them are implementation things that >> are not related to security. > When you say "most" are there some related to security? > Or would you (for security) rather suggest that I make one layer with > luks2+AEAD... and one with traditional luks1 without AEAD (especially > for the triple encryption of plain files, I've mentioned below)? LUKS2 is new code, with new bugs. FDE AEAD started as an academic experiment and I believe we have to push authenticated encryption forward (in general), so it is now part of upstream LUKS. Some bugs can have security impact. That's all I meant here. For the stacking layers and different cipher: Well, I personally do not believe it is worth to use chained ciphers or multiple layer of encryption, but on the other hand, I do not want block it. (One of the item on my TODO list is to add new VeraCrypt chains to cryptsetup.) >> LUKS2 as pon-disk format should be ok but AEAD is still something I >> would >> better see to be analysed by some other people. > Is anything planned here? Guess there are quite some people with high > knowledge of crypto in the kernel community... maybe Ted Ts'o. > > >> I hope so. It is more fragile though - if the journaling in dm- >> integrity >> is broken, we have no proper tool for recovery yet. > Well at least for my long-term-backup (ab)use of cryptsetup, that > fragility wouldn't be a problem anyway. If your use case is a long-term backup only, an authenticated encryption is good to detect silent errors. Better would be to have something that even repairs it (forward error correction). >>> 3) --sector-size >>> Does this also change the crypto block size? I vaguely think to >>> remember that some loooooong time ago when XTS was introduced, >>> someone >>> said it wouldn't be safe to use with block sizes >512? >>> Or does this just set how many 512bit crypto blocks are >>> written/read at >>> once to the underlying device? >> >> It is mainly about the crypto block. > > So --setctor-size sets the crypto-block size, if I understand you > correctly. Yes. And it implies that dm-crypt device must present this block as an atomic unit (we abuse hw-sector size). Check lsblk -t output. >> Limitation for XTS block is I think >> at most 2^20 AES blocks, we have maximum 4096 bytes sector size >> (because of >> the 4k page size), so this is not a problem. > Not sure about this,... > The FAQ in section 5.16 already mentions: > "There is a potential security issue with XTS mode and large > blocks. LUKS and dm-crypt always use 512B blocks and the issue does > not apply." > But it doesn't tell when the issues start... > > I found: > > https://crypto.stackexchange.com/questions/35383/how-many-blocks-can-securely-be-encrypted-with-xts > But that isn't fully clear to me either... > could be that the recommendation says the block size should be no more > than 128*2^20 bits... which would bei fine for us... but I don't find > that at all in the NIST specs... neither whether it's about the crypto > block size or the total size (disk). I am trying to avoid doing any mathematical analysis (I know that I am not good in it :-) But the XTS mode seems to be nice target of so many confusions... So the extremely pragmatic engineering view: - Read NIST 800-38E and IEEE 1619-2007 - this is all the source of confusion, it is unclear in some aspects. Also see https://en.wikipedia.org/wiki/Disk_encryption_theory#XTS Two limits: 1) limit to XTS block size (strictly set in NIST 800-38E) to 2^20 AES blocks. No poblem with dmcrypt, maximum block size is 4096 bytes (256 AES blocks, 2^8). 2) There is a limit in IEEE 1619, discussed in link you provided, to number of encrypted blocks with one encryption key. (And there a limit for AES in any mode in general.) I think the IEEE standard is just confusing. Better read Rogaway's analysis in chapter 6 from Evaluation of Some Blockcipher Modes of Operation, web.cs.ucdavis.edu/~rogaway/papers/modes.pdf Anyway, many FDE systems use XTS mode today. And note, that with AEAD extension we should use random IV. It not only causes that XTS mode start to behave partially as a wide-block mode (there is no longer AES-block granularity, all the sector changes) but also I think the analysis need to bee tweaked, because we no longer use consecutive IV, that is fixed for the particular sector. (On the other hand, you must not use random IV without authentication, because then relocation of ciphertext sector is possible. We depend on authentication of not only data but also IV and sector number.) ... >>> 7) Are we going to see SHA3 anytime soon in dm-crypt/cryptsetup? >>> E.g. >>> for HMAC in integritry... or for --hash? >> >> Kernel should support whatever hash/hmac is there. I perhaps limited >> this with >> fixed list of algorithms in userspace. (SHA3 has strange name like >> sha3-256, I think we >> had to fix the code to support it). >> >> But it will be terribly slow. Anyway, this should be supported in >> next release (2.1). >> Kernel should be ok already (I hope :) > > Yeah, seems it's hardcoded... any estimate on when 2.1 sees the light? I hope, as already promised, end of this year. > Would it even make sense to use SHA3 with HMAC? Kernel crypto api allows any construction here, kernel can use sha3 already, but userspace has problem with dash in "sha3-256", I have to fix it. (You can trick it manually but I do not want to post hacks how to do this otherwise people start to use it :))) ... >> It is "safe" but I would better use random IV >> (so every write will regenerate IV). > Okay what does that mean now? Should/can one use [aes|serpent]-xts- > random? What nonce sizes would that use? nonce = IV = size of cipher block here (16 bytes) ... >> That's why we use random IV - with 128bit nonce the probability of >> collision is negligible even if you write lot of sectors. >> With 96bit nonce you can get collision quite "soon". > > I assume you'd use /dev/random for that?! It is in kernel, and it actually calls get_random_bytes(iv, iv_size); So yes, it is directly kernel RNG. >>> 11) The persistent settings stored with --persistent... >>> Are these encrypted/integrity protected? Otherwise an attack could >>> trick a user into e.g. using TRIM even though he doesn't because of >>> security concerns. >> >> These are not encrypted, it is stored in LUKS header in JSON. >> Actually no change here - today it is stored in crypttab in not >> encrypted initramfs. >> >> You can trick user already today - bu modyfing crypttab. or binaries >> in initramdisk. > > Well if you have a fully encrypted system, than an attacker cannot > easily mangle with the crypttab... sure you always have to start > somewhere, but there's always the choice for people to keep their > (unencrypted) boot USB-stick always with them... Then also take detached LUKS header on USB. > So I think that's a bit problematic,... if potentially security > relevant settings are now unsecured in the header... cryptsetup will > take them from there and the current model, where one was safe by > having the initramfs always at the (physical) keyring is basically > broken. > > Can't you sign these options? Or at least provide a crypttab option to > ignore any non-secured options in the header? crypttab is handled by systemd. But activation options in LUKS2 header have priority (in fact it was meant as a replacement for these options). But if you keep attacker mangling with LUKS header, he can always do harm here. (Try to move data offset in LUKS1 or just change cipher, it will corrupt data after activation.) You have to secure whole LUKS header here. And there is quite high press to make TRIM as default for dm-crypt, it started here https://www.redhat.com/archives/dm-devel/2016-September/msg00061.html and it is reappearing regularly (not on public list though). BTW Fedora has discard option as a default for several releases. And ... we do not support TRIM on FDE AEAD (dm-integrity) yet... :-) (Once supported, it can only trim data blocks, not metadata. So it will be tricky. ... m. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
