GPG Encryption – How to Renew an Expired Encryption Subkey with GPG

Private keys never expire. Only public keys do. Otherwise, the world would never notice the expiration as (hopefully) the world never sees the private keys.

For the important part, there is only one way, so that saves a discussion about pros and cons.

You have to extend the validity of the main key:

gpg --edit-key 0x12345678
gpg> expire
...
gpg> save

You have to make a decision about extending validity of vs. replacing the subkey(s). Replacing them gives you limited forward security (limited to rather large time frames). If that is important to you then you should have (separate) subkeys for both encryption and signing (the default is one for encryption only).

gpg --edit-key 0x12345678
gpg> key 1
gpg> expire
...
gpg> key 1
gpg> key 2
gpg> expire
...
gpg> save

You need key 1 twice for selecting and deselecting because you can extend the validity of only one key at a time.

You could also decide to extend the validity unless you have some reason to assume the key has been compromised. Not throwing the whole certificate away in case of compromise makes sense only if you have an offline main key (which IMHO is the only reasonable way to use OpenPGP anyway).

The users of your certificate have to get its updated version anyway (either for the new key signatures or for the new key(s)). Replacing makes the key a bit bigger but that is not a problem.

If you use smartcards (or plan to do so) then having more (encryption) keys creates a certain inconvenience (a card with the new key cannot decrypt old data).

When it comes to DEB packages and repositories, we're talking about explicitly creating a signature. This is different to encrypting and signing a message for a known recipient key. In that case, gpg uses the receiver's key preferences, in combination with your own local preferences to work out a suitable algorithm choice

Unfortunately, there are not much options available for stand-alone signing right now. Even in GPG-2, there is only an option to disallow a cipher algo, but no option to disallow a digest (signing) algo.

Thus, the only thing you can do is explicitly to define a fixed digest (signing) algo in your preferences. Because that is what will be used, when the debian tooling invokes your local GPG installation to make the signatures. Obviously, this has the downside to interfere with the automatic choice of a signing algo; which means, after setting that option, a receiver only capable of SHA1 will no longer be able to verify your signatures.

Anyway, set the following to your ~/.gnupg/gpg.conf

digest-algo SHA256

Probably you should also place a personal preference list there, which influences the default when creating new keys (but as such does not immediately solve the problem at hand -- it won't hurt either)

personal-digest-preferences SHA512,SHA384,SHA256,SHA224
default-preference-list SHA512,SHA384,SHA256,SHA224,AES256,AES192,AES,CAST5,3DES,BZIP2,ZIP,ZLIB,Uncompressed

Regarding SHA1 and 3DES, these are the lowest common denominator for the PGP protocol, and thus hardwired into the software. They are automatically added at the end of your preference list, in order to ensure interoperability with other (weak) implementations of the protocol.

See Section 13.2 of RfC4880

Since SHA1 is the MUST-implement hash algorithm, if it is not explicitly in the list, it is tacitly at the end.

Moreover, SHA1 is still the only algorithm used/allowed to generate a V4 Fingerprint (See Section 12.2)

Well, it might be time to move on, but there is not much we (users) can do, as long as the standard is not upgraded...