Generate subkeys based on less secure OpenPGP primary key

Question

I've been reading about the benefits of using OpenPGP subkeys for different machines. Obviously, it's a much safer practice than copying around the same master key between multiple machines (especially laptops).

I'm planning to migrate to the "one subkey per machine" way of managing OpenPGP keys as described here: https://wiki.debian.org/Subkeys

The instructions are pretty clear if you're setting up OpenPGP signing from scratch. However, I've been using a rsa2048 key (DB746BD8) for several years, and ideally I would like to keep the trust and the identity associated with it. Are there any (recent) best-practice guides out there that explain a situation like this? For example, does it make sense (i.e. does it add security) to generate 4096-bit subkeys using a rsa2048 master key? Would it be better to generate a new rsa4096 primary key? Or something completely different?

EDIT

Some additional information about my particular key/situation:

• The key was used primarily for Git commit signing - I do not think it was ever used for encryption, nor uploaded to a keyserver.
• The only time it was "published" was when it was uploaded to the GitHub website, as described here.
• The key has not been certified/signed by anyone.

My goal is to figure out the PGP/GPG setup for the medium to long-term, and so far the plan looks like this:

1. Decide on the primary key to use
   1. Keep the existing rsa2048 primary key DB746BD8
   2. Generate a new primary key (e.g. rsa4096, ecdsa)
2. Generate and distribute new subkeys
3. Upload key to keyservers
4. Potentially use it for encryption, to sign other people's keys etc.

The main question is whether I should go with 1.1. or 1.2. - especially considering that after following 2. 3. and 4., it might become more difficult to later on switch to a new key (?).

Answer 1

You must distinguish between security of your whole OpenPGP key (depends on your primary key) and security of encrypted/signed message (depends primarily on the subkey, but see below).

Primary Key

The primary key itself is obviously not strengthened -- all primary key operations (issuing certifications on other keys, managing user IDs, managing subkeys, issuing revocation certificates) are bound to the primary key. If an attacker gets hold of the primary key (for example, by brute-force attacks that might be feasible in future), he will be able to perform all those tasks. Additionally, the primary key has often set the signing capability bit, thus it can also issue valid certifications (in fact, this is default if you create key pairs in GnuPG).

Signing

The subkeys are used for "day-to-day work": signing and encrypting documents. For signatures, an attacker can easily create a new (and automatically trusted) subkey pair when he gets hold of the primary key, thus there is no actual use in creating a stronger subkey (of course, one could check manually which signing key was used, but this is definitely not OpenPGP best practice and standard).

Encryption

For encryption keys, the situation is different -- once a message was encrypted for a subkey, creating new encryption subkeys is of no use. With other words: an attacker will not be able to decrypt old messages encrypted before he got hold of the secret primary key. As soon as he has access to it, he will be able to issue a new encryption key and intercept messages. Implementations of OpenPGP use the newest valid subkey capable of encryption. In fact, you will not be able to read those messages any more (as you don't have access to the new secret key).

But in both cases (signing and encryption subkeys), you are at least able to realize something's wrong, as the attacker will have to distribute the new subkeys. But you won't realize an attack occured before damage may already have happened.

Wrap Up

There is some use, and as creating a new subkey pair is a cheap and easy task, why not just do so. But for a long term solution, consider phasing out your old key and switching to a new key pair instead. Maybe even consider new ECDSA keys already?