In Linux kernel maintainer PGP guide I don’t understand the section “Back up your whole GnuPG directory”, and it is also asymmetric with the section discussing paperkey.

AFAIK, this should be sufficient:

gpg --output "priv_0.pgp" --armor --export-secret-key

I do 16 of these and then copy those to an USB stick (i.e. one for each hex digit).

#linux #kernel #pgp

not 16 USB sticks, only couple but both have 16 spare copies of the same secret key. and i also have the doomsday printed backup :-)

@duxsco I can pull public keys from keyserver and ownertrust is neither something that cannot be re-created.

Public key restore:

gpg --recv-keys 5107E66D34788A93E3227C903AB05486C7752FE1

@duxsco If I really wanted to backup ownertrust I can e.g. make a mastodon post with the contents :-) it does not contain any secret material. We are talking here about backing up material that can neither be lost nor shared.

@duxsco My “alternative” approach to the one proposed in the guide (I quite strictly follow it otherwise) has a measurable benefit: it is more durable given the 16 spare copies of the secret material.

I’ve been even thinking to send a patch to kernel-pgp-guide.txt and that was sort of grounds to make this post. I think that just packing ~/.gnupg is somewhat dirty approach…

I’d like to also point out that this approach also mirrors on how paperkey use is instructed, so it is not asymmetrical. IMHO, processes should have only asymmetry if you have some very well rationalized explicit reason to do that when it comes privacy and security.

@duxsco The factorized 16x durability increase should be quite true given how wear-leveling algorithms work on memory technology devices. I.e. they should be expected to end up to the slots in NAND storage which are spread nicely and to least used locations.

@duxsco Then you probably can use your own judgement but we are talking about best practices for kernel maintainers and I have hard time to see how dumping ~/.gnupg to a tar would be such.

If you want to back up public keys it is better idea similarly just export them to a separate file (and also ownertrust has an export command).

For Linux the only thing that matters is that the private master key is never stolen and that should be the only single focus of the instructions.

@jarkko it's for the purpose of convenience if you do a lot of cross-signing of other people's keys. It's less common these days, but still done often enough.

@monsieuricon so is there some difference compared to:

gpg --output "$USER-public.pgp" --armor --export $USER
gpg --output "$USER-private.pgp" --armor --export-secret-key $USER
gpg --export-ownertrust > "$USER-ownertrust.pgp"

Not trying to argue against just trying to understand what I’m reading :-)

@duxsco hey i'll check this out thanks! could be useful

@jarkko ultimately, there is no difference. However, if someone asks you to sign their key, you'd have to reimport your [C] key into your keyring, or create a temporary keyring just for this purpose. This is a lot harder to do than to just mount an encrypted storage and set GNUPGHOME.

If you don't do a lot of key signing, this is no big deal, but if you do, then this significantly simplifies the whole process and saves a ton of time.

@monsieuricon BTW, I must have been doing something wrong at the time but I recall sending my public key for wot and https://www.kernel.org/doc/wot/ does not have it. still i've used signed tags as long as I can remember to past.

I recall that I have required amount of blessings for my key (need to sanity check). I guess I need to re-submit the public key, right?

@jarkko oh, that wot render is ancient. I should just redirect that to https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs

@monsieuricon phew, right, it is there, thanks :-) https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs/3AB05486C7752FE1.svg

@jarkko If you click "plain" it should render in your browser:
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/plain/graphs/3AB05486C7752FE1.svg

@monsieuricon right, so it does, thanks!