Re: getting an encrypted file to show what public key was used
On Tue, May 29, 2012 at 11:28:36AM -0400, Robert J. Hansen wrote: This goes to underline the importance of proper certificate validation. If I have the sequence of events correct, then it could have been avoided entirely if there had been a Step 4.5, validate the certificate he just received. Indeed. The problem is much like a hash index. And anyone who's used hash indexing* should know that he must search the indicated bucket for the record which actually matches the search key. Hashing only cuts the size of the search space; it doesn't guarantee reducing it to a single-element space. * And anyone who puts socks in one drawer and shirts in another has used hash indexing. :-) -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpe88WKS1xAI.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
getting an encrypted file to show what public key was used
I am using gnupg via PHP's wrapper for it. I am sending an ecrypted files to remote hosts, using two different keys for the respective hosts. One host can decrypt the file properly, but the other host cannot. I am trying to troubleshoot this bug. Of course, I do not have the private keys from the remote hosts, so I cannot troubleshoot the complete circuit on my own. The host that cannot decrypt their file has the decruption running in some kind of Windows batch file. The error message they get seems to indicate the name of the public key that was used to encrypt the file. I am trying to figure out of the name of the public key is actually encoded into the gpg file. This is their error message: Beginning GPG Decryption Using current version of GNUPG gpg: encrypted with 2048-bit ELG-E key, ID F1940956, created 2002-04-25 Different Public Key another_key@another_company.com gpg: decryption failed: secret key not available However, when I try to decrypt the file I'm sending them, without the key, I get simply $ gpg --decrypt sensitive_file.gpg gpg: encrypted with ELG-E key, ID F1940956 gpg: decryption failed: secret key not available I want gpg to report the email address of the key used to encrypt the file, like in the error message I'm getting from the remote host. I want to see Different Public Key another_key@another_company.com, like in their error message. But my gpg doesn't report that. Is the name of the public key really encoded into the encrypted file? Or is something else mixed up on the remote host (for instance, them having the other hosts' private key)? How can I see the name of the public key that encrypted the file? Am I missing a switch? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: getting an encrypted file to show what public key was used
On 5/29/12 9:45 AM, Steven Lefevre wrote: gpg: encrypted with 2048-bit ELG-E key, ID F1940956, created 2002-04-25 Different Public Key another_key@another_company.com gpg: decryption failed: secret key not available Oh, cute. A short ID collision. :) Quaero Corporation's, apparently. Short answer: try using gpg - sensitive-file.gpg. This will give you a large amount of detailed information that might be useful for your debugging. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: getting an encrypted file to show what public key was used
On 5/29/12 11:17 AM, Hauke Laging wrote: What can you see that from? Can't, but it seems to be the most likely option. The most likely cause of this seems to be -- 1. His correspondent said use certificate 0xF1940956. 2. He did a gpg --recv-key 0xF1940956. 3. Quaero Corporation already has a certificate with the short ID of 0xF1940956 on the keyservers, created 2002-04-25. 4. He imported Quaero Corporation's certificate 5. He believes he's using the correct certificate for his correspondent, since he's using the short ID they specified 6. He's actually using Quaero Corporation's certificate 7. And his correspondents can't read the traffic, since he's using the wrong certificate. I could be wrong, of course, but that's where I'd place my bets. This goes to underline the importance of proper certificate validation. If I have the sequence of events correct, then it could have been avoided entirely if there had been a Step 4.5, validate the certificate he just received. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: getting an encrypted file to show what public key was used
Am Di 29.05.2012, 11:28:36 schrieb Robert J. Hansen: This goes to underline the importance of proper certificate validation. If I have the sequence of events correct, then it could have been avoided entirely if there had been a Step 4.5, validate the certificate he just received. Looks like a nice possibility for checking how serious the handling of keys by your partners is: Create a key with a short ID collision for a key available on the keyservers and give them the short ID... 8-) 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
Re: getting an encrypted file to show what public key was used
On Tue, 29 May 2012 15:45, lefevre...@osu.edu said: $ gpg --decrypt sensitive_file.gpg gpg: encrypted with ELG-E key, ID F1940956 gpg: decryption failed: secret key not available 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. 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
Re: getting an encrypted file to show what public key was used
Steven, The key who has the Short Key ID of F1940956 has the same short Key ID as : http://keyserver.ubuntu.com:11371/pks/lookup?search=0xF1940956op=vindex This is a flaw in the OpenPGP protocol (If I remember right). Short Key ID are only the last 8 hexadecimal characters of the full fingerprint. And the flaw make that OpenPGP verify only that short Key ID instead of the full fingerprint, and that leads to collision of Key ID even if the keys are differents ... The easier solution for you would be to create a new key On Tue, May 29, 2012 at 5:02 PM, Robert J. Hansen r...@sixdemonbag.org wrote: On 5/29/12 9:45 AM, Steven Lefevre wrote: gpg: encrypted with 2048-bit ELG-E key, ID F1940956, created 2002-04-25 Different Public Key another_key@another_company.com gpg: decryption failed: secret key not available Oh, cute. A short ID collision. :) Quaero Corporation's, apparently. Short answer: try using gpg - sensitive-file.gpg. This will give you a large amount of detailed information that might be useful for your debugging. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ 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
Re: getting an encrypted file to show what public key was used
Am Di 29.05.2012, 09:45:48 schrieb Steven Lefevre: Beginning GPG Decryption Using current version of GNUPG gpg: encrypted with 2048-bit ELG-E key, ID F1940956, created 2002-04-25 Different Public Key another_key@another_company.com gpg: decryption failed: secret key not available However, when I try to decrypt the file I'm sending them, without the key, I get simply $ gpg --decrypt sensitive_file.gpg gpg: encrypted with ELG-E key, ID F1940956 gpg: decryption failed: secret key not available Was this try in the same GnuPG environment like the encoding or was one within PHP and the other one as your regular user account? GnuPG does not report UIDs if the key is not available in the keyring. The error message tells us that the key which you have encoded for (0xF1940956 (or its main key), Different Public Key another_key@another_company.com) is part of the decoding system's keyring but only the public key. So you encode for the wrong key. I want gpg to report the email address of the key used to encrypt the file, like in the error message I'm getting from the remote host. I want to see Different Public Key another_key@another_company.com, like in their error message. But my gpg doesn't report that. You have to import the respective key in order to get that information. Is the name of the public key really encoded into the encrypted file? No, just the (long) ID of the used key (i.e. possibly a subkey). How can I see the name of the public key that encrypted the file? Am I missing a switch? You can search the keyservers for subkeys, too. gpg --keyserver pool.sks-keyservers.net --search-keys 0xF1940956 I am confused by Robert's short ID collision hint but my remarks should be correct anyway. 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
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
Re: getting an encrypted file to show what public key was used
On Tuesday 29 of May 2012 17:36:25 Hauke Laging wrote: Am Di 29.05.2012, 11:28:36 schrieb Robert J. Hansen: This goes to underline the importance of proper certificate validation. If I have the sequence of events correct, then it could have been avoided entirely if there had been a Step 4.5, validate the certificate he just received. Looks like a nice possibility for checking how serious the handling of keys by your partners is: Create a key with a short ID collision for a key available on the keyservers and give them the short ID... 8-) No, thank you. Getting people to use any form of crypto is hard enough. We don't need to show them that it doesn't fix all problems... Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl ___ 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]
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: getting an encrypted file to show what public key was used
On 5/29/12 11:16 AM, Tanguy Herrmann wrote: This is a flaw in the OpenPGP protocol (If I remember right). The protocol is fine, but it seems that the people involved did not properly validate certificates. (Note that I'm not certain about this, hence my seems. Maybe I should qualify it as seems likely.) And the flaw make that OpenPGP verify only that short Key ID instead of the full fingerprint, and that leads to collision of Key ID even if the keys are differents ... Certificate validation uses the full fingerprint. The easier solution for you would be to create a new key I apologize for sounding strident here, but that advice is both malinformed and wrong. It's malinformed because when something fails, we should learn why it failed and develop processes to prevent the failure in the future. Saying well, just have a do-over is not consistent with the best practices of software engineering. It's wrong because it's the other person whose certificate has a collision. He can create all the new certificates he wants but it won't change a thing. He may also not be able to persuade the other person to generate a new certificate: they may have already invested a lot in their current certificate, and may not want to switch. ___ 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 Tue, May 29, 2012 at 1:47 PM, David Shaw ds...@jabberwocky.com 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 2:05 PM, Sam Whited wrote: On Tue, May 29, 2012 at 1:47 PM, David Shaw ds...@jabberwocky.com 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: getting an encrypted file to show what public key was used
On 5/29/12 1:54 PM, Steven Lefevre wrote: This is, not surprisingly, the case. There was bad logic in my script and somehow, somewhere, it's using the wrong key for this particular host. The good news is it's an easy problem to fix. :) Get in touch with your contact over there (preferably via a non-email/non-IM form of contact, like the telephone). After getting in touch with the right person and verifying to your satisfaction that you're really talking to the right person, just ask: Hey, I need the full fingerprint of your OpenPGP key. Not the short ID, but the full fingerprint. Would you help me with that, please? Write down the full fingerprint. Then say, And could you please email me your public key? Then: $ gpg --delete-key 0xF1940956 Once the email with their certificate arrives, save it to disk and: $ gpg --import their certificate $ gpg --edit-key their certificate From the edit-key screen, type 'fingerprint' to check the full fingerprint. Make sure it matches what you were given on the phone. If it matches, then from the edit-key screen, type 'lsign'. This will validate the certificate, and at this point you'll have a fairly high assurance that you're using the correct certificate. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: getting an encrypted file to show what public key was used
On Tue, May 29, 2012 at 11:28 AM, Robert J. Hansen r...@sixdemonbag.org wrote: 1. His correspondent said use certificate 0xF1940956. 2. He did a gpg --recv-key 0xF1940956. 3. Quaero Corporation already has a certificate with the short ID of 0xF1940956 on the keyservers, created 2002-04-25. 4. He imported Quaero Corporation's certificate 5. He believes he's using the correct certificate for his correspondent, since he's using the short ID they specified 6. He's actually using Quaero Corporation's certificate 7. And his correspondents can't read the traffic, since he's using the wrong certificate. I could be wrong, of course, but that's where I'd place my bets. This is, not surprisingly, the case. There was bad logic in my script and somehow, somewhere, it's using the wrong key for this particular host. I was confused about how the remote host could learn the name of the public key, but apparently their script looks it up from public sources, or already has it on their keyring, or whatever. I was not aware of a method I could use to tell which key I had just encrypted a file with, but thanks to the replies, I now know that the key ID will let me know :) Steve Lefevre ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: getting an encrypted file to show what public key was used
On Tue, 29 May 2012 19:54, lefevre...@osu.edu said: This is, not surprisingly, the case. There was bad logic in my script and somehow, somewhere, it's using the wrong key for this particular Speaking of scripts: Scripts should use --with-colons and never try to parse the regular output. --with-colons prints the long bit key ID. Shalom-Salam, Werner p.s. I have said this at least a hundred times, but it is still not known well enough. The small scripts in tools/ use this method and should give the intial idea to look into the man page and check what this --with-colons is about. Would an option --annotate which enables --with-colons, --batch, and --status-fd be helpful? -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: getting an encrypted file to show what public key was used
On Tue, May 29, 2012 at 3:29 PM, Werner Koch w...@gnupg.org wrote: On Tue, 29 May 2012 19:54, lefevre...@osu.edu said: This is, not surprisingly, the case. There was bad logic in my script and somehow, somewhere, it's using the wrong key for this particular Speaking of scripts: Scripts should use --with-colons and never try to parse the regular output. --with-colons prints the long bit key ID. I was being a bit ambiguous -- by 'script' I meant a PHP program, not a shell script :P ___ 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: getting an encrypted file to show what public key was used
Am Di 29.05.2012, 21:29:51 schrieb Werner Koch: I have said this at least a hundred times, but it is still not known well enough. You probably mean: Among the readers of this list. How much known may it be in the wild...? Would an option --annotate which enables --with-colons, --batch, and --status-fd be helpful? I don't think so because giving --with-colons, --batch, and --status-fd is not the problem. Making this easier should not have a big effect on the problem. The problem is knowledge (and discipline). So the aim should be to spread the knowledge. This could be done by printing a warning to stderr when stdin and stdout are not terminals and these options are not given: You are probably running gpg non-interactively. In order not to break scripts it is strongly encouraged to use scripted output of gpg only with the options --with-colons, --batch and --status-fd. See http://www.gnupg.org/...; 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
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: getting an encrypted file to show what public key was used
On Tue, 29 May 2012 22:02, mailinglis...@hauke-laging.de said: You are probably running gpg non-interactively. In order not to break scripts it is strongly encouraged to use scripted output of gpg only with the options --with-colons, --batch and --status-fd. See http://www.gnupg.org/...; Well, scripts won't see that message ;-). They might also assume something about stderr output and break. Well, such a break has the benefit that the authors need to look at the problem. 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
