[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YuJWNgIupkBPvsCD@gondor.apana.org.au>
Date: Thu, 28 Jul 2022 17:26:14 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Leonard Crestez <cdleonard@...il.com>
Cc: Dmitry Safonov <dima@...sta.com>, linux-kernel@...r.kernel.org,
Dmitry Safonov <0x7f454c46@...il.com>,
Andy Lutomirski <luto@...capital.net>,
Ard Biesheuvel <ardb@...nel.org>,
David Ahern <dsahern@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Biggers <ebiggers@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
Francesco Ruggeri <fruggeri@...sta.com>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Salam Noureddine <noureddine@...sta.com>,
netdev@...r.kernel.org, linux-crypto@...r.kernel.org
Subject: Re: [PATCH 0/6] net/crypto: Introduce crypto_pool
On Wed, Jul 27, 2022 at 06:52:27PM +0300, Leonard Crestez wrote:
>
> The fact that setkey is implemented at the crypto_ahash instead of the
> ahash_request level is baked into all algorithm implementations (including
> many hardware-specific ones). Changing this seems extremely difficult.
What I had in mind is simply making the tfm setkey optional. That
way you could then have an additional setkey at the request level.
If the key is provided in either place you're allowed to perform
the hash.
This should have minimal impact on existing code.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists