[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnupg-users
Subject:    Re: invalid gpg key revocation
From:       David Shaw <dshaw () jabberwocky ! com>
Date:       2012-03-05 18:40:09
Message-ID: 55D12FC6-9D54-41FB-BF48-76A4F73E6043 () jabberwocky ! com
[Download RAW message or body]


On Mar 5, 2012, at 12:12 PM, auto15963931@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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


[prev in list] [next in list] [prev in thread] [next in thread]