mpi: EC point operations [discussion]
christian at grothoff.org
Fri Mar 8 23:46:08 CET 2013
Looking at your three patches, I think they should in theory suffice to implement ECDH
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
First of all, I didn't find how I would take a point from an S-expression (gcry_sexp_t) and
convert that to a gcry_mpi_point_t. So that function would definitively still be needed to
bridge the high and low-level APIs.
Even with that, the result would still be a bit ugly. Right now, I generate a key with:
gcry_sexp_build (&s_keyparam, NULL,
"(genkey(ecdsa(curve \"NIST P256\"))))");
gcry_pk_genkey (&s_key, s_keyparam);
this key I can then use for ECDSA. If I wanted to use it for ECDH, I would have to manually
parse the S-expression and extract P, A, Q, d, G to run the gcry_mpi_ec_mul function that
your testcase invokes as follows:
+ P = hex2mpi ("0xfffffffffffffffffffffffffffffffeffffffffffffffff");
+ A = hex2mpi ("0xfffffffffffffffffffffffffffffffefffffffffffffffc");
+ G = make_point ("188DA80EB03090F67CBF20EB43A18800F4FF0AFD82FF1012",
+ d = hex2mpi ("D4EF27E32F8AD8E2A1C6DDEBB1D235A69E3CEF9BCE90273D");
+ Q = gcry_mpi_point_new (0);
+ ctx = gcry_mpi_ec_p_new (P, A);
+ gcry_mpi_ec_mul (Q, d, G, ctx);
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.
Note that I'm not suggesting to remove the low-level API your patches added; I'm
generally not always happy that I have to box and unbox everything in S-expressions,
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.
Finally, with respect to highly optimized code for a particular curve (like the ED25519 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
gcry_mpi_ec_p_new function would have to do some semi-ugly test to check if the curve
parameters happened to match a specialized curve to then use the custom logic. Having
a way to initialize certain curves by name (or enum) would also make it trivial to replace
generic ECC operator implementations with optimized versions.
My 2 cents for tonight!
p.s.: I didn't see these in Git master; is there a branch I should be looking at?
More information about the Gcrypt-devel