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;
Date:   Fri, 23 Jul 2021 09:20:25 -0700
From:   Eric Biggers <ebiggers@kernel.org>
To:     Thara Gopinath <thara.gopinath@linaro.org>
Cc:     Herbert Xu <herbert@gondor.apana.org.au>,
        linux-crypto@vger.kernel.org
Subject: Re: Extending CRYPTO_ALG_OPTIONAL_KEY for cipher algorithms
Message-ID: <YPrsScKf/YlKmNfU@gmail.com>
References: <f04c8f1d-db85-c9e1-1717-4ca98b7c8c35@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f04c8f1d-db85-c9e1-1717-4ca98b7c8c35@linaro.org>
Precedence: bulk

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