Hey Milan! Thanks for your replies :-) 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 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. > > 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. > 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). > What I meant is that the problem with FDE is missing data context - > you have one key > for everything, one user can decrypt all data etc. > You perhaps do not want this on multi-user system. Ah I see :-) > My threat model does not protect to data replay (you can revert > sectors from old copy). AFAIU this is the case even *with* AEAD, right? I'd have hoped that this would effectively be solved when a fs above does checksumming and has something like btrfs generations... > > 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? Would it even make sense to use SHA3 with HMAC? https://crypto.stackexchange.com/questions/35127/should-hmac-sha3-be-preferred-over-hck-m Says KMAC would be more suited for it. > > 8) Something more important for me: > > a) Which algos are already safe to use for encryption/integrity? > > In the release notes you basically list these three: > > * aes-xts-plain64 with hmac-sha256 or hmac-sha512 as the > > authentication tag. > > * aes-gcm-random (native AEAD mode) > > DO NOT USE in production! The GCM mode uses only 96-bit nonce, > > * ChaCha20 with Poly1305 authenticator (according to RFC7539) > > > > But in another place it also says that Chacha20-poly1305 is > > affacted by the small nonce: > > > > NOTE: Currently available authenticated modes (GCM, Chacha20- > > poly1305) > > in kernel have too small 96-bit nonces that are problematic with > > randomly generated IVs (the collison probability is not > > negligible). > > For the GCM, nonce collision is a fatal problem. > > > > b) So is only aes-xts-plain64 / with hmac-sha* safe to use? Or is > > even > > that safe to use at all? > > It depends, what you expect. Well as much confidentiality and integrity as possible, without looking at performance > 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? I'd always assumed aes-xts-plain64 was the "best" choice so far. But apart from that, right now it's not recommended to use either aes- gcm-random or ChaCha20/Poly1305, right? Once this would use bigger nonces... what's then the suggested "best" cipher spec... for both AEAD and non-AEAD? Btw: Has anyone had a look at Ketje? > > 10) We plan to use AEGIS and MORUS, as CAESAR finalists. > > Are these then safer than aes-xts-plain64 / hmac-*? > > I stumbled over a paper which shows that these algos fail pretty > > bad if > > a nonce is reused: > > https://eprint.iacr.org/2017/1137.pdf > > Nonce must not be reused here. > > 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?! > > 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... 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? > > 12) Next to normal disk encryption (and in the future integrity > > protection) like on a laptop,... I'd like to "abuse" cryptsetup/dm- > > crypt for now to encrypt plain files, i.e. very large (~20GiB) dar > > files that are backups of all my personal data and which I want to > > write to tape. > > Since this will be long term archival,... I'd like to > > - triple encrypt with different algos (AES, SERPENT, <something > > else>) > > - use a recent password hashing algo (Argon2*) > > I think I read your mail on some crypto list. It's a small world ;-) > Not sure if I can help here. Well the main question is probably... are there any concerns/weaknesses in using XTS when not doing normal FDE? Sure, AFAIU, in XTS every sector is independent, so there's the change of replay attacks (which is not that easy with e.g. CBC as everything is chained)... but when I use a single key for every encrypted container and encrypt only once, replaying shouldn't anyway be possible at all. Thanks, Chris. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
