This series is presented as an RFC for a couple of reasons: - it is only build tested - it is unclear whether this is the right way to move away from the use of bare ciphers in non-crypto code - we haven't really discussed whether moving away from the use of bare ciphers in non-crypto code is a goal we agree on This series creates an ESSIV shash template that takes a (cipher,hash) tuple, where the digest size of the hash must be a valid key length for the cipher. The setkey() operation takes the hash of the input key, and sets into the cipher as the encryption key. Digest operations accept input up to the block size of the cipher, and perform a single block encryption operation to produce the ESSIV output. This matches what both users of ESSIV in the kernel do, and so it is proposed as a replacement for those, in patches #2 and #3. As for the discussion: the code is untested, so it is presented for discussion only. I'd like to understand whether we agree that phasing out the bare cipher interface from non-crypto code is a good idea, and whether this approach is suitable for fscrypt and dm-crypt. Remaining work: - wiring up some essiv(x,y) combinations into the testing framework. I wonder if anything other than essiv(aes,sha256) makes sense. - testing - suggestions welcome on existing testing frameworks for dm-crypt and/or fscrypt Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Cc: Eric Biggers <ebiggers@xxxxxxxxxx> Ard Biesheuvel (3): crypto: essiv - create a new shash template for IV generation dm crypt: switch to essiv shash fscrypt: switch to ESSIV shash crypto/Kconfig | 3 + crypto/Makefile | 1 + crypto/essiv.c | 275 ++++++++++++++++++++ drivers/md/Kconfig | 1 + drivers/md/dm-crypt.c | 137 ++-------- fs/crypto/Kconfig | 1 + fs/crypto/crypto.c | 11 +- fs/crypto/fscrypt_private.h | 4 +- fs/crypto/keyinfo.c | 64 +---- 9 files changed, 321 insertions(+), 176 deletions(-) create mode 100644 crypto/essiv.c -- 2.20.1
