"Fixing" private key/generating public key from incomplete private

Werner Koch wk at gnupg.org
Tue Mar 4 16:02:50 CET 2014

On Sat,  1 Feb 2014 18:06, dbaryshkov at gmail.com said:

> the DSA key from PKCS#8 keyfile. It contains (in terms of gcrypt
> s-exp) domain parameters (p, q, g), secret exponent (x) but no
> public exponent (y). I found gcrypt_pubkey_get_sexp, but it
> (currently) only works for ECC.

We have a similar thing in RSA due to the different ways of specifying
the parameters required for the use of the CRT.  Libgcrypt solves this
in the general case by not using the CRT.  Gpg-agent however computes
missing parameters in the form required by Libgcrypt during import of an
(OpenSSL) generated key.

Your idea is to define a function to help an application to compute the
parameters in the Libgcrypt preferred (or required) form.

> It there a good way to solve my problem? I was thinking about
> adding an special mode to gcry_pk_genkey or about adding a

Not good.  The key has alrady be generated.

> special API resembling gcrypt_pubkey_get_sexp() but working
> with such (incomplete) private keys instead of contexts.

What is your problem with contexts?  They will be helpful to cache
intermediate results, for example for mass verification.  Thus I plan to
implement them anyway (gcry_pubkey_*).

For example we could use something like this:

   gcry_ctx_new (&ctx)
   gcry_pubkey_testkey (key, ctx);
   gcry_pubkey_get_sexp (&result, GCRY_PK_GET_PUBKEY, ctx);
   gcry_ctx_release (ctx);

With gcry_pubkey_testkey being identical to gcry_pk_testkey if no
context is given.  gcry_ctx_new would create a new empty context object
which gcry_pubkey_testkey would the setup with its internal intermediate
results (e.g. y).



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gcrypt-devel mailing list