Re: [RFC PATCH 0/3] crypto: switch to shash for ESSIV generation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux