invalid gpg key revocation

[David Shaw]

On Mar 5, 2012, at 12:12 PM, auto15963931 at hushmail.com wrote:

> I am 99.9% sure no one has gotten access to my machine or my keys. 
> If they had, I have to believe that there would have been more 
> damage done than this, and that does not appear to have happened. I 
> mention the details, which may seem irrelevant, only because 
> sometimes the devil is in the details.  This event has in fact 
> occurred, and I need to figure out how to explain it and prevent 
> it. There was no revocation certificate for the key in question. 
> There has to be another explanation. If this was user error, then I 
> want to find that as well. What can be looked at on the revoked key 
> to see how or under what circumstances it was revoked? Thanks.

A revocation appears as a signature on the key.  Anyone who has (write) access to the key can add such a signature (if it exists).  However, only the holder of the secret key can generate such a signature.  In other words, if you really never made a revocation (many howto documents recommend making one and saving it when you generate your key), and the revocation you found on your key is genuine (if gpg confirms it is revoked), then I recommend you check if someone has access to your secret key.

You can examine the revocation certificate with:

 gpg --export (your key id) | gpg --list-packets

The piece you are interested in will look like this.  It's usually the second packet in an exported key:

:signature packet: algo 1, keyid 7296AD3DA736CEC5
	version 4, created 1330970459, md5len 0, sigclass 0x20
	digest algo 2, begin of digest 74 51
	hashed subpkt 2 len 4 (sig created 2012-03-05)
	hashed subpkt 29 len 10 (revocation reason 0x01 (foobar))
	subpkt 16 len 8 (issuer key ID 7296AD3DA736CEC5)
	data: [2047 bits]

Note the sigclass is "0x20", which is the revocation class.  The keyid would be that of your key (or it's a revocation for someone else, and is not relevant to your key).  "Created" is the epoch timestamp of when the revocation was supposedly generated, echoed in "sig created".  The "revocation reason" is the reason given when generating the revocation:

0 == no reason given
1 == revoked because the key was compromised
2 == revoked because the key was superseded by another key
3 == revoked because the key is no longer used

The string in parenthesis is a human readable note given by the revoker.

Anyway, that's what can be looked at, but - and this is important - virtually all of those fields are settable to whatever the revoker wants to set them to, so you can't trust them.  For example, they could set their clock to whatever date they wanted and make the revocation from that date.  They could give any revocation reason they like, or no reason.  They can put whatever they want to in the string.  What they can't do (modulo serious crypto failure and/or bugs) is generate a revocation without access to the secret key.

David