Message-ID: <4D3564E4.1010203@epointsystem.org>
Date: Tue, 18 Jan 2011 11:01:08 +0100
From: "Daniel A. Nagy" <nagydani@epointsystem.org>
Organization: ePoint Systems Ltd.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP
	certification
References: <4D34F133.3000807@fifthhorseman.net>
In-Reply-To: <4D34F133.3000807@fifthhorseman.net>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig29B4C3D13C4C40618B3DA1EA"
Cc: notmuch <notmuch@notmuchmail.org>
Precedence: list

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig29B4C3D13C4C40618B3DA1EA
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 01/18/2011 02:47 AM, Daniel Kahn Gillmor wrote:
> i believe collisions of the low 64 bits of SHA1 are within reach today,=

> i'd love to be corrected if this is not the case

I'd suggest using the entire fingerprint as a reference and leaving the
creation date out of the fingerprint calculation for v5 for the
following reasons:

Yes, generating two keys with identical long key ID's is feasible (and
not even particularly expensive on 64-bit machines with dozens of
gigabytes of RAM), but generating a new key with the same 64-bit key ID
as an existing key is on the very far end of the realm of feasibility.
Given the dubious gains from success, I would rule out this attack as
impractical.

Another problem with fingerprints and key IDs is that they are generated
over the key and the creation date, meaning that the same key can have
different key ID's. Since the signature subpacket with the reference is
not part of the hashed data, one can change both the key ID and the
reference and keep the signature valid. Again, I don't know what the
practical value of such an attack might be, but just like in the first
case, it creates an odd situation potentially undermining the trust in
the security of the system. When arguing in front of a non-expert judge,
such quirks erode the claims of rock-solid evidence very badly.

The key ID itself (especially the long one) is not a bad idea, however.
It is a nice compromise in the middle of Zooko's triangle (almost
memorable, almost globally unique and almost secure). In order to make
it more useful, I'd suggest using 20-digit decimal identifiers (like
credit card numbers) instead of 16-digit hexadecimal ones.

Regards,

--=20
Daniel


--------------enig29B4C3D13C4C40618B3DA1EA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk01ZOgACgkQ28D1wCI06YWaKACffiStcNXJhiUxxNBCwpXK9Pg2
3LYAnjEnlPZ4Nxb6HrEFihVD72//UIWh
=7Gg2
-----END PGP SIGNATURE-----

--------------enig29B4C3D13C4C40618B3DA1EA--