From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Nathan Huckleberry <nhuck@google.com>,
linux-crypto@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
linux-arm-kernel@lists.infradead.org,
Paul Crowley <paulcrowley@google.com>,
Sami Tolvanen <samitolvanen@google.com>
Subject: Re: [RFC PATCH 3/7] crypto: hctr2 - Add HCTR2 support
Date: Wed, 26 Jan 2022 21:36:09 -0800 [thread overview]
Message-ID: <YfIvSXgnUMoPglCt@sol.localdomain> (raw)
In-Reply-To: <YfIrr8MagPw9scLr@gondor.apana.org.au>
On Thu, Jan 27, 2022 at 04:20:47PM +1100, Herbert Xu wrote:
> On Wed, Jan 26, 2022 at 09:08:38PM -0800, Eric Biggers wrote:
> >
> > The optional parameters mentioned in the comment above don't appear to be
> > implemented. Also, the syntax described is ambiguous. I think you meant for
> > there to be only one set of square brackets?
> >
> > xctr(blockcipher_name) should be xctr_name, since it would have to be a driver /
> > implementation name, and those don't necessarily include parentheses like the
> > algorithm names do.
> >
> > Did you consider not allowing the single block cipher implementation to be
> > overridden? The single block cipher is a minor part compared to xctr. This
> > would simplify the "full" syntax slighty, as then it would be
> > "hctr2(xctr_name, polyval_name)" instead of
> > "hctr2(blockcipher_name, xctr_name, polyval_name)".
> >
> > I suppose it does make sense to take the single block cipher parameter, given
> > that it is used. But you'll need to make sure to make hctr2_create() enforce
> > that the same block cipher is used in both parameters.
>
> For the single block cipher parameter, another option is to derive
> it from the xctr_name. That is, once you have the skcipher for
> xctr_name, you extract its cra_name, assuming that it must be of
> the form xctr(%s) then you just strip away the xctr() and get the
> single block cipher name that way.
That's what I had in mind with "hctr2(xctr_name, polyval_name)".
>
> The purpose of having the parameter explicitly is so that the
> instantiatied algorithm is automatically torn down when the
> underlying algorithm is replaced with a better version.
>
> This is in general unnecessary if you're simply using the
> single block cipher to generate setup material.
>
Well, the single block cipher isn't used just in ->setkey(), but also in
->encrypt() and ->decrypt() (not for the bulk of the data, but for 1 block).
So allowing its implementation to be specified might make sense.
Alternatively the single block cipher could be emulated with xctr which the
template already has, similar to how the cts template only uses cbc, but I think
that would be pretty messy here.
- Eric
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-27 5:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-25 1:44 [RFC PATCH 0/7] crypto: HCTR2 support Nathan Huckleberry
2022-01-25 1:44 ` [RFC PATCH 1/7] crypto: xctr - Add XCTR support Nathan Huckleberry
2022-01-27 5:28 ` Eric Biggers
2022-01-27 9:42 ` Ard Biesheuvel
2022-01-27 19:26 ` Eric Biggers
2022-01-27 19:43 ` Ard Biesheuvel
2022-01-25 1:44 ` [RFC PATCH 2/7] crypto: polyval - Add POLYVAL support Nathan Huckleberry
2022-01-27 5:19 ` Eric Biggers
2022-01-25 1:44 ` [RFC PATCH 3/7] crypto: hctr2 - Add HCTR2 support Nathan Huckleberry
2022-01-27 5:08 ` Eric Biggers
2022-01-27 5:20 ` Herbert Xu
2022-01-27 5:36 ` Eric Biggers [this message]
2022-01-27 5:40 ` Herbert Xu
2022-01-27 5:44 ` Herbert Xu
2022-01-27 6:41 ` Eric Biggers
2022-01-27 6:35 ` Eric Biggers
2022-02-01 18:25 ` Eric Biggers
2022-01-27 9:29 ` Ard Biesheuvel
2022-01-27 19:20 ` Eric Biggers
2022-01-25 1:44 ` [RFC PATCH 4/7] crypto: x86/aesni-xctr: Add accelerated implementation of XCTR Nathan Huckleberry
2022-01-25 1:44 ` [RFC PATCH 5/7] crypto: arm64/aes-xctr: " Nathan Huckleberry
2022-01-28 14:10 ` Ard Biesheuvel
2022-02-07 10:00 ` Ard Biesheuvel
2022-01-25 1:44 ` [RFC PATCH 6/7] crypto: x86/polyval: Add PCLMULQDQ accelerated implementation of POLYVAL Nathan Huckleberry
2022-02-01 18:18 ` Eric Biggers
2022-02-03 3:28 ` Eric Biggers
2022-01-25 1:44 ` [RFC PATCH 7/7] crypto: arm64/polyval: Add PMULL " Nathan Huckleberry
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=YfIvSXgnUMoPglCt@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=nhuck@google.com \
--cc=paulcrowley@google.com \
--cc=samitolvanen@google.com \
/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;
as well as URLs for NNTP newsgroup(s).