Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On May 29, 2012, at 3:34 PM, Daniel Kahn Gillmor wrote: > On 05/29/2012 02:18 PM, David Shaw wrote: >> The reason I bring it up is that using the v3 key attack, 64-bit key IDs >> have no particular benefit over 32-bit IDs for intentional collisions (i.e. >> an attacker generating a key with the same key ID as the victim in order to >> confuse matters and/or steal traffic). It's just as easy to forge 64 bits >> as it is to forge 32… > > Right, which is why gpg should default to not processing/accepting v3 > keys either, frankly. The window for v3 being deprecated started long > ago. If we expect people to rely on gpg for any sort of key management, > it ought to have reasonably safe and sane defaults. While I don't think the world is ready for a change in default visibility from 32 to 64 bit key IDs, I am in favor of this by default. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On 05/29/2012 02:18 PM, David Shaw wrote: > The reason I bring it up is that using the v3 key attack, 64-bit key IDs have > no particular benefit over 32-bit IDs for intentional collisions (i.e. an > attacker generating a key with the same key ID as the victim in order to > confuse matters and/or steal traffic). It's just as easy to forge 64 bits as > it is to forge 32… Right, which is why gpg should default to not processing/accepting v3 keys either, frankly. The window for v3 being deprecated started long ago. If we expect people to rely on gpg for any sort of key management, it ought to have reasonably safe and sane defaults. dropping v3 unless explicitly overridden, and defaulting to displaying 64-bit keyids in the places where it must show keyids seems like it would be a reasonable choice. Yes, it might break compatibility with some existing docs. Those docs are likely to be out-of-date, and many of them may well encourage bad practices anyway to someone who doesn't understand what they're seeing. fwiw, i agree with Werner that we should avoid displaying keyids to users wherever we can -- they're not human-friendly identifiers. But if we're going to expose them, we should be exposing them in ways that at least make them somewhat collision-resistant. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On May 29, 2012, at 2:05 PM, Sam Whited wrote: > On Tue, May 29, 2012 at 1:47 PM, David Shaw wrote: >> On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote: >> >> What is your concern here, though - accidental or intentional collision? > > Certainly both; while accidental collision isn't probable, 32-bit IDs > aren't exactly collision resistant either. This, coupled with the fact > that a nice GPGPU is now relatively inexpensive makes brute forcing > collisions not only possible, but relatively easy for a determined > attacker. The reason I bring it up is that using the v3 key attack, 64-bit key IDs have no particular benefit over 32-bit IDs for intentional collisions (i.e. an attacker generating a key with the same key ID as the victim in order to confuse matters and/or steal traffic). It's just as easy to forge 64 bits as it is to forge 32… David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On Tue, May 29, 2012 at 1:47 PM, David Shaw wrote: > On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote: > > What is your concern here, though - accidental or intentional collision? Certainly both; while accidental collision isn't probable, 32-bit IDs aren't exactly collision resistant either. This, coupled with the fact that a nice GPGPU is now relatively inexpensive makes brute forcing collisions not only possible, but relatively easy for a determined attacker. —Sam -- Sam Whited pub 4096R/FB39BCF7EC2C9934 SamWhited.com s...@samwhited.com 404.492.6008 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote: > On 05/29/2012 11:35 AM, Werner Koch wrote: >> Use >> >> gpg --keyid-format long --decrypt sensitive_file.gpg >> >> to see the non-abbreviated key ID as stored in the file. Use this to >> find the key on a server, etc. > > i've seen a lot of these mistakes where people seem to think that 32-bit > keyids are somehow collision-resistant. For example: > > https://lists.ubuntu.com/archives/uds-announce/2012-May/000234.html > > Perhaps GnuPG should change the default of --keyid-format from "short" > to "long"? certainly, the 64-bit keyID itself is not as > collision-resistant as the full fingerprint, but it does raise the bar > for an attacker (and discourages users from just parrotting the 32-bit > keyid if they don't understand what they're looking at). > > I think switching the default to "long" would be on balance a Good Thing. > > What do other people think? I think that it would bring more confusion than benefit, unfortunately. There is a significant amount of documentation (and even code) that uses OpenPGP in terms of 32-bit key IDs, and if that if we were to change, we'd cause all sorts of problems. Defaults should be conservative. That doesn't mean we can't start encouraging people to use 64-bit IDs, but I don't expect it to be a quick process. What is your concern here, though - accidental or intentional collision? David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On 5/29/12 11:51 AM, Daniel Kahn Gillmor wrote: > Perhaps GnuPG should change the default of --keyid-format from "short" > to "long"? Hurts interoperability. Once someone learns the process on PGP or BouncyCastle or [insert OpenPGP implementation here], they're going to want to take those same skills over to GnuPG. Those other implementations overwhelmingly display short key IDs; if they come to GnuPG expecting short key IDs and see long ones, we'll see a sea of questions of "why did my key ID change when I imported it from PGP to GnuPG?" (Hmm. "Interoperability" might be the wrong word, but there's not a good term for "skill portability.") Anyway, it's not that I think this change is _a priori_ bad, but in order to diminish the skill portability issues (both in moving from other implementations to GnuPG and from GnuPG to other implementations) I think this change should not be implemented without some coordination with the other major implementations. Honestly, this seems like something to bring up to the IETF WG. The RFC already has a plethora of implementation recommendations: adding an implementation recommendation of "use long key IDs when possible" seems to be an entirely reasonable addition. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2012-05-29 17:51, Daniel Kahn Gillmor wrote: > On 05/29/2012 11:35 AM, Werner Koch wrote: ... > I think switching the default to "long" would be on balance a Good > Thing. > I agree, and don't see much of a reason not to use a long KeyID rather than a short one. However, please note that search for subkeys using the long keyID format is only supported in SKS since version 1.1.3 announced 11 April 2012 (lookup for parent/regular public keys is supported before that), so before implementing such a change I'd like to consider setting the minimum requirement for the SKS pool[0] to 1.1.3. Technically that is a rather easy change, however, it'd currently reduce the number of available servers to about 15 from 61 in the pool with min version requrement of 1.1.0 (current). So might have to give the keyserver administrators some time to upgrade before that. (cross posting to sks-devel) [0] http://sks-keyservers.net/status/ - -- - Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk - Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws - This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is now available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ - Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJPxPWcAAoJEBbgz41rC5UIzLIQAIoftDYMBEl4N3MRO2ucrNt2 qG2t3xMTQlRv3hmf5mqqIYmK6zRvmKmjBdw7WPdIo83xY0+WBRiOSQEkSOM86Ed3 WhgYOlaNFNaPHrYB6v1yL6C9PkqXkv1IxFP8x12CjsfgnV5AWpQWDJIXHquD2C1K lbwX0+c/VnsN9LltBRvNqdrO/Le/HhVZyeMd6CoJYkp7aHdPCnmxsXi3DHqr78Bw FFP4ABWllE9RgAJN8ekvM7j8CedktwPXtkjGjoQw7+13p2xP3qd6E5ggTfFaHAQ5 HibxKBFZZmkcO3JSOmO7SF+63IKYPptu2uJ/p28ZFnExO+8HelU8m5iga+OXQqFC bw/qKbiWLcQxGMD2R+5ZyXOOCaJeg0vNwyt3YAGo09WJ7OJWYGne1A2h2vB/lxNS V09xjkNEbLQqQ1Kt1cLLZ5p/vxwrZ/136uyGhgmxX8gFVN9GBG31VymeV7pVqG11 21i0wqCW1KvW70b+D6vgQIxzTxUE1twc5suRi01bjDnAn0Kkl3mtZjPEI9kRRyfB W6+6zGtJgAr9AMPakAxhey39fTu8bS+dsRYS2ztrhhC/XfaxdreOrKpdKKqaUbEF zKddYjo+XarW27vubpCkIS3hnWd8nn/jBRuAwkKUC/qiSwvKKsvV8Y2FJt0FjLqI suwhmsLwpD1I5U0uMH6D =2Hk4 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
Am Di 29.05.2012, 11:51:06 schrieb Daniel Kahn Gillmor: > I think switching the default to "long" would be on balance a Good Thing. A smaller change which should "solve" most of these problems could be to change the error message. If gpg is operating with the short format then a respective hint could be added: "gpg is currently operation with short ID format. This prevents short ID collisions from being easily detected. You may want to run gpg with the option '--keyid-format long' to check the long IDs." Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On 05/29/2012 11:35 AM, Werner Koch wrote: > Use > >gpg --keyid-format long --decrypt sensitive_file.gpg > > to see the non-abbreviated key ID as stored in the file. Use this to > find the key on a server, etc. i've seen a lot of these mistakes where people seem to think that 32-bit keyids are somehow collision-resistant. For example: https://lists.ubuntu.com/archives/uds-announce/2012-May/000234.html Perhaps GnuPG should change the default of --keyid-format from "short" to "long"? certainly, the 64-bit keyID itself is not as collision-resistant as the full fingerprint, but it does raise the bar for an attacker (and discourages users from just parrotting the 32-bit keyid if they don't understand what they're looking at). I think switching the default to "long" would be on balance a Good Thing. What do other people think? --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
