I want to create a new GPG key with a longer key size.
What are the best ways to replace the key?
My current key is associated with a lot of stuff like GitHub etc.
Should I revoke my old key and sign the new one with the old?
So what's the best way to do it.
-
I'll leave it as a comment as there may be a better answer, but I would revoke the old one and replace it with the new one in each site. You are creating a new pair of keys, so I don't think there's much you can do related with the old one.– sysfiendCommented Dec 16, 2018 at 18:29
-
1Expire the old key... don't revoke it... sign the new key with the old key...– RubberStampCommented Dec 16, 2018 at 20:51
-
@RubberStamp I wrote a text where I explain that I have a new and then my old and new fingerprint. After that I signed this medsage with my old key.– Emil EnglerCommented Dec 16, 2018 at 21:04
-
1There are many methods to the madness... however, I would recommend signing the new key with the old key because the text you've posted may not remain posted for as long as you use the new key. Someone with the old key may only have access to your distributed public keys. Checking the signatures on the new public key will leave no doubt that the old key was your old key. And, I think it's important to have a self-contained solution to this particular problem.... Some people recommend cross-signing old with new and new with old.– RubberStampCommented Dec 16, 2018 at 23:45
-
My text that was signed with my old key has been uploaded on website so I think it should be clear by that. The new key is also on nearly every keyserver by now. (emilengler.com/pgp.html)– Emil EnglerCommented Dec 17, 2018 at 6:10
Add a comment
|
1 Answer
On your question
I see by inspection of your keys that are posted on public key servers, that you have already posted your revocation certificate for your old key. The revocation certificate includes the fingerprint of the new key. So, your method seems acceptable, and probably better than many other attempts at the key rollover process.
Personal key management is mostly an opinion based exercise. Recommendations abound, and some seem better than others. Cross-signing the public keys is probably a better method without resorting to a third party identity tracking service such as keybase.io
It's usually a good idea to revoke keys only when absolutely necessary, such as a lost private key or a compromised key. Modern gpg implementations create a revocation certificate as part of the key generation process. On my Debian Buster system, those certificates are automatically stored in ~/.gnupg/openpgp-revocs.d So, as long as one keeps the revocation certificate, one can revoke a posted public key at will regardless of whether or not one remembers the passphrase or has the private key.
Expiring old keys rather than revoking them is probably a better method, because the expiration date on a pgp key can easily be changed at will and posted to a public key server without permanent repercussions.
Lastly, always keep the old keys. Don't discard the private keys thinking that you won't need them anymore. All old messages encrypted with old public keys will not be accessible without the old private keys.
On public key servers
Anyone can post any public key to a public key server. So, it's not a good idea to blindly trust keys discovered on public key servers. The key servers are also littered with old, compromised, expired, and revoked keys. It's very difficult to figure out or verify that a given key on a key server is the correct and current key for communication with the identity information listed on the key.
The original idea was that people with keys would get together in person-to-person meet-ups called key signing parties to sign each other's keys and build a web of trust. However, key signing parties are not that common and most keys I've come across are simply self-signed with zero other signatures. So, in general practice, the web of trust doesn't work out so well to determine which key belongs to which identity and which key is the most current key.
These problems are a few which keybase.io has been trying to solve. Keybase replaces the person-to-person web of trust with verified identity tracking across third party web services such as Github. However, effective use of keybase requires that one maintain third party accounts on web services that track you. So, online anonymity takes quite a huge hit with keybase use. Some may say it's an acceptable trade off, and some may not wish to accept that trade off.
