Extending CRYPTO_ALG_OPTIONAL_KEY for cipher algorithms

Extending CRYPTO_ALG_OPTIONAL_KEY for cipher algorithms

[Thara Gopinath]

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)

Re: Extending CRYPTO_ALG_OPTIONAL_KEY for cipher algorithms

[Eric Biggers]

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

Re: Extending CRYPTO_ALG_OPTIONAL_KEY for cipher algorithms

[Gilad Ben-Yossef]

On Fri, Jul 23, 2021 at 7:20 PM Eric Biggers <ebiggers@kernel.org> 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!

Re: Extending CRYPTO_ALG_OPTIONAL_KEY for cipher algorithms

[Thara Gopinath]

On 7/24/21 5:42 AM, Gilad Ben-Yossef wrote:
> On Fri, Jul 23, 2021 at 7:20 PM Eric Biggers <ebiggers@kernel.org> 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.

Thanks Eric and Gilad for the pointers. Gilad, the talk is great. I wish 
I had seen it prior to telling my manager that we will have to "invent" 
something new for this! This should mostly suffice for my use-case. 
Although, I see that all the protected implementations are for aes 
algorithms. Is it fair to say that it can be extended to other cipher 
algorithms and/or hash algorithms if needed ?

> 
> Cheers,
> Gilad
> 

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