On Thu, Jul 18, 2019 at 01:19:41PM +0200, Milan Broz wrote: > > > From that perspective - to prevent people from doing cryptographically stupid things - > > IMHO it would be better to just pull the CTS into the XTS implementation i.e. make > > xts natively support blocks that are not a multiple of (but >=) the cipher blocksize ... > > I would definitely prefer adding CTS directly to XTS (as it is in gcrypt or OpenSSL now) > instead of some new compositions. > > Also, I would like to avoid another "just because it is nicer" module dependence (XTS->XEX->ECB). > Last time (when XTS was reimplemented using ECB) we have many reports with initramfs > missing ECB module preventing boot from AES-XTS encrypted root after kernel upgrade... > Just saying. (Despite the last time it was keyring what broke encrypted boot ;-) > Can't the "missing modules in initramfs" issue be solved by using a MODULE_SOFTDEP()? Actually, why isn't that being used for xts -> ecb already? (There was also a bug where CONFIG_CRYPTO_XTS didn't select CONFIG_CRYPTO_ECB, but that was simply a bug, which was fixed.) Or "xts" and "xex" could go in the same kernel module xts.ko, which would make this a non-issue. Anyway, I agree that the partial block support, if added, should just be made available under the name "xts", as people would expect. It doesn't need a new name. - Eric
