Mailing List Archive

On Tue, 17 Sep 2019 06:51, me@halfdog.net said:

> Regenerating private keys is mathematically trivial but tool-wise
> a little tricky. It seems that quite some people were troubled

What's wrong with

gpg --import backup-of-private-key.gpg

the private key include the entire public key.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Werner Koch writes:
> On Tue, 17 Sep 2019 06:51, me@halfdog.net said:
>
>> Regenerating private keys is mathematically trivial but tool-wise
>> a little tricky. It seems that quite some people were troubled
>
> What's wrong with
>
> gpg --import backup-of-private-key.gpg
>
> the private key include the entire public key.

That it won't work in some circumstances, e.g. those cited the
line below those you have quoted (fixing the wrong private/public
you got obviously right anyway drafting your reply):

"""Regenerating public keys is mathematically trivial but tool-wise
a little tricky. It seems that quite some people were troubled
by this problem due to different reasons (I not attempted to
confirm all of these):

* Using (old) backups of keys for decrypting with only private
key available.
* Smartcards with only private key on them
* Forensic scenarios
"""

Therefore some exports (or copies of old secring.gpg) just do
no include the public key, otherwise import would be trivial.
Usually problem reports of other users look like [0] and do not
contain any direct solution, only workarounds e.g. "get your
missing public key from somewhere else".

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
if I only stored away the secring or an explicit private key
export, therefore I cannot find out what exactly caused the
situation, just that for me as for many others import or decrypt
does not work any more.

I believe that decryption worked with older gpg1 versions and
this kind of key data but I do not remember when and the gpg1
software version used back then.

hd

[0] https://unix.stackexchange.com/questions/267844/gpg-secret-key-not-available-when-sec-pub-key-are-in-keyring


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue, 17 Sep 2019 11:09, me@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.

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

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


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Werner Koch writes:
> On Tue, 17 Sep 2019 11:09, me@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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users