On Sun, Jun 16, 2019 at 11:44 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > [+Cc dm-devel and linux-fscrypt] > > On Fri, Jun 14, 2019 at 10:34:01AM +0200, Ard Biesheuvel wrote: > > 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. ... > I agree that moving away from bare block ciphers is generally a good idea. For > fscrypt I'm fine with moving ESSIV into the crypto API, though I'm not sure a > shash template is the best approach. Did you also consider making it a skcipher > template so that users can do e.g. "essiv(cbc(aes),sha256,aes)"? That would > simplify things much more on the fscrypt side, since then all the ESSIV-related > code would go away entirely except for changing the string "cbc(aes)" to > "essiv(cbc(aes),sha256,aes)". I will also add that going the skcipher route rather than shash will allow hardware tfm providers like CryptoCell that can do the ESSIV part in hardware implement that as a single API call and/or hardware invocation flow. For those system that benefit from hardware providers this can be beneficial. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom!
