From: Ard Biesheuvel <ardb@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org, ebiggers@kernel.org,
James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [PATCH v2] crypto: lib - implement library version of AES in CFB mode
Date: Sat, 11 Mar 2023 09:55:15 +0100 [thread overview]
Message-ID: <CAMj1kXG_27v0YXoO_8Avjcz=YtYhCfX_6pcXowk0fy5cYR6gVw@mail.gmail.com> (raw)
In-Reply-To: <ZAxAK2rlOsQjlgB9@gondor.apana.org.au>
On Sat, 11 Mar 2023 at 09:47, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Sat, Mar 11, 2023 at 09:42:06AM +0100, Ard Biesheuvel wrote:
> >
> > Every call to crypto_skcipher_set_reqsize(), no?
>
> We'd only convert the software implementations. But you're right
> there does seem to be a few users such as aria that demand a large
> amount of temp space. I'd be tempted to just leave them on skcipher.
>
> In other cases such as ctr we can easily put the IV on the stack.
>
But why can't we make skcipher just a hybrid?
- make the scatterlist members in skcipher_request unions with virtual
src and dst alternatives
- add an API that assigns those alternative members and checks that
the tfm is not ALG_ASYNC
- make the existing skcipher_en/decrypt() implementations check the
request type, and hand off to a 'sync' alternative that allocates the
request ctx on the stack, and make the accessor return the stack
version instead of the heap version
- update skcipher_walk_xxx() to return the virtually addressable dst
and src if the sync request type is encountered.
That way, the skcipher implementations can remain as they are, and the
callers can just put a struct skcipher_request on the stack (without
the padding and ctx overhead) and call the new interface with virtual
addresses.
That way, all the SYNC_SKCIPHER hacks can go, and we don't need yet
another algo type.
That way, the implementations can remain the same,
next prev parent reply other threads:[~2023-03-11 8:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 14:43 [PATCH v2] crypto: lib - implement library version of AES in CFB mode Ard Biesheuvel
2023-02-20 4:44 ` Herbert Xu
2023-02-20 7:28 ` Ard Biesheuvel
2023-03-10 10:15 ` Herbert Xu
2023-03-10 16:18 ` Ard Biesheuvel
2023-03-11 8:06 ` Herbert Xu
2023-03-11 8:15 ` Ard Biesheuvel
2023-03-11 8:17 ` Herbert Xu
2023-03-11 8:42 ` Ard Biesheuvel
2023-03-11 8:47 ` Herbert Xu
2023-03-11 8:55 ` Ard Biesheuvel [this message]
2023-03-11 9:00 ` Herbert Xu
2023-03-11 9:02 ` Ard Biesheuvel
2023-03-11 9:21 ` Herbert Xu
2023-03-11 9:25 ` Ard Biesheuvel
2023-03-11 9:41 ` Herbert Xu
2023-03-12 8:06 ` Ard Biesheuvel
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='CAMj1kXG_27v0YXoO_8Avjcz=YtYhCfX_6pcXowk0fy5cYR6gVw@mail.gmail.com' \
--to=ardb@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=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 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.