q not derived from d in gcry_pk_sign
Werner Koch
wk at gnupg.org
Fri Mar 22 15:43:19 CET 2013
On Fri, 22 Mar 2013 10:19, grothoff at in.tum.de said:
> 'q' value is not found (as it is neither in the curve nor explicitly in
> the S-expression); however, q can of course be calculated as q = dg
> from the private key and the curve.
Right. That raises another question. In contrast to gcry_cipher_ and
gcry_md_, the gcry_pk_ functions don't follow an open-process-close
paradigm and thus have no associated context. For the fast ECC
operations we have seen that a context is sometimes useful to speed up
operations. To some degree this would also be true for the other
algorithms. For example, I never implemented Montgomery multiplication
because a real performance gain could only be achieved if we would be
able to cache temporary values. The original idea was to employ a real
cache for this, however that requires quite some code to get it right
and thread safe. If we could use a caller provided context instead,
this would shift the responsibility of caching to the caller, who better
knows whether it makes sense.
Given that we have an ABI break anyway, I consider to add a context
argument to all gcry_pk_ functions which may eventually be used to
implement such features. For now we would just pass NULL for the
context but we may then start to experiment without breaking the ABI or
API.
gcry_error_t gcry_pk_sign_ext (gcry_sexp_t *result,
gcry_sexp_t data, gcry_sexp_t skey,
gcry_ctx_t ctx);
#define gcry_pk_sign(a,b,c) gcry_pk_sign_ext ((a),(b),(c), NULL)
(Or should we use gcry_pubkey_foo instead of gcry_pk_sign_ext ?)
> The nicest fix I can think of right now would be a change to how
> sexp_elements_extract_ecc' works (i.e. reporting "got all" even
> if q was not found and forcing the caller to manually check &
Given that ECC is not yet in widespread use it would be okay to go with
this little interface change.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gcrypt-devel
mailing list