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

[Dmitry Eremin-Solenikov]

Hello,

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.

Yes.

>
>> 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
Dmitry