mpi: EC point operations [discussion]

[Christian Grothoff]

On 03/11/2013 09:15 AM, Werner Koch wrote:
> On Fri,  8 Mar 2013 23:46, christian at grothoff.org said:
>
>> using libgcrypt; however, the mismatch between the s-expression based public key
>> APIs to create signatures (ECDSA) and the low-level MPI-API is pretty rough from a
>> user's perspective.
> Agreed.  Right now we only have a low level API for some math fucntions.
> This is similar to the RSA and the raw MPI functions.
>
>> +  ctx = gcry_mpi_ec_p_new (P, A);
> I had the idea to add some more optional arguments to that function but
> then decided against it.  As of now, this function is basically the same
> as the internally used one.  A useful and more generic additional
> function would be
>
>    ctx = gcry_mpi_ec_new ("(curve \"NIST P256\")");
>
> and for ease of use would also accept the genkey parameter set like
>
>    ctx = gcry_mpi_ec_new ("(genkey(ecdsa(curve \"NIST P256\")))")
>
> this solves parsing the s-exp for P and A.  To retrieve the key
> parameters (or whatever) from the context I can image these functions:
>
>    mpi   = gcry_mpi_ec_get_mpi ("d", ctx);
>    point = gcry_mpi_ec_get_point ("G", ctx)
>
> This requires additionalallocation etc. but it is a quite generic way to
> retrieve the needed values.
Yes, that exact API would be beautiful.
>> So having a higher-level API that can --- instead of a manually constructed 'ctx' --- take
>> the "s_key" S-expression and 'd' and returns 'Q' would certainly be a nice extension.
> See above.
>
>> but in cases where they are already in use (i.e. because of gcry_pk_*-operations), it
>> would make sense to me to make the transition between the high- and low-level APIs
>> as painless as possible.
> We have to see how we can optimize that further.
Once you have the proposed gcry_mpi_ec_new, you can easily add the hacks 
for this into the
ctx-construction based on the name of the curve.
>> I wonder if you'd not want some "other" means to initialize that 'ctx', say with a bunch of
>> function pointers that point to curve-specific optimized operations.  Right now, the
> That would be an internal operation and invisible to the API.  Thus it
> can be done at any time without changing the API.
>
>    gcry_mpi_ec_set_mpi ("d", mpi, ctx);
>    gcry_mpi_ec_set_point ("G", point, ctx)
>
> might be auseful extension as well.
I very much agree.
>> p.s.: I didn't see these in Git master; is there a branch I should be
>> looking
> I have a private branch for now.  If you think the current interface and
> my proposed extensions are okay I can push that to master.
I see. With the extensions discussed here, I think it should be 
sufficient for at least
my purpose ;-).  Let me know once the changes have hit master ;-).

Happy hacking!

Christian