Re: Interesting real world short ID collision
On Wed, 15 Feb 2012 05:32, ds...@jabberwocky.com said: It seems the owner of one went to a keysigning party, and an attendee was rather surprised to find two keys coming back from the keyserver for that ID... At the FSFE we had this surprise regulary with 76B8337A which is used by one of our office folks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Interesting real world short ID collision
As pointed out in Debian bug 659905, on the keyservers, the primary key 171CAA4A (dated 2002) collides (presumably naturally) with a subkey on primary key 1C8BB5A7 (dated 2000). It seems the owner of one went to a keysigning party, and an attendee was rather surprised to find two keys coming back from the keyserver for that ID... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659905 David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Short ID Collision
Dan McGee wrote: On Thu, Dec 29, 2011 at 2:18 AM, John Clizbe j...@enigmail.net wrote: Jerry wrote: It would seem, and this is strictly my own opinion, that if the old pksd servers are dead then there is no logical reason to continue to support them. Just my 2¢. If only all software support decisions were that cut and dried. Oh well... David Shaw committed patches to the 1.4, 2.0, 2.1 branches of GnuPG yesterday afternoon (28-Dec). The change will be in the next release of each branch. Just discovered keyservers are still totally crappy on this front. Check this out when using a subkey ID to try to fetch a key; the following is a request produced by GPGME gpgme_get_key() that returns no matches (note that this is a subkey ID): Subkey lookup, broken in first URL: http://pgp.mit.edu:11371/pks/lookup?op=indexoptions=mrsearch=0x22AD5874F39D989Fexact=on vs. http://pgp.mit.edu:11371/pks/lookup?op=indexoptions=mrsearch=0xF39D989Fexact=on Public key lookup, both work: http://pgp.mit.edu:11371/pks/lookup?op=indexoptions=mrsearch=0x6D1A9E70E19DAA50exact=on vs. http://pgp.mit.edu:11371/pks/lookup?op=indexoptions=mrsearch=0xE19DAA50exact=on This is totally unacceptable in my opinion, why do we have such broken infrastructure that it cannot support a simple lookup like this? thread reference: http://lists.gnupg.org/pipermail/gnupg-users/2012-January/043495.html Thanks for the patch, Dan. Tested with short long key IDs and fpr of my encryption and authentication subkeys on OpenPGP card key 0x435BD034. [Signature key : E2B8 43E8 E65E EF41 27AF A222 2313 315C 435B D034 Encryption key: 8C87 E7D8 63B4 0BA0 CE62 BA8B ABFE 8362 C97A C237 Authentication key: 8841 2F18 79D5 34B8 FA3E CC56 6D59 9CFB B850 79AD] http://keyserver.gingerbear.net:11371/pks/lookup?op=indexoptions=mrsearch=0x8C87E7D863B40BA0CE62BA8BABFE8362C97AC237exact=on http://keyserver.gingerbear.net:11371/pks/lookup?op=indexoptions=mrsearch=0xABFE8362C97AC237exact=on http://keyserver.gingerbear.net:11371/pks/lookup?op=indexoptions=mrsearch=0x88412F1879D534B8FA3ECC566D599CFBB85079ADexact=on http://keyserver.gingerbear.net:11371/pks/lookup?op=indexoptions=mrsearch=0x6D599CFBB85079ADexact=on Works fine. The patch will be in the next release of SKS and until then the patched source may be pulled from: hg clone https://code.google.com/r/johnclizbe-sks-keyserver/ Thanks again for the patch. -John -- John P. Clizbe Inet: John (a) GingerBear DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Cowboy Haiku -- Reflections on Rodeo So many Cowboys. / Round Wrangler butts drive me nuts. / Never enough rope. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Short ID Collision
On Thu, Dec 29, 2011 at 2:18 AM, John Clizbe j...@enigmail.net wrote: Jerry wrote: It would seem, and this is strictly my own opinion, that if the old pksd servers are dead then there is no logical reason to continue to support them. Just my 2¢. If only all software support decisions were that cut and dried. Oh well... David Shaw committed patches to the 1.4, 2.0, 2.1 branches of GnuPG yesterday afternoon (28-Dec). The change will be in the next release of each branch. Just discovered keyservers are still totally crappy on this front. Check this out when using a subkey ID to try to fetch a key; the following is a request produced by GPGME gpgme_get_key() that returns no matches (note that this is a subkey ID): Subkey lookup, broken in first URL: http://pgp.mit.edu:11371/pks/lookup?op=indexoptions=mrsearch=0x22AD5874F39D989Fexact=on vs. http://pgp.mit.edu:11371/pks/lookup?op=indexoptions=mrsearch=0xF39D989Fexact=on Public key lookup, both work: http://pgp.mit.edu:11371/pks/lookup?op=indexoptions=mrsearch=0x6D1A9E70E19DAA50exact=on vs. http://pgp.mit.edu:11371/pks/lookup?op=indexoptions=mrsearch=0xE19DAA50exact=on This is totally unacceptable in my opinion, why do we have such broken infrastructure that it cannot support a simple lookup like this? -Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Short ID Collision
Dan McGee wrote: On Thu, Dec 29, 2011 at 2:18 AM, John Clizbe j...@enigmail.net wrote: Jerry wrote: It would seem, and this is strictly my own opinion, that if the old pksd servers are dead then there is no logical reason to continue to support them. Just my 2¢. If only all software support decisions were that cut and dried. Oh well... David Shaw committed patches to the 1.4, 2.0, 2.1 branches of GnuPG yesterday afternoon (28-Dec). The change will be in the next release of each branch. Just discovered keyservers are still totally crappy on this front. Check this out when using a subkey ID to try to fetch a key; the following is a request produced by GPGME gpgme_get_key() that returns no matches (note that this is a subkey ID): I guess you don't know the degree that SKS from its outset stripped much of the crappy from PKSD. The few flecks of fecal implementation were needed at the time for interoperability -- a nasty practicality of which software writers on the Internet have to be mindful. As for being still totally crappy, the problem only came up in discussion about a week ago. Do you expect us to pull a fix out of our behinds and have it magically applied to all existing keyservers in a week? BTW, it's being discussed on the GnuPG-* lists. NO ONE has opened an issue on SKS snip This is totally unacceptable in my opinion, why do we have such broken infrastructure that it cannot support a simple lookup like this? I'm sorry, did you mean to attach a patch fixing this to this message? Supply a patch, help test it, and shepherd it into a release, or you're just being part of the problem, IMO. Patches for SKS are accepted at sks-de...@nongnu.org. (subscribe first) SKS source is available from: hg clone https://code.google.com/p/sks-keyserver/ (sub)Keys are indexed on short key ID. This was for historical compatibility with PKSD, as this was the lookup mechanism in place at the time. The patch allowing longer lookup IDs has _just_ been applied to Gnupg's git repository -- it's NOT even in the wild yet and you're screaming about SKS not making the change yet. For most of us, this work we do is an unpaid second job, pay us for support and you can adopt your tone of it it being Unacceptable IMO. Until then, contribute or, IMNSHO, plug it. You may wish to glance at http://sks-keyservers.net/status/. The frst release that could have this change in it would be 1.1.3. After almost four months, 14 (actually 12 -- two of those are my public facing development machines out of five) out of almost 80 have converted. You may expect to see similar slow adoption rates with this fix (and other things in 1.1.3). -- John P. Clizbe Inet: John (a) GingerBear DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Cowboy Haiku -- Reflections on Rodeo So many Cowboys. / Round Wrangler butts drive me nuts. / Never enough rope. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Short ID Collision
Jerry wrote: It would seem, and this is strictly my own opinion, that if the old pksd servers are dead then there is no logical reason to continue to support them. Just my 2¢. If only all software support decisions were that cut and dried. Oh well... David Shaw committed patches to the 1.4, 2.0, 2.1 branches of GnuPG yesterday afternoon (28-Dec). The change will be in the next release of each branch. -- John P. Clizbe Inet: John ( a ) Enigmail DAWT org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Q:Just how do the residents of Haiku, Hawai'i hold conversations? A:An odd melody / island voices on the winds / surplus of vowels ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Short ID Collision
Did anyone read about this reported problem with GnuPG and short keys? I found this on SlashDot this morning: http://yro.slashdot.org/story/11/12/27/0044242/gnupg-short-id-collision-has-occurred?utm_source=headlinesutm_medium=email -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Short ID Collision
On 12/28/11 6:13 AM, Jerry wrote: Did anyone read about this reported problem with GnuPG and short keys? There is no problem. We've known for quite a long time that short key ID collisions are possible: that's why you can't rely on a short key ID as a fingerprint. There's room for some healthy debate on whether GnuPG should be sending full fingerprints to query for keys, but honestly, calling this a problem is really overstating things. There's some behavior that some users find less than optimal, but that's not the same as saying there's a bug in GnuPG that can cause crashes, reveal your data, or anything else like that. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Short ID Collision
On Dec 28, 2011, at 6:13 AM, Jerry wrote: Did anyone read about this reported problem with GnuPG and short keys? I found this on SlashDot this morning: http://yro.slashdot.org/story/11/12/27/0044242/gnupg-short-id-collision-has-occurred?utm_source=headlinesutm_medium=email The proper title of the article should have been Easy method for making a OpenPGP short collision re-discovered. Again. To his credit, the original blog poster more or less says that. Unfortunately, as various other sites picked it up, the issue and focus mutated a bit. Short key ID collisions are nothing new. They're obvious, and handling them is built into the system. It's also not hard to make one - just generate keys over and over until you get a collision. On a fast system, that won't take very long at all. Now to the bug, such as it is. Using the key from the blog post, if I do: gpg --recv-keys 70096AD1 I'll get two keys. The reason for that is that I am requesting something ambiguous. There are two keys with that short key ID, so the server (correctly) returns both. It's up to the caller (me) to decide which is the right one, using the web of trust, or whatever means I want to verify keys. The keyserver is just a database, and does not say that a given key is right or wrong. That's not the problem. However, if I do: gpg --recv-keys EC4B033C70096AD1 I'll also get two keys. Even though I gave enough information to specify one of the keys in particular, I still got both. The reason why is due to the history of PGP keyservers. When the GPG side of the keyserver code was written, the server side (a program called pksd) was not capable of understanding anything *other* than the short key ID. Because of this, GPG intentionally truncates all key IDs to their short representation when requesting keys from that type of keyserver. Other keyservers (LDAP) did not have that limitation, and so the longest possible representation is used there. Since that code was written, time has moved on, and the old pksd server is dead and replaced by the sks server, which is capable of understanding more than the short key ID. So given that there aren't any pksd servers to support any longer, it has been suggested (see https://bugs.g10code.com/gnupg/issue1340) that we should do like we do for LDAP, which never had this limitation in the first place, and send the longest key ID we can. It's a reasonable thing to do - if the user gives us 64 bits, use all 64 bits. So is this a security problem? No, for many reasons, most of which were mentioned in the responses to the blog post. Allow me to add one more reason: keyservers aren't capable of saying if a key is the right one or not. They're just a searchable database that anyone can submit to. A person who trusts a particular key is correct just because they found it on a keyserver is fooling themselves. That's what we have a web of trust and/or fingerprint checking for. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Short ID Collision
On Wed, 28 Dec 2011 11:57:40 -0500 David Shaw articulated: On Dec 28, 2011, at 6:13 AM, Jerry wrote: Did anyone read about this reported problem with GnuPG and short keys? I found this on SlashDot this morning: http://yro.slashdot.org/story/11/12/27/0044242/gnupg-short-id-collision-has-occurred?utm_source=headlinesutm_medium=email The proper title of the article should have been Easy method for making a OpenPGP short collision re-discovered. Again. To his credit, the original blog poster more or less says that. Unfortunately, as various other sites picked it up, the issue and focus mutated a bit. Short key ID collisions are nothing new. They're obvious, and handling them is built into the system. It's also not hard to make one - just generate keys over and over until you get a collision. On a fast system, that won't take very long at all. Now to the bug, such as it is. Using the key from the blog post, if I do: gpg --recv-keys 70096AD1 I'll get two keys. The reason for that is that I am requesting something ambiguous. There are two keys with that short key ID, so the server (correctly) returns both. It's up to the caller (me) to decide which is the right one, using the web of trust, or whatever means I want to verify keys. The keyserver is just a database, and does not say that a given key is right or wrong. That's not the problem. However, if I do: gpg --recv-keys EC4B033C70096AD1 I'll also get two keys. Even though I gave enough information to specify one of the keys in particular, I still got both. The reason why is due to the history of PGP keyservers. When the GPG side of the keyserver code was written, the server side (a program called pksd) was not capable of understanding anything *other* than the short key ID. Because of this, GPG intentionally truncates all key IDs to their short representation when requesting keys from that type of keyserver. Other keyservers (LDAP) did not have that limitation, and so the longest possible representation is used there. Since that code was written, time has moved on, and the old pksd server is dead and replaced by the sks server, which is capable of understanding more than the short key ID. So given that there aren't any pksd servers to support any longer, it has been suggested (see https://bugs.g10code.com/gnupg/issue1340) that we should do like we do for LDAP, which never had this limitation in the first place, and send the longest key ID we can. It's a reasonable thing to do - if the user gives us 64 bits, use all 64 bits. So is this a security problem? No, for many reasons, most of which were mentioned in the responses to the blog post. Allow me to add one more reason: keyservers aren't capable of saying if a key is the right one or not. They're just a searchable database that anyone can submit to. A person who trusts a particular key is correct just because they found it on a keyserver is fooling themselves. That's what we have a web of trust and/or fingerprint checking for. It would seem, and this is strictly my own opinion, that if the old pksd servers are dead then there is no logical reason to continue to support them. Just my 2¢. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
