2021-07-23 10:17:24

by Thara Gopinath

[permalink] [raw]
Subject: Extending CRYPTO_ALG_OPTIONAL_KEY for cipher algorithms

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.



--
Warm Regards
Thara (She/Her/Hers)


2021-07-23 16:21:28

by Eric Biggers

[permalink] [raw]
Subject: Re: Extending CRYPTO_ALG_OPTIONAL_KEY for cipher algorithms

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.

- Eric

2021-07-24 09:43:02

by Gilad Ben-Yossef

[permalink] [raw]
Subject: Re: Extending CRYPTO_ALG_OPTIONAL_KEY for cipher algorithms

On Fri, Jul 23, 2021 at 7:20 PM Eric Biggers <[email protected]> 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!