FYI, unfortunately quite bad mistake was found in the dm-crypt code that uses ESSIV with LUKS2 (through cryptsetup2). See mail below. https://www.redhat.com/archives/dm-devel/2018-January/msg00157.html (LUKS2 by default enables using of kernel keyring for volume key.) There is no problem with LUKS1. Also there is no code that enables kernel keyring for other IVs (so TrueCrypt and Loopaes modes are not affected if used though cryptsetup2). This bug means that we effectively use zeroed key for ESSIV IV derivation, it de-facto degrades it to plain IV and causes data corruption (first 16 bytes in CBC mode, whole sector if used with XTS mode). I hope there are not many users that converted existing CBC-ESSIV device to LUKS2, the default is XTS-plain64 mode is not affected. We will disable kernel keyring for affected kernel in next release of cryptsetup, but some devices could be already corrupted by this bug. Sorry for that, even the review missed this mistake :-( Milan -------- Forwarded Message -------- Subject: [BUG] dm crypt: kernel keyring key processing bug Date: Fri, 12 Jan 2018 16:30:31 +0100 From: Ondrej Kozina <okozina@xxxxxxxxxx> To: dm-devel@xxxxxxxxxx Hi, there's unfortunate and quite nasty bug in IV initialization when key is being passed via kernel keyring service. We erase internal key copy too soon and we pass wrong key to IV initialization routines. Affected IVs I reproduced [1] the bug with are: 'essiv' and 'tcw'. I don't have a test yet for 'lmk', but it's probably also affected. Users probably won't notice the bug if they don't mix loading keys via keyring service and via classical hexbyte representation. But doing so and using any affected IV will lead to data corruption. The good news is keyring service is not used with LUKS1 devices and with plain encryption in cryptsetup (even with cryptsetup 2.0.0). This may change when users start adopting LUKS2 format and convert LUKS1 device with i.e.: cbc-essiv:sha256 mode to LUKS2. LUKS2 uses keyring service by default. Mike, If you accept the patch please resend also to stable kernels. [1] https://gitlab.com/cryptsetup/cryptsetup/blob/wip-luks2/tests/keyring-compat-test Ondrej Kozina (1): dm crypt: wipe kernel key copy after IV initialization drivers/md/dm-crypt.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) -- 1.8.3.1 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
