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

Dmitry Eremin-Solenikov dbaryshkov at gmail.com
Tue Mar 4 16:27:21 CET 2014


On Tue, Mar 4, 2014 at 7:02 PM, Werner Koch <wk at gnupg.org> wrote:
> 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.

More or less the same problem here - I have private keys without public
key bundled in, so I have to restore it.

> 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_*).

The problem is that they are not supported yet for non-ECC things,
are they?

> 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).

Would it be possible to use contexts instead of s-exp in external API?
That would bring some speedup for the library I think.

With best wishes

More information about the Gcrypt-devel mailing list