How can I store and manage my GPG key pair securely?

Question

I've taken measures and thoughts on how to securely store and manage my key pair. In the process of it a few questions arose, which I'm not capable of answering yet. My key pair will be used to encrypt passwords and documents of banks, insurances, invoices, photos and the like. All this data is not publicly available. It is stored in a cloud with password restricted access. I'm evaluating right now, which one fits best.

This is how I set up my key pair:

# Generated a key pair in the past, following general tutorials
gpg> list
sec rsa2048/9AB628FC04C23871
    created: 2019-02-29 expires: 2022-02-29 usage: SC
    trust: ultimate    validity: ultimate
ssb rsa2048/17832C40CF826BA9
    created: 2019-02-29 expires: 2022-02-29 usage: E
[ ultimate ] (1). Thomas Kelly <[email protected]>

> gpg --list-keys --with-fingerprint [email protected]
pub    rsa2048 2019-02-29 [SC] [expires: 2022-02-29]
       B69A 8371 FC28 402C C204 82CF 7138 A96B B8F4 C87A
uid         [ ultimate ] Thomas Kelly <[email protected]>
sub    rsa2048 2019-02-29 [E] [expires: 2022-02-29]

> fdisk /dev/sdb # n, 2048, +2G, w
> cryptsetup open --type plain -d /dev/urandom /dev/sdb1 data
> dd if=/dev/zero of=/dev/mapper/data status=progress bs=1M
> cryptsetup close data
> cryptsetup luksFormat /dev/sdb1 # pw ...
> sudo cryptsetup open /dev/sdb1 data
> mkfs.ext4 /dev/mapper/data

Then I went on and exported my keys towards this device, I've created. After I got used to it, that private keys are always a little bit different from another and you can't export your sub-public key, the following questions remained:

1. Are both of the following commands returning the ssb key (17832C40CF826BA9)?

gpg --export-secret-keys 17832C40CF826BA9
gpg --export-secret-subkeys 9AB628FC04C23871

2. Is it fine to remove the key 9AB628FC04C23871 from my system, after I backed it up on the drive, created above?

3. Should I save a revocation certificate with it?

4. This key pair once expired and I changed the expire date. I can't remember correctly, but I've found two additional certificates lying around that seem to be these old expires certificates. I've read that the process of changing the expiring value creates new certificates. Can you confirm this?

5. I want to have two certificate stores like this on different locations. I'd renew the key on a yearly base. Should I use paperkey or the same digital method above?

Answer 1

Are both of the following commands returning the ssb key (17832C40CF826BA9)?

gpg --export-secret-keys 17832C40CF826BA9
gpg --export-secret-subkeys 9AB628FC04C23871

Yes, in addition to other things: The first command exports the full key - the primary key pair (public+secret) and its subkey pair (even though you specified the subkey ID, gpg exports the entire key because of the command used). The second command exports almost the same thing, the only difference being the primary secret key it exports is unusable.

Is it fine to remove the key 9AB628FC04C23871 from my system, after I backed it up on the drive, created above?

Yes. But take care that the output of the first command export-secret-keys is the one you have saved.

Should I save a revocation certificate with it?

If your use case doesn't involve sharing the public key with others so they can encrypt documents to you and/or verify documents you sign, there's no web of trust and hence no reason to be concerned with the revocation certificate.

A revocation certificate is used by importing it to your keyring (you can also revoke any key pair in your keyring using the --edit-key menu) then uploading the revoked key to a keyserver and/or sending it (and the revocation certificate) to any of your contacts with whom you had shared the public key. The certificate itself contains instructions on how to apply it.

I've read that the process of changing the expiring value creates new certificates. Can you confirm this?

Changing expiration dates has no effect on revocation certificates. The only times a revocation certificate is created is when you first generate the key and if you manually generate a revocation with --gen-revoke

I want to have two certificate stores like this on different locations. I'd renew the key on a yearly base.

Given that your use case seems restricted to securing personal data in cloud storage there is little reason to set an expiration date at all. If you ever want to change to a new key, you'll still have to retain the old one (or else unencrypt everything made with the old key then re-encrypt it with a new one).

Should I use paperkey or the same digital method above?

Be advised that if you use Paperkey it saves only the secret key data without any accompanying public key material. The public key will be required when you want to import the secret key to gnupg. The best thing you can do is use a strong password for your private key.

The only thing you might consider is a larger RSA public key. Your current key is 2048-bit the default key size in GnuPG is now 3072-bit. While it is probably far outside the realm of possibility for any entity to factor a 2048-bit RSA modulus, that probably won't remain the case forever.