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-boun...@gnupg.org [mailto:gnupg-users- boun...@gnupg.org] > On Behalf Of Robert J. Hansen > Sent: Monday, March 05, 2012 11:27 AM > To: gnupg-users@gnupg.org > Subject: Re: invalid gpg key revocation > On 3/5/12 12:12 PM, auto15963...@hushmail.com wrote: > > I am 99.9% sure no one has gotten access to my machine or my keys. > > 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 wrong > confidence interval. :) > > There are really only a few possibilities here: > > 1. User error. You did it yourself by accident and didn't realize > 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 if > 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-boun...@gnupg.org [mailto:gnupg-users- boun...@gnupg.org] > On Behalf Of David Shaw > Sent: Monday, March 05, 2012 12:40 PM > To: auto15963...@hushmail.com > Cc: gnupg-users@gnupg.org GnuPG > Subject: Re: invalid gpg key revocation > > > On Mar 5, 2012, at 12:12 PM, auto15963...@hushmail.com 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 (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 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 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. > -----Original Message----- > From: gnupg-users-boun...@gnupg.org [mailto:gnupg-users- boun...@gnupg.org] > On Behalf Of Hauke Laging > Sent: Monday, March 05, 2012 12:53 PM > To: gnupg-users@gnupg.org > Subject: Re: invalid gpg key revocation > > Am Montag, 5. März 2012, 18:12:24 schrieb auto15963...@hushmail.com: > > I am 99.9% sure no one has gotten access to my machine or my keys. > > 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 medium > which has been accessible by an insecure environment afterwards > b) the passphrase is secure (random, 80+ bit key space) and has never > 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 responsible. > > > > If they had, I have to believe that there would have been more damage > > done than this, > > It is hard to make good assumptions about the motivation and aims of > unknown people. You don't even know whether the one got access to your > 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 really > 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 what > > 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 faked. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
