public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH 00/15] crypto: Add twopass lskcipher for adiantum
Date: Wed, 14 Feb 2024 15:35:17 -0800	[thread overview]
Message-ID: <20240214233517.GD1638@sol.localdomain> (raw)
In-Reply-To: <cover.1707815065.git.herbert@gondor.apana.org.au>

On Tue, Feb 13, 2024 at 05:04:25PM +0800, Herbert Xu wrote:
> [PATCH 00/15] crypto: Add twopass lskcipher for adiantum

Thanks.  Can you include an explanation of the high-level context and goals for
this work?  It's still not clear to me.  I'm guessing that the main goal is to
get rid of the vaddr => scatterlist => vaddr round trip for software
encryption/decryption, which hopefully will improve performance and make the API
easier to use?  And to do that, all software algorithms need to be converted to
"lskcipher"?  Will skcipher API users actually be able to convert to lskcipher,
or will they be blocked by people expecting to be able to use hardware crypto
accelerators?  Would you accept lskcipher being used alongside skcipher?
Previously you had said you don't want shash being used alongside ahash.

I'd prefer there was a clear plan before merging a bunch of patches that leave
everything in a half-finished state.

By the way, note that hctr2 requires two passes too, as it's an SPRP like
Adiantum.  Also note that SPRPs in general may require more than two passes,
though Adiantum and HCTR2 were designed to only need two (technically they have
three passes, but two are combinable).  It's fine to support only two passes if
that's what's needed now; I just thought I'd mention that there's no guarantee
that two passes will be enough forever.

> In addition to converting adiantum, the underlying chacha algorithm
> is also converted over to lskcipher.
> 
> The algorithms cts + xts have been converted too to ensure that the
> tailsize mechanism works properly for them.  While doing this the
> parameters for cts + xts have been modified so that blocksize is now
> 1.  This entails changing the paramters of all drivers that support
> cts and/or xts.

cts and xts have nothing to do with adiantum.  So this further indicates that
the scope of this work is broader than just "crypto: Add twopass lskcipher for
adiantum" as suggested by the title.

It would be good to have a sense for the direction of this work.  What will be
coming next?

- Eric

  parent reply	other threads:[~2024-02-14 23:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-13  9:04 [PATCH 00/15] crypto: Add twopass lskcipher for adiantum Herbert Xu
2023-12-02  4:55 ` [PATCH 01/15] crypto: skcipher - Add tailsize attribute Herbert Xu
2024-02-14 23:44   ` Eric Biggers
2024-02-15  6:40     ` Herbert Xu
2024-02-23  6:01       ` Eric Biggers
2023-12-02  5:42 ` [PATCH 02/15] crypto: algif_skcipher - Add support for tailsize Herbert Xu
2023-12-04 10:24 ` [PATCH 04/15] crypto: xts - Convert from skcipher to lskcipher Herbert Xu
2023-12-05  6:09 ` [PATCH 05/15] crypto: skcipher - Add twopass attribute Herbert Xu
2023-12-05  6:13 ` [PATCH 06/15] crypto: algif_skcipher - Disallow nonincremental algorithms Herbert Xu
2024-02-14 22:56   ` Eric Biggers
2024-02-15  6:47     ` Herbert Xu
2024-02-23  6:00       ` Eric Biggers
2023-12-05  9:52 ` [PATCH 07/15] crypto: adiantum - Use lskcipher instead of cipher Herbert Xu
2023-12-06  4:46 ` [PATCH 08/15] crypto: skcipher - Add incremental support to lskcipher wrapper Herbert Xu
2023-12-06  5:49 ` [PATCH 09/15] crypto: chacha-generic - Convert from skcipher to lskcipher Herbert Xu
2024-02-14 23:41   ` Eric Biggers
2024-02-15  6:52     ` Herbert Xu
2023-12-06  6:05 ` [PATCH 10/15] crypto: skcipher - Move nesting check into ecb Herbert Xu
2023-12-06  8:55 ` [PATCH 11/15] crypto: skcipher - Propagate zero-length requests to lskcipher Herbert Xu
2023-12-07 10:03 ` [PATCH 03/15] crypto: skcipher - Remove ivsize check for lskcipher simple templates Herbert Xu
2023-12-07 10:13 ` [PATCH 12/15] crypto: cts - Convert from skcipher to lskcipher Herbert Xu
2023-12-29 10:47 ` [PATCH 13/15] crypto: cts,xts - Update parameters blocksize/chunksize/tailsize Herbert Xu
2024-02-14 23:00   ` Eric Biggers
2024-02-15  7:57     ` Herbert Xu
2024-02-23  6:09       ` Eric Biggers
2023-12-30  7:16 ` [PATCH 14/15] crypto: lskcipher - Export incremental interface internally Herbert Xu
2024-02-13  8:48 ` [PATCH 15/15] crypto: adiantum - Convert from skcipher to lskcipher Herbert Xu
2024-02-14 23:35 ` Eric Biggers [this message]
2024-02-15  8:20   ` [PATCH 00/15] crypto: Add twopass lskcipher for adiantum Herbert Xu
2024-02-23  6:39     ` Eric Biggers

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=20240214233517.GD1638@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@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