Hey. On Sun, 2018-08-19 at 12:07 +0200, Milan Broz wrote: > 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. Okay, but there are no already known issues... :) > > > 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). I will anyway add PAR files :-) ... and gpg signatures as well. So for me it was just important here, that the dm-integrity journal causes no issues... (and actually I think I can disable it - for the long term backup thingy, not for "normal" disk encryption with AEAD) > > 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. I've added this as a potential todo for the documentation at: https://gitlab.com/cryptsetup/cryptsetup/issues/404#note_95375083 > - 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've added this as a potential todo for the documentation at:https://gitlab.com/cryptsetup/cryptsetup/issues/404#note_95375142 > > > 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) Ah it's in /proc/crypto as well :-) Looking at this: - All SERPENT+XTS or AES+XTS modes have 128 bit IV. - Some GCM have the 96 bit IVs... but some have even only 64 bit (__gcm-aes-aesni, rfc4106(gcm(aes)) and __gcm-aes-aesni). - ChaCha20 seems to have all 128 bit IV... but is this correct? I've modpobed chacha20poly1305 ... but at least ther's no reference to poly1305 in /proc/crypto > 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.) Okay now I'm still confused about what one can safely use and what not :-( AFAIU: 1) aes-gcm-random => NOT safe to use Because up to at least 4.17, kernel crypt uses just 96 bit nonces for which the collision chance is too big. 2) [aes|serpent]-xts-plain64 with hmac-[sha256|sha512] (or in cryptsetup with hmac-sha3-[256|512] => SAFE to use But *-xts-random would be better (if, and only if, AEAD/integrity is used, right? Also, do NOT use -random, if no AEAD/integrity is used. 3) [aes|serpent]-xts-random with hmac-[sha256|sha512] (or in cryptsetup with hmac-sha3-[256|512] => SAFE to use -random is better than -plain64 (but ONLY with AEAD) 4) chacha20-random with poly1305 => SAFE to use Could this safely be used with -plain64? > > 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. I always didn't like this because one can easier mix up things and "open" the device with the wrong header. Perhaps one could have a stub header that contains just enough information to tell at least whether a matching device/key has been selected. > 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.) Well but at least these one would notice immediately... > You have to secure whole LUKS header here. ... but one wouldn't notice e.g. someone silently enabling TRIM for you > 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). Well even if this request comes from the very top, it's still wrong. dm-crypt/cryptsetup is for people who want security, and the defaults should be just for that. And after all, every distro can just override that defaults if it believes their users aren't "crazy-anal people" o.O Thanks, Chris. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
