Mailing List Archive

On Wed, 26 Jan 2022 08:15, Mogens Jensen said:
> As of GnuPG (LTS) version 2.2.33, what is the recommended way to backup
> your GPG private keys on a Linux system?

For just the private keys you can tar up the private-keys-v1.d
directory, encrypt it with gpg (you might want to use a password (-c)
then). But such a backup has no public keys and they can't be
re-generated from the backup-ed private keys. However, the other data
below ~/.gnupg is not highly sensitive can can be part of the regular
backup.

> 1. Backing up the entire ~./gnupg directory?

That is of course a working option but recall that the data has the
private keys and you should encrypt it.

> 2. Exporting only the keys?
>
> $ gpg --armor --export-secret-keys >gpg-key-backup.asc

That is possible, but, frankly, the OpenPGP format for encrypted private
keys is not as strong as it should be - thus you better add an
additional encryption layer. The actual problem here is that you need
to provide the passphrase for each key.


Salam-Shalom,

Werner

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

On Wed, 26 Jan 2022 08:15, Mogens Jensen said:
> As of GnuPG (LTS) version 2.2.33, what is the recommended way to backup
> your GPG private keys on a Linux system?

For just the private keys you can tar up the private-keys-v1.d
directory, encrypt it with gpg (you might want to use a password (-c)
then). But such a backup has no public keys and they can't be
re-generated from the backup-ed private keys. However, the other data
below ~/.gnupg is not highly sensitive can can be part of the regular
backup.

> 1. Backing up the entire ~./gnupg directory?

That is of course a working option but recall that the data has the
private keys and you should encrypt it.

> 2. Exporting only the keys?
>
> $ gpg --armor --export-secret-keys >gpg-key-backup.asc

That is possible, but, frankly, the OpenPGP format for encrypted private
keys is not as strong as it should be - thus you better add an
additional encryption layer. The actual problem here is that you need
to provide the passphrase for each key.


Salam-Shalom,

Werner

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

On 26/01/2022 16:14, Werner Koch via Gnupg-users wrote:
> On Wed, 26 Jan 2022 08:15, Mogens Jensen said:
>> 1. Backing up the entire ~./gnupg directory?
>
> That is of course a working option but recall that the data has the
> private keys and you should encrypt it.

If i may interject, arn't the private keys already stored encrypted[1]
on disk? The first encryption ought to be already secure enough.

allthebest,

Max



[1] even encrypted by the same program, gnupg; so if there is an
encryption flaw inside it, encrypting the data with the same program
again wouldn't help.

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

Werner Koch via Gnupg-users wrote in
<87mtjiil6k.fsf@wheatstone.g10code.de>:
|On Wed, 26 Jan 2022 08:15, Mogens Jensen said:
|> As of GnuPG (LTS) version 2.2.33, what is the recommended way to backup
|> your GPG private keys on a Linux system?
|
|For just the private keys you can tar up the private-keys-v1.d
|directory, encrypt it with gpg (you might want to use a password (-c)
|then). But such a backup has no public keys and they can't be
|re-generated from the backup-ed private keys. However, the other data
|below ~/.gnupg is not highly sensitive can can be part of the regular
|backup.
|
|> 1. Backing up the entire ~./gnupg directory?
|
|That is of course a working option but recall that the data has the
|private keys and you should encrypt it.
|
|> 2. Exporting only the keys?
|>
|> $ gpg --armor --export-secret-keys >gpg-key-backup.asc
|
|That is possible, but, frankly, the OpenPGP format for encrypted private
|keys is not as strong as it should be - thus you better add an
|additional encryption layer. The actual problem here is that you need
|to provide the passphrase for each key.

And there is this neat trick with the removed private master key,
in a file headlined "subkey howto" somewhere on a Debian server.

This is how i do it --- i even use three different PGP home
directories, ~/sic/.pgp on an always unmounted encfs volume, that
has the private master key, and on a mounted-as-long-as-LID-is-up
~/sec.arena/pgp{,-nosecrets}.git encfs volume (all residing on a
LUKS partition):

#@ ~/.gnupg/gpg.conf a.k.a ~/sec.arena/pgp.git/gpg.conf
#@ For GPG v1.
#@ This contains a secring with a mutilated private key, which can be used
#@ for creating signatures, but which cannot be exported or whatever.
#@ It also has a different password than the true and full private key.


#@ ~/sec.arena/pgp-nosecrets.git/gpg.conf
#@ For GPG v1.
#@ No secring at all, only the public key for encryption, e.g.:
#@ gpg --homedir="${HOME}/sec.arena/pgp-nosecrets.git" < IN > OUT

I always write that verbose because i have no idea of all this and
since it is so far off my "normal life" i tend to forget what this
is all about very soon; "ewig und drei Tage" ("everlasting and
three days") was a common idiom of my Grandma.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

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

* 2022-01-26 08:15:30+0000, Mogens Jensen via Gnupg-users wrote:

> As of GnuPG (LTS) version 2.2.33, what is the recommended way to backup
> your GPG private keys on a Linux system?
>
> 1. Backing up the entire ~./gnupg directory?

Yes. Just normal backup is good and often enough. Just store the backups
at least as safe as your ~/.gnupg directory.

Very old backups may not be fully compatible with newer versions of
GnuPG. Although GnuPG may have some automatic mechanism to convert from
older file formats.

> 2. Exporting only the keys?

The OpenPGP export format is good too because it does not depend on the
current file format. The export format should be compatible with almost
any OpenPGP implementation. If you backup important long-term keys
outside your normal computers I suggest using the export format: "gpg
--export-secret-keys".

--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462

On Thu, 27 Jan 2022 08:25, Teemu Likonen said:

> outside your normal computers I suggest using the export format: "gpg
> --export-secret-keys".

Note that there is an attack on the private key export format. Thus my
recommendation not to rely on this unless you can make sure that the
exported keys in the backup have not been modified. The problem here is
that the public parts of the encrypted private parts are not
authenticated and by modifying the public parts and tricking the user to
import such a modified backup, information about the secret key can be
revealed.

GnuPG's internal format to store the private key is not affected by this
problem because the public parameters are authenticated.


Salam-Shalom,

Werner


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

On 2022-01-28 at 08:18 +0100, Werner Koch wrote:
> The problem here is that the public parts of the encrypted private
> parts are not authenticated and by modifying the public parts and
> tricking the user to import such a modified backup, information about
> the secret key can be revealed.

I'm a bit confused by this claim, Werner.

Say you fetch your key backup from Mallory's safe, and take it to your
basement. The import wouldn't be an online process with timing leaks.
The feedback that Mallory might get is his friend at the door blaming
him for providing a tampered backup.

The private part wouldn't be modifiable without the passphrase. And if
the public part was changed, it would no longer match the secret part
(or it could match the secret key, but have a different creation
timestamp and be effectively a different key than the one you were
expecting to restore), so it should get rejected. And pubkey with a
prime of 1 shall be invalid.
Some preferences could be added/stripped from the public key
(undesirable), but that's far from revealing information from the
secret key.

Could you elaborate? I am surely missing something.

Best regards



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

On Sun, 30 Jan 2022 04:25, Ángel said:

> Could you elaborate? I am surely missing something.

Unfortunately I can't tell you any details because the paper has not yet
been published. The attack is not easy to mount but it is not entirely
academic. It affects the standard for sending private keys and not any
specific implementation.

The OpenPGP DT knows about it for nearly a year but they are busy
nitpicking on details of the 4880bis and spending way to much time
handling and discussing editorial issues and non chartered features.


Shalom-Salam,

Werner


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