On Fri, Jul 23, 2021 at 7:20 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Fri, Jul 23, 2021 at 06:13:50AM -0400, Thara Gopinath wrote: > > Hi > > > > I have a requirement where the keys for the crypto cipher algorithms are > > already programmed in the h/w pipes/channels and thus the ->encrypt() > > and ->decrypt() can be called without set_key being called first. > > I see that CRYPTO_ALG_OPTIONAL_KEY has been added to take care of > > such requirements for CRC-32. My question is can the usage of this flag > > be extended for cipher and other crypto algorithms as well. Can setting of > > this flag indicate that the algorithm can be used without calling set_key > > first and then the individual drivers can handle cases where > > both h/w keys and s/w keys need to be supported. > > CRYPTO_ALG_OPTIONAL_KEY isn't meant for this use case, but rather for algorithms > that have both keyed and unkeyed versions such as BLAKE2b and BLAKE2s, and also > for algorithms where the "key" isn't actually a key but rather is an initial > value that has a default value, such as CRC-32 and xxHash. > > It appears that that the case you're asking about is handled by using a > different algorithm name, e.g. see the "paes" algorithms in > drivers/crypto/ccree/cc_cipher.c. Yeap, seems like another use case for "protected keys" like CryptoCell and the IBM mainframe. I gave a talk about this you might find useful - https://www.youtube.com/watch?v=GbcpwUBFGDw Feel free to contact me if you have questions. Cheers, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom!
