Re: [PATCH 2/5] crypto: akcipher - Drop usage of sglists for verify op

[Lukas Wunner <lukas@wunner.de>]

On Tue, Aug 06, 2024 at 01:55:15PM +0800, Herbert Xu wrote:
> On Mon, Jul 29, 2024 at 03:48:00PM +0200, Lukas Wunner wrote:
> > Commit 6cb8815f41a9 ("crypto: sig - Add interface for sign/verify")
> > introduced an API which accepts kernel buffers instead of sglists for
> > signature generation and verification.
> > 
> > Commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto interface without
> > scatterlists") converted the sole user in the tree to the new API.
> > 
> > Although the API externally accepts kernel buffers, internally it still
> > converts them to sglists, which results in overhead for asymmetric
> > algorithms because they need to copy the sglists back into kernel
> > buffers.
> > 
> > Take the next step and switch signature verification over to using
> > kernel buffers internally, thereby avoiding the sglists overhead.
> > 
> > Because all ->verify implementations are synchronous, forego invocation
> > of crypto_akcipher_sync_{prep,post}() and call crypto_akcipher_verify()
> > directly from crypto_sig_verify().
> 
> The link between sig and akcipher is meant to be temporary.  The
> plan is to create a new low-level API for sig and then migrate
> the signature code over to that from akcipher.
> 
> Yes we do want to get rid of the unnecessary SG list ops but is
> it possible to side-step this for your work? If not perhaps you
> could help by creating the low-level API for sig? :)

I'm looking through the code right now to understand what would be
necessary to get there.

One issue I see is an algorithm name collision in rsa-pkcs1pad.c:
I think I'd have to register two instances in pkcs1pad_create(),
an akcipher_instance and a sig_instance.

And inst->alg.base.cra_name would be the same in both cases,
i.e. "pkcs1pad(%s)".  Now what?  :(

The last couple of days I've been contemplating amending
struct akcipher_alg with additional callbacks to get the
max_sig_size and max_data_size.  For RSA it's the same as
the keysize (which is available through the existing ->max_size
callback), but for ECDSA it's different depending on the
template.  Adding those new callbacks to a new struct sig_alg
would be cleaner of course than shoehorning them into struct
akcipher_alg.

Thanks,

Lukas