invalid gpg key revocation

auto15963931 at auto15963931 at
Tue Mar 6 19:36:07 CET 2012

Okay, there are a lot of responses, and I need to get to the bottom 
of this as quickly as possible, but I also want to do so 
methodically.  Let me respond to the points raised as best I can 
until this is resolved. 

> -----Original Message-----
> From: gnupg-users-bounces at [mailto:gnupg-users-
bounces at]
> On Behalf Of Robert J. Hansen
> Sent: Monday, March 05, 2012 11:27 AM
> To: gnupg-users at
> Subject: Re: invalid gpg key revocation

> On 3/5/12 12:12 PM, auto15963931 at wrote:
> > I am 99.9% sure no one has gotten access to my machine or my 
> Whenever anyone ascribes 99.9% certainty to a belief, my knee-jerk
> reaction is to think the only 99.9% certainty is they've got the 
> confidence interval.  :)
> There are really only a few possibilities here:
> 1.  User error.  You did it yourself by accident and didn't 
>     it.
> 2.  Someone has access to your private key and passphrase and
>     revoked your user ID.
> 3.  GnuPG has a critical, showstopper bug.
> 4.  The algorithm you used has a critical cryptographic flaw that
>     someone exploited.
> I can't tell you how likely #1 or #2 are, but #s 3 and 4 both 
seem like
> fairly low-probability events.  I would begin by checking to see 
> either #1 or #2 are in fact the case.  If you want me to believe 
#3 or
> #4 are the case, you're first going to have to convince me it 
could not
> have been #1 or #2.

I agree that user error is a possibility, but I am not certain how 
to prove it. I can reproduce another public key just like the one 
that was revoked except using a different name. I can use the same 
program, same method and same machine, and I can post it to an 
email here just as I posted it to the other site I mentioned. This 
way you can see the result plainly. At least we can determine 
whether the key is getting made correctly.

I have to reiterate, but not eliminate the posibility, that someone 
having access to this machine is extremely unlikely.  This machine 
is not in a public place or workplace. It is at my home, and I do 
not have any guest accessing it. My family members would not, and 
could not do this anyway. It is fully encrypted and well protected. 
 I have a good deal of anti-malware and firewall protection.  
Impossible, no; improbable, highly so.

> -----Original Message-----
> From: gnupg-users-bounces at [mailto:gnupg-users-
bounces at]
> On Behalf Of David Shaw
> Sent: Monday, March 05, 2012 12:40 PM
> To: auto15963931 at
> Cc: gnupg-users at GnuPG
> Subject: Re: invalid gpg key revocation
> On Mar 5, 2012, at 12:12 PM, auto15963931 at wrote:
> >  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 
> 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 
> 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

Looking at this instruction, I think you assume that I have 
imported the revoked key onto my keyring. I have not done so.  On 
my keyring is the valid key, which is not revoked.  The revoked key 
appears to be on a keyserver.  When I do a search and view the 
result online, I can see my key ID number and user ID plainly 
identifying this key as having now been revoked.  I have not 
imported it. The really wierd part is that I never publicly put it 
on a server myself. I guess someone else did that as part of this 
malice after I put it on a website for importing.  I am reluctant 
to import the bad one because it might mess up the good one. So, I 
am not sure how to look at the certificate with your command, which 
appears to require that I export it. Does it not?
> 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 
> 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 
> 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 
> 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 
> serious crypto failure and/or bugs) is generate a revocation 
without access
> to the secret key.

> -----Original Message-----
> From: gnupg-users-bounces at [mailto:gnupg-users-
bounces at]
> On Behalf Of Hauke Laging
> Sent: Monday, March 05, 2012 12:53 PM
> To: gnupg-users at
> Subject: Re: invalid gpg key revocation
> Am Montag, 5. März 2012, 18:12:24 schrieb 
auto15963931 at
> > I am 99.9% sure no one has gotten access to my machine or my 
> IMHO that requires at least that
> 1) you have generated the key in a secure environment, i.e.
> 	a) booted from a safe medium
> 	b (really) validated the content of the medium
> 2) and either
> 	a) you have made sure that the key has never been written to a 
> which has been accessible by an insecure environment afterwards
> 	b) the passphrase is secure (random, 80+ bit key space) and has 
> been used in an insecure environment
> 3) the key has been generated by a well known software about 
which no
> respective bugs (like the SSL key space disaster) are known
> Can you confirm that?

I have generated the key on my main PC, which, as far as I know, 
and I am no slouch when it comes to security (and, no problem, :) I 
do not think you suggested I am). My machine is well protected with 
firewall and antimalware.  It is always, separated from internet, 
no; as this email indicates. I do not make documents on one 
machine, save it to CD and move media to another machine for using 
on internet.  Frankly, if I had to do that, I would consider 
moving. :)  If my machine has been compromised in any way, I need 
to ascertain that much and fix it. Still, I find this possibility 
extremely unlikely in all honesty.

This key has been generated by a well know software, whose name I 
will withhold at this point until I appear to have eliminated the 
issue of user error. If I am to blame, I do not want to brandish 
someone else's name unfairly.  Nevertheless, I am perfectly willing 
to use a different software to try to reproduce another key, and I 
am perfectly willing and capable of using the CLI of gnupg if need 
be; in this way I can be sure that the program itself is not 
> > If they had, I have to believe that there would have been more 
> > done than this,
> It is hard to make good assumptions about the motivation and aims 
> unknown people. You don't even know whether the one got access to 
> private key by planned action or rather incidentally.
> Even if it was planned the motivation may have been to show you 
your limits
> (or the other one's superiority), not to cause damage (=becoming 
> criminal).
Granted that motivations are difficult to ascertain, but this is no 
small event. I have created a key in a manner that I believe is 
secure. If it can be revoked, what else can be done with it? I need 
to figure out what happened and prevent it. If I am to blame, I 
need to fix my mistake so that it does not happen again. This is 
borderline to identity theft.
> > What can be looked at on the revoked key to see how or under 
> > circumstances it was revoked?
> I do not know whether there is any data in such a revocation 
signature that
> differs from system to system. Even the timestamp can easily be 

More information about the Gnupg-users mailing list