keyids in signatures getting corrupted, GPG and/or Debian problem?

[David Shaw]

On Tue, Mar 30, 2004 at 08:24:00PM -0500, Jason Harris wrote:
> 
> I've just noticed some signatures with their keyids changed to
> 0x0910 in the last two bytes.  Both keys I've noticed this on
> so far have been submitted directly to kjsl from different
> machines/users, and I believe both users use GPG. The "mangled"
> keyids were logged upon reception, which I believe rules out HD
> problems with keyserver.kjsl.com, and the recurring 0x0910 pattern
> in the same spot feels like more than just a coincidence.
> 
> [checks for more anomalies]
> Looking for "0910" in my logs, this pattern appears quite
> popular on Debian (maintainer) keys, and some keys have
> been submitted from other keyservers (including directly
> from SKS) as well.
> 
> One example is 0xBDBFE83, which came into kjsl via HKP, and
> two others are 0xE0442D74 and 0x1CDB0FE3, which came via email
> from SKS servers.  The first key I noticed came in via HKP and
> the bogus subkey binding signature was hard to miss:  0x12F506C8.
> 
> [checks more logs]
> Actually, I see this as far back as 2003-10-17 on 0x6A765865
> and 0xACDEB0B3, which came in via HKP from auric.debian.org.

Jason, how on earth did you find this?  Really awesome discovery, and
an interesting problem.  I have a suspicion on how it happens, though
I do not know which program is doing it.  It is unlikely to be GnuPG
or one of the common keyservers for reasons that will be clear in a
moment.

Note that all of the corrupt sigs are v4, plus they seem to always be
a corrupt version of a real sig that has a 101 private subpacket
attached to it (the subpackets that old GnuPGs used to generate for
internal sig caching).  The corrupt version, however, never has the
101 subpacket attached any longer.

What I suspect happens is that some program assumes that the issuer
subpacket is the first subpacket and instead ends up reading the 101
as if it was an issuer.  Since the 101 is 6 bytes long and an issuer
is 8, it ends up reading two bytes over.  The next two bytes, the ones
that end up in the low 16 bits of the keyid are... yep, 0910, which
are the beginning of the genuine issuer subpacket.  09 for 9 bytes
long, and 10 for subpacket type 16 (issuer).  After that, I'm not sure
what else goes wrong - it looks like it keeps reading and fills in the
rest of the keyid field from the remaining 6 bytes of the actual
issuer subpacket.

Anyway, I seriously doubt it's GnuPG or we'd have a zillion bug
reports about this and we don't.  In any event, GnuPG does not assume
anything about subpacket ordering.  I don't think it is pksd either.
I just re-read the subpacket code, and the pksd subpacket code looks
sane to me.  I don't speak OCAML particularly, but the sks subpacket
code looks sane so far as I understand it.

As to what program *is* doing this, I have no idea.  There are other
keyserver types, so one of them could be it.  It also doesn't have to
be a keyserver.  It could just as easily be a OpenPGP program that
doesn't read signatures properly as it could be a keyserver that
doesn't read signatures properly.

Since you saw this frequently on Debian maintainer keys, I wonder if
there is a problem there?  I know the Debian folks have their own HKP
keyserver that isn't pksd or sks, but I don't know anything about the
engine behind it.  Worth a look, but still only a guess of course.

All of that said, I'm not too worried about this.  It's annoying, but
ultimately harmless.  The corrupt sig will not validate (though the
sig itself is actually good, the bad issuer means the key that issued
it will never be found), so it will be ignored.

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 330 bytes
Desc: not available
Url : /pipermail/attachments/20040331/8b94714a/attachment.bin