What does "revoking" a key actually do?

I am currently encrypting some personal information using gpg ( gpgdir actually). I have a copy of my private key printed onto a sheet of paper in the form of a data matrix lest I lose the digital copy of my private key. However, in reading up about encryption best practice I've often come across the notion of "revoking" my key. In gpg , I can generate a revocation key using gpg --gen-revoke KEY , which can later be used to "revoke" my key. But what does that actually mean? And how is it useful? I have found a plethora of information online about how to revoke my key and generate revokation keys, but none on what actually happens when I "revoke" my key. Is this functionality useful if I am the only intended user of the encrypted data?

asked Jan 1, 2016 at 12:36 343 1 1 gold badge 2 2 silver badges 7 7 bronze badges

Dupe of security.stackexchange.com/questions/101445/… and security.stackexchange.com/questions/101189/… is an example. Yes, revocation only matters if you are receiving from or sending to other people; for purely "self to self" use you simply stop using a key if it is (possibly) compromised.

Commented Jan 1, 2016 at 20:06

2 Answers 2

Think of revoking a key as a comment added to the key file. This comment, if present, will tell others users of your key (someone that send you encrypted gpg emails for exemple) that the key have been revoked and that they shouldn't use it !

Revoking a key is only useful when you send it on key servers, to make others know it's revoked.

answered Jan 1, 2016 at 12:43 573 4 4 silver badges 13 13 bronze badges

Gnupg is open source (yeah!) and hence it can be looked up what happens. When you create a revocation certificate for a key i.e. via `gpg --gen-revoke name"

it internally moves through the following functions/key steps

  1. main() in gpg.c (the gpg command line tool) is called, then
  2. parameters parsed and then gen_revoce( const char *uname) in revoce.c is called,
  3. inside then it retrieves the secret and public key for the uname
  4. it then calls make_keysig_packet in sign.c like this

rc = make_keysig_packet( &sig, pk, NULL, NULL, sk, 0x20, 0, opt.force_v4_certs?4:0, 0, 0, revocation_reason_build_cb, reason );

Then in this certificate provided to a keyserver will allow for this (as @WayToDoor phrased) it the comment to the key on the server.

Only the person in possession of the secret private key can sign messsages to be verified with the public key and hence, a revocation is a "sending of a private key signed message, hash of message generated and assymetrically encrypted" kind of thing.

My take on the further thing is that once revoked, the keypair is burned (trustwise worthless).

Therefore it would be smart to have used a subkey to a safer (air gapped) master encryption key, allowing the reissuing of a new working subkey to replace the revoked key, without the need to safe channel wise verify the public key of the new subkey-keypair.