Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: Extending CRYPTO_ALG_OPTIONAL_KEY for cipher algorithms
To:     Gilad Ben-Yossef <gilad@benyossef.com>,
        Eric Biggers <ebiggers@kernel.org>
Cc:     Herbert Xu <herbert@gondor.apana.org.au>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
References: <f04c8f1d-db85-c9e1-1717-4ca98b7c8c35@linaro.org>
 <YPrsScKf/YlKmNfU@gmail.com>
 <CAOtvUMfwbBr44qOCma4RaH_RoC35x00N=O1Ejaxc+5EPGY8rUw@mail.gmail.com>
From:   Thara Gopinath <thara.gopinath@linaro.org>
Message-ID: <42d22781-be50-174d-033a-bac0ed5efffb@linaro.org>
Date:   Thu, 29 Jul 2021 06:32:06 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAOtvUMfwbBr44qOCma4RaH_RoC35x00N=O1Ejaxc+5EPGY8rUw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


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)