On Mar 5, 2012, at 12:12 PM, [email protected] 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
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
