[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150601054857.GA10460@gondor.apana.org.au>
Date: Mon, 1 Jun 2015 13:48:57 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Tadeusz Struk <tadeusz.struk@...el.com>
Cc: Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
keescook@...omium.org, jwboyer@...hat.com, richard@....at,
steved@...hat.com, qat-linux@...el.com, dhowells@...hat.com,
linux-crypto@...r.kernel.org, james.l.morris@...cle.com,
jkosina@...e.cz, zohar@...ux.vnet.ibm.com, davem@...emloft.net,
vgoyal@...hat.com
Subject: Re: [PATCH RFC v2 1/2] crypto: add PKE API
On Thu, May 28, 2015 at 09:54:41AM -0700, Tadeusz Struk wrote:
>
> If we do this that way then we will be able to pass only one input and one
> output parameter. There are cases when we will need more that this.
> For instance for ECDSA signature generation we need one input param hash(m)
> and two output parameters (r, s).
There is no reason why you couldn't encode that within one stream.
As far as as the user is concerned the output is one entity, i.e.,
the signature. The fact that it is made up of two numbers is of
no concern to the API. It's a technicality for the algorithm to
sort out.
> So I have used the SG for that. This is not to deal with non-contiguous memory,
> but to pass more in/out parameters. Each parameter will need to occupy contiguous space in memory.
> I will update the comment to make it more clear.
> If you have other idea how to do this I will be happy to try it.
If you really wanted to do this then you should be using a simple
(u8 *, unsigned int) pair but I don't really think this is at all
necessary.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists