mpi: EC point operations [discussion]

[Christian Grothoff]

Hi Werner,

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
user's perspective. 

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",
+                  "7192B95FFC8DA78631011ED6B24CDD573F977A11E794811",
+                  "1");
+  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!

Happy hacking!

-Christian
p.s.: I didn't see these in Git master; is there a branch I should be looking at?