mpi: EC point operations [discussion]
christian at grothoff.org
Mon Mar 11 09:28:14 CET 2013
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
> 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 ;-).
More information about the Gcrypt-devel