Regenerate Openpgp Public Key from Private Key

halfdog me at halfdog.net
Tue Sep 17 14:31:14 CEST 2019


Werner Koch writes:
> On Tue, 17 Sep 2019 11:09, me at halfdog.net said:
>
>> Therefore some exports (or copies of old secring.gpg) just
>> do no include the public key, otherwise import would be trivial.
>
> Nope.  It is not possible to create an OpenPGP secret keyblok
> without the public key parts.

There must have been some easy/likely pathes to reach such a
state regarding the number people searching for such a solution,
e.g. checking only 'gpg "secret key without public key"', which
is only one possible error message in such an incomplete-private-key
scenario.

One cause seems loss of pubring.gpg (or zeroing out, not replaying
it from backup, ...) as documented in [0].

Others might be related only to the missing user_id or sig packets,
maybe because these expired during the whole timeline.

>> As the key causing me problems was very old, I do not have
>> the software at hand that was used to create it, nor it is
>> clear
>
> We removed v3 key support in 2.1 for security reasons.  You
> need to use gpg 1.4 wo work with these keys.

At least my problematic keys were already v4 ones, I cannot say
for sure for similar problem reports on the net, they might have
used v3s.

>> https://unix.stackexchange.com/questions/267844/gpg-secret-key-not-available-when-sec-pub-key-are-in-keyring
>
> That is about the old 2.0 (or a 1.4) version which is end-of-life
> and did not allow to merge secret and public keyblocks.  That
> might be the problem at hand.  2.2 fixes this problem by not
> trying to sync a secring.gpg and pubring.gpg.  The secring.gpg
> is actually not anymore used but the secret parts of the key
> have been moved to the gpg-agent's secret key store.

As the problem might be related to long-time compatibility of
gpg, most of the reports and possible solutions are quite old
and may affect outdated software.

As it seems quite important for some users to decrypt old data
also years after creating it and that seems to fail sometimes,
the probability to have an outdated version in the whole scenario
is nearly 100%. Hence I did not spend much time to figure out
how the problem happened over the years, just took it as granted
and tried to find an easy fix - not recreating all the frames
with some Python opengpg framework as one poster suggested.

hd

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640241




More information about the Gnupg-users mailing list