"Fixing" private key/generating public key from incomplete private
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,
> 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