In reply to @Valodim:stratum0.org
but hey, then again if hockeypuck just does it, it's not worse than what koo has been doing for years, the behavior is patched in most distros, and perhaps he'll change his mind to accept the patch

In reply to @Valodim:stratum0.org
maybe the time is over to design everything around gnupg

In reply to @heiko:mtrx.hkos.cloud
That's right. Here's a list of keyservers that make up the "main" synced pool: https://spider.pgpkeys.eu/sks-peers

In reply to @finlaydag33k:finlaydag33k.nl
I think they wanted to recreate the private key (and from that, then deriving the public keys again).
Seems like they lost their private keys.

Yep. Luckily not all of them. It's amazing how GPG is one of the very few pieces of software (maybe even the only one) that the more I learn about the more confused I get.
I think my error was in thinking that once I exported my privkeys that:

1. Public keys could have been (easily) derived from them, since that's pretty much the first thing you learn when being introduced to the concept of asymmetric cryptography.
2. When importing the privkeys, I specified --keyring thinking that the privkeys would be imported into that keyring but they were imported into the ~/.gnupg/ directory. So when I deleted those keys, I thought I was only deleting them from that directory and not from the supposed keyring I had imported them to.

I think from now on I'm just going to make a directory, set $GNUPGHOME to there, and if I want to move that to somewhere else or just back it up, simply backup / tar that entire directory.

In reply to @forevernoob:matrix.org

Yep. Luckily not all of them. It's amazing how GPG is one of the very few pieces of software (maybe even the only one) that the more I learn about the more confused I get.
I think my error was in thinking that once I exported my privkeys that:

1. Public keys could have been (easily) derived from them, since that's pretty much the first thing you learn when being introduced to the concept of asymmetric cryptography.
2. When importing the privkeys, I specified --keyring thinking that the privkeys would be imported into that keyring but they were imported into the ~/.gnupg/ directory. So when I deleted those keys, I thought I was only deleting them from that directory and not from the supposed keyring I had imported them to.

I think from now on I'm just going to make a directory, set $GNUPGHOME to there, and if I want to move that to somewhere else or just back it up, simply backup / tar that entire directory.

Public keys can be derived from them again (in theory), just not easily.
It's still a deterministic derivation but getting the correct parameters to feed into it is a pain.
The private key itself is probably lost though...

Personally, I'd call upon the might revocation certificate (if you made one) and start with a new key pair, having learned your lessons about backups. :')

In reply to @finlaydag33k:finlaydag33k.nl

Public keys can be derived from them again (in theory), just not easily.
It's still a deterministic derivation but getting the correct parameters to feed into it is a pain.
The private key itself is probably lost though...

Personally, I'd call upon the might revocation certificate (if you made one) and start with a new key pair, having learned your lessons about backups. :')

In reply to @forevernoob:matrix.org
But if one of the inputs is literally a timestamp, then how can one possibly derive a pubkey unless you exactly know the timestamp or are fine with brute-forcing it?
I haven't had to use those revocation certs yet but if I'm not mistaken the revocation certs are also inside the relevant $GNUPGHOME, right?

I do not know where revocation certs are stored.
Mine is ASCII-armored and put mirrored on a few locations that I'm not disclosing. :p

regarding the timestamp bit: That's why I said in theory. XD
Practically infeasible but they can be derived from them. :')
Tho I generally just upload them to a keyserver or my Git repo to have a backup.

Basically I treat my $GNUPGHOME as "disposable".
I should be able to nuke my entire PC then throw it into the Mariana's Trench without my GPG infra being really affected.

In reply to @forevernoob:matrix.org
But if one of the inputs is literally a timestamp, then how can one possibly derive a pubkey unless you exactly know the timestamp or are fine with brute-forcing it?
I haven't had to use those revocation certs yet but if I'm not mistaken the revocation certs are also inside the relevant $GNUPGHOME, right?

I do not know where revocation certs are stored.
Mine is ASCII-armored and put mirrored on a few locations that I'm not disclosing. :p

regarding the timestamp bit: That's why I said in theory. XD
Practically infeasible but they can be derived from them in theory. :')
Tho I generally just upload them to a keyserver or my Git repo to have a backup.

Basically I treat my $GNUPGHOME as "disposable".
I should be able to nuke my entire PC then throw it into the Mariana's Trench without my GPG infra being really affected.

In reply to @finlaydag33k:finlaydag33k.nl

I do not know where revocation certs are stored.
Mine is ASCII-armored and put mirrored on a few locations that I'm not disclosing. :p

regarding the timestamp bit: That's why I said in theory. XD
Practically infeasible but they can be derived from them in theory. :')
Tho I generally just upload them to a keyserver or my Git repo to have a backup.

Basically I treat my $GNUPGHOME as "disposable".
I should be able to nuke my entire PC then throw it into the Mariana's Trench without my GPG infra being really affected.

According to the documentation:

• pubring.gpg (legacy) and pubring.kbx is where the public keys are stored.
• secring.gpg (legacy) and private-keys-v1.d is your private keys
• ropenpgp-revocs.d is your pre-generated revocation certs.

It should in theory be enough to backup these (hint: Have someone more knowledgeable confirm or deny my statement) but I just like to do things manually that way because that way, I can be sure I didn't screw up.