[107532] in Cypherpunks
Re: PGP Fingerprint
daemon@ATHENA.MIT.EDU (Adam Back)
Fri Jan 15 19:57:42 1999
Date: Sat, 16 Jan 1999 00:33:08 GMT
From: Adam Back <aba@dcs.ex.ac.uk>
To: cypherpunks@cyberpass.net
In-reply-to: <199901150120.CAA02075@replay.com> (message from Anonymous on
Fri, 15 Jan 1999 02:20:14 +0100)
Reply-To: Adam Back <aba@dcs.ex.ac.uk>
Anonymous writes:
> > See the FAQ entry that someone else posted for what is wrong with pgp2.x
> > fingerprints.
>
> Does the problem affect only the 2.x scheme (which is what I thought when I
> posted) or do fingerprints generated by later versions share the same
> affliction?
Version 5.x and later fix the problem for new version keys. You can't
fix the old version keys without breaking them because the fixed
method of generating a fingerprint naturally results in a different
hash.
> Also, is the hash used in key signing for affected versions a complete one
> (i.e., including all necessary info)?
When you are signing a key it doesn't hash the same data, and the
problem doesn't arise in that context, only in the context of
fingerprints, which is bad enough.
> > As far as PGP format goes, adding the length field into the digest would go
> > along way towards fixing it. (Length fields for pgp big int representation
> > is big endian 16 bit word representing length of following big int in
> > bits).
> >
> > Peter Gutmann suggested using the ASN.1 representation for an RSA key, as a
> > more portable way of doing it (compatible with x509).
>
> It's also more general (or maybe that's the same thing you're
> saying): if you make a habit of hashing something you could really
> use to encrypt a message, there's no way you could make a similar
> mistake doing fingerprints even if you're using a different PKC --
> for what that's worth.
I didn't understand that comment.
The problem is a specific problem with the data that is chosen to be
hashed to produce a fingerprint. They did not include the length of
integers, and just jammed the big ints up next to each other in the
hashed data.
Say (for simplicity) that the public exponent was (in hex) 11 and the,
and the public modulus ABCD13. Then the data which is hashed would
be:
ABCD1311 (or 4 consequtive bytes as there are 2 hex digits to a byte).
So the problem arises that you don't fix where the exponent starts in
the format, so you could also interpret that as:
n = ABCD, e = 1311
ie a key with public exponent 1311 and modulus ABCD would have the
same fingerprint.
There are many ways you could fix this, eg:
include include an escaped 00 to mark to begining of the public
exponent (ie real 00 is encoded 00 00, the marker is encoded 00, so
the above would be: ABCD130011, and a key n = AB0023, e = 11 would be
written: AB0000230011, etc)
or simpler prepend the offset of the e in bytes: 03ABCD1311
the pgp5.x fix is something like the last one: include the prepended
bit length of the integers in the hash.
Another fix it is to alter the users definition of a fingerprint:
consider the fingerprint to be the keylength (eg 1024 or 2048) as part
of the fingerprint -- ie never give a fingerprint without also giving
the key length.
Adam
