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
Date: Fri, 23 Jul 2021 09:20:25 -0700 [thread overview]
Message-ID: <YPrsScKf/YlKmNfU@gmail.com> (raw)
In-Reply-To: <f04c8f1d-db85-c9e1-1717-4ca98b7c8c35@linaro.org>
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
next prev parent reply other threads:[~2021-07-23 16:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-23 10:13 Extending CRYPTO_ALG_OPTIONAL_KEY for cipher algorithms Thara Gopinath
2021-07-23 16:20 ` Eric Biggers [this message]
2021-07-24 9:42 ` Gilad Ben-Yossef
2021-07-29 10:32 ` Thara Gopinath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YPrsScKf/YlKmNfU@gmail.com \
--to=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=thara.gopinath@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.