CryptNET Key Server

Logged In: YES
user_id=52593

I believe that your key is corrupt.

The difference in the hashed data:

bash-2.05b$ diff /tmp/cks.results.txt /tmp/gnupg.results.txt
1c1,2
< 98
---
> 99
> 00
173,174c174
< 29
< B4
---
> 29

GnuPG prepends the 0x99 and 0x00 bytes that your key does
not have to your key material before hashing it.

Your key's actual first bytes:

bash-2.05b$ hexdump -x /tmp/key.bin
0000000 ab98 3c04 07d5 012b

Normal key material should look like this:

bash-2.05b$ hexdump -x /tmp/key2.bin
0000000 0099 038d ef36 faa7

Key 2 would have the prefix bytes that GnuPG is actually
hashing, 0x99 followed by 0x00.

I don't think it's really a good idea to hash data that is
not the data being presented. GnuPG is non compliant with
the standard in this regard if I'm not mistaken about what's
going on here. Signatures on your key may be invalid if
made with anything other than GnuPG because the hash in the
signature will not be made with altered data. You should
edit the first two bytes of your key ,changing them to the
standard prefix, to recover it.

If your key has been through your DNS software, you may want
to double check it as a possible source of the corruption.
Perhaps an old GnuPG keyring is around on the machine you
generated the key on with the proper prefix, or perhaps this
was done by an experimental or CVS copy of GnuPG.

Let me know if you need help to recover the key.

Logged In: YES
user_id=52593

I need to look at this more closely, but perhaps your key is
corrupt:

00000000 98 ab 04 3c d5 07 2b 01 05 00 ba 89 48 11 e7 e9

I have never seen a key that did not start with 0x99, that I
recall.

The difference:
0x99: 01111110
0x98: 01111101

Did you generate this key w/ gnupg? I generated a RSA only key
just to check and it was 0x99....

I don't think gnupg ever used the new packet format for v3 back
compat. I haven't had lots of time to look at this, I will
try and spend some more and get it resolved before a
possible release this weekend.

hmmm.... I will crack open the gnupg source and put some
echo in there to get a list of the bits it's hashing.
Clearly we are hashing different content. I wonder though
if the content is bad to begin with.

Logged In: YES
user_id=618664

I'm reopening, because something seems weird.

First I ran into the last-key-is-ignored bug, but when I
exported the key twice, I now get this:

jas@dopio:~$ cks_import -v /tmp/skey.bin
VERBOSE
Processing...

Processing /tmp/skey.bin
9765 C65E D63E 175D 037F&nbsp;&nbsp;C959 15D8 F4FA 8686 5801
Final Results:

Total Public Keys Processed: 1
Total Public Keys Imported: 1
Total Public Keys Updated: 0
Total Public Keys Duplicate: 0
Total Public Keys Rejected: 0
Total Pubkey Keys Failed on Error: 0

jas@dopio:~$

Notice the keyId 8686 5801, where does it come from? Here's
what gpg thinks:

jas@dopio:~$ gpg /tmp/skey.bin
pub 1280R/B565716F 2002-05-05 Simon Josefsson
<simon@josefsson.org>
uid Simon Josefsson <jas@extundo.com>
sub 1280R/4D5D40AE 2002-05-05 [expires: 2004-10-18]
pub 1280R/B565716F 2002-05-05 Simon Josefsson
<simon@josefsson.org>
uid Simon Josefsson <jas@extundo.com>
sub 1280R/4D5D40AE 2002-05-05 [expires: 2004-10-18]
jas@dopio:~$

Searching for B565716F on the web interface doesn't work.

Searching for 8686 5801 does, try it remotely on my system
to see what it output -- something about "Unknown signer".

Logged In: YES
user_id=52593

[vab@hewson vab]$ gpg --export B565716F >>/tmp/skey.bin
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more
information
[vab@hewson vab]$ /home/vab/devl/cks/src/cks_import
/tmp/skey.bin
Processing...

Processing /tmp/skey.bin
Final Results:

Total Public Keys Processed: 1
Total Public Keys Imported: 1
Total Public Keys Updated: 0
Total Public Keys Duplicate: 0
Total Public Keys Rejected: 0
Total Pubkey Keys Failed on Error: 0