public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Ingo Franzki <ifranzki@linux.ibm.com>
Cc: Harald Freudenberger <freude@linux.ibm.com>,
	linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
	dengler@linux.ibm.com, davem@davemloft.net, hca@linux.ibm.com
Subject: Re: [PATCH v3 3/3] s390/crypto: New s390 specific shash phmac
Date: Tue, 12 Nov 2024 09:34:18 +0800	[thread overview]
Message-ID: <ZzKwms8HEUYkEXnf@gondor.apana.org.au> (raw)
In-Reply-To: <ea93f581-795b-49c3-865a-76a00ee46c01@linux.ibm.com>

On Mon, Nov 11, 2024 at 01:13:34PM +0100, Ingo Franzki wrote:
>
> There is no need to perform the (possibly time consuming) key conversation at every init.

The key is converted not just at init, but multiple times during
each update operation.  Remember the API is multi-threaded, so at
any time there could be multiple tfm's, each with a different key
being operated on in parallel.

If the hardware is such that you can only have one converted key,
then I'm afraid you're stuck with having to do the conversion before
each use.

However, since we are converting the key during each update, why
is it even stored in the tfm_ctx?

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

  reply	other threads:[~2024-11-12  1:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-07 14:55 [PATCH v3 0/3] New s390 specific protected key hmac Harald Freudenberger
2024-11-07 14:55 ` [PATCH v3 1/3] crypto: api - Adjust HASH_MAX_DESCSIZE for s390-phmac context Harald Freudenberger
2024-11-07 14:55 ` [PATCH v3 2/3] s390/crypto: Add protected key hmac subfunctions for KMAC Harald Freudenberger
2024-11-07 14:55 ` [PATCH v3 3/3] s390/crypto: New s390 specific shash phmac Harald Freudenberger
2024-11-11 12:13   ` Ingo Franzki
2024-11-12  1:34     ` Herbert Xu [this message]
2024-11-12  1:38   ` Herbert Xu
2024-11-12 12:45     ` Harald Freudenberger
2024-11-14 11:17       ` Herbert Xu

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=ZzKwms8HEUYkEXnf@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=davem@davemloft.net \
    --cc=dengler@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=ifranzki@linux.ibm.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-s390@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox