From wk at gnupg.org Mon Feb 1 11:01:31 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Feb 2010 11:01:31 +0100 Subject: Passphrase problem in gpgsm 2.0.14 In-Reply-To: <874om9vsq1.fsf@vigenere.g10code.de> (Werner Koch's message of "Tue, 26 Jan 2010 15:36:06 +0100") References: <874om9vsq1.fsf@vigenere.g10code.de> Message-ID: <87iqahs29w.fsf@vigenere.g10code.de> Hi! Due to the problems with Mailman breaking the signature, I uploaded the patch from the orginal message to the ftp server and signed it: ftp://ftp.gnupg.org/gcrypt/gnupg/patches/gnupg-2.0.14-encode-s2k.patch Please apply it if you use gnupg 2.0.14 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Mon Feb 1 14:53:43 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 1 Feb 2010 14:53:43 +0100 Subject: Passphrase problem in gpgsm 2.0.14 In-Reply-To: <201001291718.38928.bernhard@intevation.de> References: <874om9vsq1.fsf@vigenere.g10code.de> <201001291718.38928.bernhard@intevation.de> Message-ID: <201002011453.47254.bernhard@intevation.de> Am Freitag, 29. Januar 2010 17:18:33 schrieb Bernhard Reiter: > Am Dienstag, 26. Januar 2010 15:36:06 schrieb Werner Koch: > > A patch against 2.0.14 is attached. > > The signature on the email was broken for me (and for Marcus), > this is for the email received via the email list. To verify the signature of Werner's original email, you can reverse the whitespace change that broke the signature. (Save the email in raw format. Join the following two lines to be one. Then recheck the signature on the changed email.) 76,77c76 < Content-Type: multipart/mixed; < boundary="=Rule-Psix-Soviet-number-key-weapons-of-mass-destruction-freedom-Nort" --- > Content-Type: multipart/mixed; boundary="=Rule-Psix-Soviet-number-key-weapons-of-mass-destruction-freedom-Nort" There is a long standing issue with Mailman breaking signature. (I've developed a patch for a part of the problem, which after a few years got accepted into mailman 2.1.13, see https://bugs.launchpad.net/mailman/+bug/265967 https://launchpad.net/mailman/2.1/2.1.13 - Mailman no longer folds long sub-part headers in multipart messages. In addition, Mailman no longer escapes From_ lines in the body of messages sent to regular list members, although MTA's may do it anyway. This is to avoid breaking signatures per Bug #265967. Debian used to carry the patch for a long time. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Feb 1 20:25:46 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Feb 2010 20:25:46 +0100 Subject: GPG4Win: running gpg-agent with SSH agent support? In-Reply-To: <87k4v13vxx.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 29 Jan 2010 14:03:06 +0100") References: <87k4v13vxx.fsf@mocca.josefsson.org> Message-ID: <87d40orc5h.fsf@vigenere.g10code.de> On Fri, 29 Jan 2010 14:03, simon at josefsson.org said: > I've installed GPG4Win and it recognizes my OpenPGP smartcards without > problem (via a gpg-agent process which appears to be auto-started > somehow?). However, I'd like to enable SSH agent support in gpg-agent Yes, we do this on Windows because we have a well known socket name there. It may actually happen that two agents are started which does not harm because the the unused agent detects this case and terminates itself after some time. > too, so that Cygwin ssh can make use of it. Is this possible, if so > how? It can't work out of the box because ssh needs to implement our local socket emulation (see libassuan/src/assuan-socket.c). It would be very useful if we could get support for this into putty. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From danm at prime.gushi.org Mon Feb 1 21:31:34 2010 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Mon, 1 Feb 2010 15:31:34 -0500 (EST) Subject: GPG4Win: running gpg-agent with SSH agent support? In-Reply-To: <87d40orc5h.fsf@vigenere.g10code.de> References: <87k4v13vxx.fsf@mocca.josefsson.org> <87d40orc5h.fsf@vigenere.g10code.de> Message-ID: On Mon, 1 Feb 2010, Werner Koch wrote: > Yes, we do this on Windows because we have a well known socket name > there. It may actually happen that two agents are started which does > not harm because the the unused agent detects this case and terminates > itself after some time. What's the socket location inder win32, if you don't mind me asking? -Dan -- "You recreate the stars in the sky with cows?" -Furrball, March 7 2005, on Katamari Damacy --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From wk at gnupg.org Tue Feb 2 11:45:52 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Feb 2010 11:45:52 +0100 Subject: GPG4Win: running gpg-agent with SSH agent support? In-Reply-To: (Dan Mahoney's message of "Mon, 1 Feb 2010 15:31:34 -0500 (EST)") References: <87k4v13vxx.fsf@mocca.josefsson.org> <87d40orc5h.fsf@vigenere.g10code.de> Message-ID: <87fx5jq5jz.fsf@vigenere.g10code.de> On Mon, 1 Feb 2010 21:31, danm at prime.gushi.org said: > On Mon, 1 Feb 2010, Werner Koch wrote: > >> Yes, we do this on Windows because we have a well known socket name >> there. It may actually happen that two agents are started which does >> not harm because the the unused agent detects this case and terminates >> itself after some time. > > What's the socket location inder win32, if you don't mind me asking? On my system this is C:\Dokumente und Einstellungen\werner\Anwendungsdaten\gnupg\S.gpg-agent You can get all these values using: c:\Programme\GNU\GnuPG>gpgconf --list-dirs sysconfdir:C%3a\Dokumente und Einstellunge[...]aten\GNU\etc\gnupg bindir:c%3a\Programme\GNU\GnuPG libexecdir:c%3a\Programme\GNU\GnuPG libdir:c%3a\Programme\GNU\GnuPG\lib\gnupg datadir:c%3a\Programme\GNU\GnuPG\share\gnupg localedir:c%3a\Programme\GNU\GnuPG\share\locale dirmngr-socket:C%3a\WINDOWS\S.dirmngr agent-socket:C%3a\Dokumente und Eins[...]gsdaten\gnupg\S.gpg-agent homedir:C%3a\Dokumente und Einstellungen\werner\Anwendungsdaten\gnupg This is a colon delimited and percent escaped output, thus the %3a for the colons in the filenames. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Tue Feb 2 15:52:34 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 02 Feb 2010 15:52:34 +0100 Subject: GPG4Win: running gpg-agent with SSH agent support? In-Reply-To: <87d40orc5h.fsf__4932.99644808776$1265055332$gmane$org@vigenere.g10code.de> (Werner Koch's message of "Mon, 01 Feb 2010 20:25:46 +0100") References: <87k4v13vxx.fsf@mocca.josefsson.org> <87d40orc5h.fsf__4932.99644808776$1265055332$gmane$org@vigenere.g10code.de> Message-ID: <87wryvital.fsf@mocca.josefsson.org> Werner Koch writes: > On Fri, 29 Jan 2010 14:03, simon at josefsson.org said: > >> I've installed GPG4Win and it recognizes my OpenPGP smartcards without >> problem (via a gpg-agent process which appears to be auto-started >> somehow?). However, I'd like to enable SSH agent support in gpg-agent > > Yes, we do this on Windows because we have a well known socket name > there. It may actually happen that two agents are started which does > not harm because the the unused agent detects this case and terminates > itself after some time. > >> too, so that Cygwin ssh can make use of it. Is this possible, if so >> how? > > It can't work out of the box because ssh needs to implement our local > socket emulation (see libassuan/src/assuan-socket.c). It would be very > useful if we could get support for this into putty. Why can't gpg-agent implement the same protocol that ssh-agent does under Windows? The ssh-agent under Cygwin appears to work in the same way it does on GNU/Linux, i.e., the ssh process looks for the environment variables that ssh-agent prints when started. /Simon From simon at josefsson.org Tue Feb 2 15:54:33 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 02 Feb 2010 15:54:33 +0100 Subject: Gnupg doesn't recognize card. In-Reply-To: <87ljfht5qn.fsf__27934.6329662532$1264770974$gmane$org@vigenere.g10code.de> (Werner Koch's message of "Fri, 29 Jan 2010 14:12:16 +0100") References: <4B622A41.7030304@gmail.com> <87ljfht5qn.fsf__27934.6329662532$1264770974$gmane$org@vigenere.g10code.de> Message-ID: <87sk9jit7a.fsf@mocca.josefsson.org> Werner Koch writes: > On Fri, 29 Jan 2010 01:22, jcruff at gmail.com said: > >> $ killall -u scdaemon #usually has to be entered 2-3x to >> kill it > > FWIW, > > gpgconf --reload scdaemon > > does the same in a well defined manner. The --reload parameter doesn't appear to be documented. Is it really supported for use in long-term portable scripts? /Simon From jcruff at gmail.com Wed Feb 3 02:04:12 2010 From: jcruff at gmail.com (Chris Ruff) Date: Tue, 02 Feb 2010 20:04:12 -0500 Subject: OpenPGP SmartCard v2.0 w/OmniKey 6121 Message-ID: <4B68CB8C.8020201@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I've been researching the archives for the past week after receiving my OpenPGP v2.0 smartcard from Kernelconcepts. Problem seems to revolve around the reader, but between by two systems OpenSUSE 11.2 (gnupg 2.0.13) and Mac OS X 10.5.8 (MacGPG/gnupg 2.0.14) I have slightly different results. First I was only able to create the 3 2048-bit keys on the linux laptop but would fail to create a 3072/2048/2048 set on the same system. On the Mac I couldn't create anything (tried all 1024 and 2048 keys). I could successfully change all my card options (did this before key generation). With the card now having 2048 keys, on the linux system I could encrypt/decrypt but can not perform any signing/verify operation. On the Mac I can encrypt, but neither decrypt/sign/verify. Errors vary from "general signing error" to secret key not found (when trying to decrypt. I was unclear how to actually setup my new keys on the Mac so I performed an export using export/export-secret-keys over to the Mac from the linux system. Please let me know what types of debugs I can provide back for review or any other test information one would like performed or provided. I would really like to get this reader working, but if not I'll take recommendations for USB ID-000 readers (since I already punched mine out). Output of '--card-status' below. Thanks in advance. $ gpg --card-status Application ID ...: D2760001240102000005000003740000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 00000374 Name of cardholder: John Ruff Language prefs ...: en Sex ..............: male URL of public key : [not set] Login data .......: techniq Signature PIN ....: forced Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 18 Signature key ....: 6530 8DA8 805C 707F 3611 9851 D057 FC41 052A 4FAD created ....: 2010-01-24 02:10:16 Encryption key....: 0A2B BBEE 4B0D C392 A4E6 3673 ECCF B9FB 1488 8977 created ....: 2010-01-24 02:10:16 Authentication key: 735C 977A DFBA 72B2 CDF0 D5D9 F9E8 742E FC34 E962 created ....: 2010-01-24 02:10:16 General key info..: pub 2048R/052A4FAD 2010-01-24 John C. Ruff (Techniq) sec> 2048R/052A4FAD created: 2010-01-24 expires: never card-no: 0005 00000374 ssb> 2048R/FC34E962 created: 2010-01-24 expires: never card-no: 0005 00000374 ssb> 2048R/14888977 created: 2010-01-24 expires: never card-no: 0005 00000374 - -- __________________________________ Chris Ruff email: jcruff at gmail.com gpg key: 0x307A351B4EC4B6A1 gpg fgpr: BF2F 2497 22E7 FEB5 C805 075C 307A 351B 4EC4 B6A1 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJLaMuIAAoJEDB6NRtOxLah8HAQAKVBmBPEu9/W13uMMQe29v11 b6EDMk08S+FJYtj56FmNY7jd43MWlpQ2vsrnKkJlfoOXuGyCcuRiuONRI5/uXnZM YtSaeL31c+YINoHDptHwegkaLfUD72X/2JQRjl5Z5FgkgoYOUjSSWVAO7J/Zt4I+ KQ+uuHqm3ivjpZFmjwpIlrepfMDmQpN8PTDdWoovsecV1g0BfOh0ZZ3mlbzSr84+ FX1+1Z2GeOGi3I0ibTUl+HFym9ZOj3YATuU+r6o+cMGjsrwfO22Q+k/5GdmrnAI8 60rsp+UrlYhS/WYZatYS+dIYy1yLZLfoSplHBLbgfbI5fzaOspIAElEUL5SjfWW1 EtOQtEqmDPq08CFIiisEENCKZDtX/I6FliXt7/uuWiuvFdHrNSnI9+GGEaxw9SfF 7f9tYk/dAzRGN8GHoQegnb+CoIJxhGeOs5uqcCEfXVT8SeJNf6Zi5PFpsKDJVvDV eKi8pV36wYnI0JJbYWWI53GwvNPc0DeQUHG4Ey71EK5VUpJVpC41NX25cDlKclIy 1eunQBH+TvIaniG7qLA2b9lvArIRSIs9YXDYk8TbEJSYt3T2wNm2TKhOJTNj4oJB fdF9fAO9p5amb0FUj2Z2CIMdxR1b/meXXq2YR7/w5w+rrlI4lp6CYBoT+gZ/h6E2 l6yvh4VpbGuJ/eLfZgqF =kWzY -----END PGP SIGNATURE----- From wk at gnupg.org Wed Feb 3 10:46:39 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Feb 2010 10:46:39 +0100 Subject: GPG4Win: running gpg-agent with SSH agent support? In-Reply-To: <87wryvital.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 02 Feb 2010 15:52:34 +0100") References: <87k4v13vxx.fsf@mocca.josefsson.org> <87d40orc5h.fsf__4932.99644808776$1265055332$gmane$org@vigenere.g10code.de> <87wryvital.fsf@mocca.josefsson.org> Message-ID: <87ock6mz28.fsf@vigenere.g10code.de> On Tue, 2 Feb 2010 15:52, simon at josefsson.org said: > Why can't gpg-agent implement the same protocol that ssh-agent does > under Windows? I don't know how ssh-agent works unde Cygwin. It has been many years that I last looked at Cygwin. How to they emulate nix doman sockets? That is the crucial question. > The ssh-agent under Cygwin appears to work in the same way it does on > GNU/Linux, i.e., the ssh process looks for the environment variables > that ssh-agent prints when started. I believe gpg-agent prints these environment variables. I can't check right now because I removed the current installation cause I am about to test a new gpg4win. However the crucial question is how the Unix domain sockets are implemented. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From andy_croft at npd.com Tue Feb 2 17:15:59 2010 From: andy_croft at npd.com (20 Ton Squirrel) Date: Tue, 2 Feb 2010 08:15:59 -0800 (PST) Subject: Error decrypting: No secret key available Message-ID: <27423049.post@talk.nabble.com> This is likely a common error for new users, which I count myself amongst. I searched the forum and found issues similar to my own but the solutions did not fix my problem. THE SETUP: I am using GPG 1.4.10 on a WinXP system. I created my own key and imported a client's key. My key shows up under the gpg -K command as 974CE93B The client's key shows up under the gpg --list-keys command as FC0919EA I'm trying to encrypt an Excel file using the following command line: gpg --compress-algo 1 --cipher-algo cast5 --local-user myusrname at localuser.com -r myClient at myClient.com -o C:\user\encrypt\out\myExcel.xls.gpg -se C:\user\encrypt\in\myExcel.xls THE PROBLEM: Once it is encrypted, neither the client or I can actually decrypt the file again. The error message reads: No secret key available Keyring does not have the secret key (0x5C3A5DB39FF7592C) needed to decrypt this message. My assumption was that the secret key would've been 974CE93B, since it's my signature. Can someone point me in the right direction? -- View this message in context: http://old.nabble.com/Error-decrypting%3A-No-secret-key-available-tp27423049p27423049.html Sent from the GnuPG - User mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy_croft at npd.com Tue Feb 2 17:16:18 2010 From: andy_croft at npd.com (20 Ton Squirrel) Date: Tue, 2 Feb 2010 08:16:18 -0800 (PST) Subject: Error decrypting: No secret key available Message-ID: <27423049.post@talk.nabble.com> This is likely a common error for new users, which I count myself amongst. I searched the forum and found issues similar to my own but the solutions did not fix my problem. THE SETUP: I am using GPG 1.4.10 on a WinXP system. I created my own key and imported a client's key. My key shows up under the gpg -K command as 974CE93B The client's key shows up under the gpg --list-keys command as FC0919EA I'm trying to encrypt an Excel file using the following command line: gpg --compress-algo 1 --cipher-algo cast5 --local-user myusrname at localuser.com -r myClient at myClient.com -o C:\user\encrypt\out\myExcel.xls.gpg -se C:\user\encrypt\in\myExcel.xls THE PROBLEM: Once it is encrypted, neither the client or I can actually decrypt the file again. The error message reads: No secret key available Keyring does not have the secret key (0x5C3A5DB39FF7592C) needed to decrypt this message. My assumption was that the secret key would've been 974CE93B, since it's my signature. Can someone point me in the right direction? -- View this message in context: http://old.nabble.com/Error-decrypting%3A-No-secret-key-available-tp27423049p27423049.html Sent from the GnuPG - User mailing list archive at Nabble.com. From mohanr at fss.co.in Tue Feb 16 08:21:40 2010 From: mohanr at fss.co.in (Mohan.Radhakrishnan) Date: Mon, 15 Feb 2010 23:21:40 -0800 (PST) Subject: Encrypting for multiple users Message-ID: <27604446.post@talk.nabble.com> Hi, We have several public keys and we use all of them to encrypt files. Each recipient then decrypts the file using his or her own secret key. Now some recipients lose their keys and replace them. Some new encrypting keys get added. So we have several old files that the new users cannot read. Can a single user generate several sub secret keys and distribute to the other recipients ? Does this solve the old file re-encryption problem somehow by still retaining individual keys ? Our policy does not allow sharing of keys. So it looks like the subkeys have the same problem because all of them originate from a common key ? Thanks, Mohan -- View this message in context: http://old.nabble.com/Encrypting-for-multiple-users-tp27604446p27604446.html Sent from the GnuPG - User mailing list archive at Nabble.com. From stefanxe at gmx.net Tue Feb 16 20:29:51 2010 From: stefanxe at gmx.net (Stefan Xenon) Date: Tue, 16 Feb 2010 20:29:51 +0100 Subject: fetch public key from card? Message-ID: <4B7AF22F.8080803@gmx.net> Hi! When using "gpg --card-edit" and "fetch" gnupg tries to download the public key from a key server. Instead, is it possible to fetch the public key from an OpenPGP Card v2.0 directly? If so, how to do this? Otherwise do I need to keep a backup of my public key always together with my OpenPGP Card? Best regards Stefan From mohanr at fss.co.in Mon Feb 15 08:34:09 2010 From: mohanr at fss.co.in (Mohan Radhakrishnan) Date: Mon, 15 Feb 2010 13:04:09 +0530 Subject: Encrypting for multiple users Message-ID: <0EE14841E1FD8545B7E084F22AEF968101881C7F@fssbemail.fss.india> Hi, We have several public keys and we use all of them to encrypt files. Each recipient then decrypts the file using his or her own secret key. Now some recipients lose their keys and replace them. Some new encrypting keys get added. So we have several old files that the new users cannot read. Can a single user generate several sub secret keys and distribute to the other recipients ? Does this solve the old file re-encryption problem somehow by still retaining individual keys ? Our policy does not allow sharing of keys. So it looks like the subkeys have the same problem because all of them originate from a common key ? Thanks, Mohan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Tue Feb 16 20:59:38 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 16 Feb 2010 14:59:38 -0500 Subject: fetch public key from card? In-Reply-To: <4B7AF22F.8080803@gmx.net> References: <4B7AF22F.8080803@gmx.net> Message-ID: <9F2C92EE-1C28-4977-A49C-3E817BBF1685@jabberwocky.com> On Feb 16, 2010, at 2:29 PM, Stefan Xenon wrote: > Hi! > When using "gpg --card-edit" and "fetch" gnupg tries to download the > public key from a key server. Instead, is it possible to fetch the > public key from an OpenPGP Card v2.0 directly? If so, how to do this? > Otherwise do I need to keep a backup of my public key always together > with my OpenPGP Card? The data stored on the card is only the secret key - and even then, it's only the necessary pieces of the secret key (there is a lot of redundant data in the OpenPGP key format). You cannot recreate a public key from a card, so you must store it elsewhere. David From chd at chud.net Wed Feb 17 00:17:06 2010 From: chd at chud.net (Chris De Young) Date: Tue, 16 Feb 2010 16:17:06 -0700 Subject: Encrypting for multiple users In-Reply-To: <0EE14841E1FD8545B7E084F22AEF968101881C7F@fssbemail.fss.india> References: <0EE14841E1FD8545B7E084F22AEF968101881C7F@fssbemail.fss.india> Message-ID: <4B7B2772.3010506@chud.net> On 2/15/2010 12:34 AM, Mohan Radhakrishnan wrote: > Hi, > > We have several public keys and we use all of them to encrypt > files. Each recipient then decrypts the file using his or her own secret > key. Now some recipients lose their keys and replace them. Some new > encrypting keys get added. So we have several old files that the new > users cannot read. > > Can a single user generate several sub secret keys and distribute to the > other recipients ? Does this solve the old file re-encryption problem > somehow by still retaining individual keys ? > > Our policy does not allow sharing of keys. So it looks like the subkeys > have the same problem because all of them originate from a common key ? I'm not intimately familiar with the way keys and subkeys are related and interact, so I can't answer the exact question you asked. However, in the general case, I think the only solution to this problem is to use some sort of key escrow system. (The real solution is "don't lose your keys" and key escrow is one way to try to implement that.) If you design some way of generating several [sub]keys or something such that the end result is the ability to regenerate a lost key, then you have effectively shared your key (since others could regenerate it without your participation). Your policy prohibits that, so whether or not you can devise a system to do it is academic. Whether or not key escrow counts as "sharing keys" is a question for your policy-makers. As a general principle, if a secret key is unavailable, you WANT the encrypted material it protects to become unavailable. That's rather the point, no? :-) -Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From f.schwind at chili-radiology.com Wed Feb 17 09:48:59 2010 From: f.schwind at chili-radiology.com (Florian Schwind) Date: Wed, 17 Feb 2010 09:48:59 +0100 Subject: gpeme_get_key returns a 'general error' after some time. In-Reply-To: <4B600BCC.1070108@chili-radiology.com> References: <4B582FC4.20301@chili-radiology.com> <87iqauyqma.fsf@vigenere.g10code.de> <4B5D5FEB.50102@chili-radiology.com> <87sk9uwe4c.fsf@vigenere.g10code.de> <4B600BCC.1070108@chili-radiology.com> Message-ID: <4B7BAD7B.2080804@chili-radiology.com> Hi, > On 25.01.2010 13:41, Werner Koch wrote: >> On Mon, 25 Jan 2010 10:10, f.schwind at chili-radiology.com said: >> Then you need to use finer grained debug control. Probably you need to >> modify something in gpgme. > > I updated to gpg 1.4.10 and gpgme 1.2.0 but this doesn't solve the problem. > > I will put more debug output in gpgme and try to identify where the > error happens. I identified the the piece of code responsible causing the error. It happens in the _gpgme_io_set_close_notify method in posix-io.c I'm getting a fd > 256 which seams to be the maximum of fds gpgme can handle. It might be some sort of design-issue in my software causing so many open fds, but I'd still like to overcome this fd limitation. As far as I can see, gpgme is using the fd as index for the notify_table. So could I just increase the size of the notify_table without breaking things? >> Salam-Shalom, >> Werner Best Regards Florian From kgo at grant-olson.net Wed Feb 17 09:19:07 2010 From: kgo at grant-olson.net (Grant Olson) Date: Wed, 17 Feb 2010 03:19:07 -0500 Subject: It'd be nice if "--refresh-keys" was covered on the website. Message-ID: <4B7BA67B.9010407@grant-olson.net> Hey, I'm not sure if this is the right place to talk about this, but the maintainer contact email listed in the Privacy Handbook is dead, the doc mailing list has a last post in 2008, and it doesn't seem like it belongs on the developer list. So... There's no mention of --refresh-keys usage on the website's manpage or the Privacy Handbook. I was reading about revoking keys on various sites, but I couldn't for the life of me figure out how other users would know that your key was revoked. How they'd get that information. I was searching around like crazy. I knew there had to be a better option than just catching things by manually re-importing the key when you're on a new computer. Or having to email everyone who has your old private key with the bad news. After days of searching, I finally found the "--refresh-keys" option. I thought once I had that figured out, it'd obviously be on the gnugp site. But it's not covered in the handbook, nor is it covered in the site's online man page. (Glad on the manpage, I know I read it a hundred times.) Anyway, it makes me wonder how many other people don't know about this command, and how many never check to see they've got bad keys on their keyring. I thought it would be also be a nice addition to the Privacy Handbook, a subsection under "Section 3: Key Management." I'm not a OpenPGP guru, but I could try my hand at a rough draft of some appropriate text if no-one else is up for it. It looks like the doc could also use some other minor updates (still say the default key is DSA/ElGammal..., etc). It might also be nice if the manpage on the website had the actual current manpage, since searching for "man gpg" inevitably ends up there. Like I said, I'm happy to do some of the legwork here if someone can point me in the right direction and think it's a reasonable request. -Grant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From kgo at grant-olson.net Wed Feb 17 09:19:01 2010 From: kgo at grant-olson.net (Grant Olson) Date: Wed, 17 Feb 2010 03:19:01 -0500 Subject: It'd be nice if "--refresh-keys" was covered on the website. Message-ID: <4B7BA675.90401@grant-olson.net> Hey, I'm not sure if this is the right place to talk about this, but the maintainer contact email listed in the Privacy Handbook is dead, the doc mailing list has a last post in 2008, and it doesn't seem like it belongs on the developer list. So... There's no mention of --refresh-keys usage on the website's manpage or the Privacy Handbook. I was reading about revoking keys on various sites, but I couldn't for the life of me figure out how other users would know that your key was revoked. How they'd get that information. I was searching around like crazy. I knew there had to be a better option than just catching things by manually re-importing the key when you're on a new computer. Or having to email everyone who has your old private key with the bad news. After days of searching, I finally found the "--refresh-keys" option. I thought once I had that figured out, it'd obviously be on the gnugp site. But it's not covered in the handbook, nor is it covered in the site's online man page. (Glad on the manpage, I know I read it a hundred times.) Anyway, it makes me wonder how many other people don't know about this command, and how many never check to see they've got bad keys on their keyring. I thought it would be also be a nice addition to the Privacy Handbook, a subsection under "Section 3: Key Management." I'm not a OpenPGP guru, but I could try my hand at a rough draft of some appropriate text if no-one else is up for it. It looks like the doc could also use some other minor updates (still say the default key is DSA/ElGammal..., etc). It might also be nice if the manpage on the website had the actual current manpage, since searching for "man gpg" inevitably ends up there. Like I said, I'm happy to do some of the legwork here if someone can point me in the right direction and think it's a reasonable request. -Grant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From start1one at list.ru Wed Feb 17 16:09:45 2010 From: start1one at list.ru (All) Date: Wed, 17 Feb 2010 18:09:45 +0300 Subject: remote Message-ID: Hi, is there a decision to use gpg on the same server and access it from remote servers, such as a LAN or via the Internet? Thanks. From wk at gnupg.org Wed Feb 17 19:31:58 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Feb 2010 19:31:58 +0100 Subject: gpeme_get_key returns a 'general error' after some time. In-Reply-To: <4B7BAD7B.2080804@chili-radiology.com> (Florian Schwind's message of "Wed, 17 Feb 2010 09:48:59 +0100") References: <4B582FC4.20301@chili-radiology.com> <87iqauyqma.fsf@vigenere.g10code.de> <4B5D5FEB.50102@chili-radiology.com> <87sk9uwe4c.fsf@vigenere.g10code.de> <4B600BCC.1070108@chili-radiology.com> <4B7BAD7B.2080804@chili-radiology.com> Message-ID: <87fx4zbtnl.fsf@vigenere.g10code.de> On Wed, 17 Feb 2010 09:48, f.schwind at chili-radiology.com said: > I'm getting a fd > 256 which seams to be the maximum of fds gpgme can > handle. It might be some sort of design-issue in my software causing > so many open fds, but I'd still like to overcome this fd Actually not, there is quite some software out which uses a lot of fds. On my system, the default number of FDs is 1024 (ulimit -n) and thus it coult happen here as well. We need to change the datatructure. > the notify_table. So could I just increase the size of the > notify_table without breaking things? Should pose no problem. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From l.bigonville at edpnet.be Wed Feb 17 18:46:02 2010 From: l.bigonville at edpnet.be (Laurent Bigonville) Date: Wed, 17 Feb 2010 18:46:02 +0100 Subject: SHA2 digest on gpg smartcard Message-ID: <20100217184602.65e73819@fornost.bigon.be> Hi, I've have a OpenGPG smartcard version 2.0 and I would generate digests stronger than SHA1. I've added "personal-digest-preferences SHA256" to my gpg.conf file, but when I sign a message the headers still uses SHA1. If I force with --digest-algo (which is not recommended according to the doc) to SHA256 it works and I'm able to verify the signature. I've opened a bug[1], but I was told that it was not a bug. Then could someone enlighten me about the reasons of this? Cheers Laurent Bigonville [1] https://bugs.g10code.com/gnupg/issue1194 From wk at gnupg.org Wed Feb 17 21:14:27 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Feb 2010 21:14:27 +0100 Subject: gpeme_get_key returns a 'general error' after some time. In-Reply-To: <87fx4zbtnl.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 17 Feb 2010 19:31:58 +0100") References: <4B582FC4.20301@chili-radiology.com> <87iqauyqma.fsf@vigenere.g10code.de> <4B5D5FEB.50102@chili-radiology.com> <87sk9uwe4c.fsf@vigenere.g10code.de> <4B600BCC.1070108@chili-radiology.com> <4B7BAD7B.2080804@chili-radiology.com> <87fx4zbtnl.fsf@vigenere.g10code.de> Message-ID: <87bpfnbows.fsf@vigenere.g10code.de> On Wed, 17 Feb 2010 19:31, wk at gnupg.org said: > We need to change the datatructure. Done. However we need to write a test case for it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From stefanxe at gmx.net Thu Feb 18 08:59:39 2010 From: stefanxe at gmx.net (Stefan Xenon) Date: Thu, 18 Feb 2010 08:59:39 +0100 Subject: fetch public key from card? In-Reply-To: <9F2C92EE-1C28-4977-A49C-3E817BBF1685@jabberwocky.com> References: <4B7AF22F.8080803@gmx.net> <9F2C92EE-1C28-4977-A49C-3E817BBF1685@jabberwocky.com> Message-ID: <4B7CF36B.5050302@gmx.net> Hi David, thanks for your reply. In the OpenPGP Card spec I discovered the command "Generate Public Keypair". So I assume the card would allow such feature but GnuPG does not support it yet? Regards Stefan Am 16.02.2010 20:59, schrieb David Shaw: > On Feb 16, 2010, at 2:29 PM, Stefan Xenon wrote: > >> Hi! >> When using "gpg --card-edit" and "fetch" gnupg tries to download the >> public key from a key server. Instead, is it possible to fetch the >> public key from an OpenPGP Card v2.0 directly? If so, how to do this? >> Otherwise do I need to keep a backup of my public key always together >> with my OpenPGP Card? > > The data stored on the card is only the secret key - and even then, it's only the necessary pieces of the secret key (there is a lot of redundant data in the OpenPGP key format). You cannot recreate a public key from a card, so you must store it elsewhere. > > David > From wk at gnupg.org Thu Feb 18 10:41:49 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Feb 2010 10:41:49 +0100 Subject: Release candidate for 2.0.15 Message-ID: <873a0yc23m.fsf@vigenere.g10code.de> Hi! I just prepared a release candidate for GnuPG 2.0.15. The goal of this release is to find out whether there are any severe build or runtime bugs. There are actually not may changes: * New command --passwd for GPG. * Fixes a regression in 2.0.14 which prevented unprotection of new or changed gpg-agent passphrases. * Make use of Libassuan 2.0 which is available as a DSO. as well as a couple of minor bug fixes and some changes to the German translation. The major point is the move to Libassuan 2.0. This is the first version of Libassuan which may be used as a shared library. We took this change to cleanup the API a bit with the drawback that some changes to the caller are required. To make development with Libassuan easier we need to get rid of Libassuan 1 which developer's package can't be installed side by side with Libassuan 2. Thus it is not easy to maintain software written with version 1 and 2 at the same time. With the 2.0.15 release we will have finished the migration of the GnuPG related tools to Libassuan 2. Please let us know if there are any problems building this release: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.15rc1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.15rc1.tar.bz2.sig Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 200 bytes Desc: not available URL: From vincent.letoux at gmail.com Tue Feb 16 23:35:30 2010 From: vincent.letoux at gmail.com (Vincent Le Toux) Date: Tue, 16 Feb 2010 23:35:30 +0100 Subject: generating / reading public key on smart card Message-ID: Hi, I'm encountering an "gpg: key generation failed" when I try to generate new keys on OpenPGP smart card v2. My config is Windows 7 ultimate 64 bits with gpg running on 32 bits. I've tried two smart card (including the one Werner sent to me) with 2 readers : gpg: detected reader `ACS CCID USB Reader 0' gpg: detected reader `SCM Microsystems Inc. SCR33x USB Smart Card Reader 0' When I'm tracing APDU sent (using a tool from IDRIX), I see: 2010-02-16 22:55:12.753 - SCardTransmit( hCard = 0xEA010000 ): Input APDU = 00 47 80 00 02 B6 00 00 Response = 67 00 67 00 means "Wrong length (Lc and/or Le)" Bellow one complete dialog (sorry, in French) Any ideas ? Regards, Vincent ===================================================== C:\Program Files (x86)\GNU\GnuPG>gpg --card-edit gpg: detected reader `ACS CCID USB Reader 0' gpg: detected reader `SCM Microsystems Inc. SCR33x USB Smart Card Reader 0' Application ID ...: D2760001240102000005000000390000 Version ..........: 2.0 Manufacturer .....: unknown Serial number ....: 00000039 Name of cardholder: Enoch Root Language prefs ...: de Sex ..............: non sp?cifi? URL of public key : http://www.example.org/~enoch/mykey.asc Login data .......: [non positionn?] Private DO 1 .....: [non positionn?] Private DO 2 .....: [non positionn?] Signature PIN ....: non forc? Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 5 Signature key ....: 69A7 FC5E 6974 866E 917B D53D E455 F2D7 CC9C 6BBC created ....: 2009-11-05 17:01:08 Encryption key....: 8DC1 3BB5 A0F0 DBA6 7E81 B2E5 D367 147F 5CB0 CDF0 created ....: 2009-11-05 17:01:08 Authentication key: 4676 0AA3 4E97 1FE5 7189 A741 591B 5112 D5A9 C5A6 created ....: 2009-11-05 17:01:08 General key info..: [none] Commande> admin Les commandes d'administration sont permises Commande> generate Faire une sauvegarde hors carte de la cl? de chiffrement ? (O/n) n gpg: NOTE: keys are already stored on the card! Remplacer les cl?s existantes ? (o/N) O PIN Sp?cifiez combien de temps cette cl? devrait ?tre valide. 0 = la cl? n'expire pas = la cl? expire dans n jours w = la cl? expire dans n semaines m = la cl? expire dans n mois y = la cl? expire dans n ann?es La cl? est valide pour ? (0) La cl? n'expire pas du tout Est-ce correct ? (o/N) O Vous avez besoin d'un nom d'utilisateur pour identifier votre cl?; le programme le construit ? partir du nom r?el, d'un commentaire et d'une adresse e-mail de cette mani?re: ? Heinrich Heine (Der Dichter) ? Nom r?el: vincent Adresse e-mail: vincent at vincent.com Commentaire: vincent Vous avez s?lectionn? ce nom d'utilisateur: "vincent (vincent) " Changer le (N)om, le (C)ommentaire, l'(E)-mail ou (O)K/(Q)uitter ? O gpg: la cl? existante sera remplac?e gpg: 3 tentatives de PIN admin restent jusqu'? ce que la carte soit irr?m?diablement bloqu?e code PIN d'administration gpg: attendez que la cl? se g?n?re... gpg: la g?n?ration de la cl? a ?chou? gpg: key generation failed: erreur g?n?rale La g?n?ration de cl? a ?chou?: erreur g?n?rale Commande> * From harry at linux.com Thu Feb 18 12:37:29 2010 From: harry at linux.com (Harry Rickards) Date: Thu, 18 Feb 2010 11:37:29 +0000 Subject: Voltage IBE Message-ID: Hi everyone, I appreciate that this may not be the right list, but does anyone know of a way to decrypt Voltage IBE encrypted messages without having to use the web interface at the third party server? The ciphertext seems to be contained in the actual message, as in the following example: -----BEGIN VOLTAGE SECURE BLOCK V3----- MIIlzgYJKoZIhvcNAQcDoIIlvzCCJbsCAQAxggJSMIIBIQIBADCBpDCBnjGBmzCB <...> fAspk82hzYpsCDlTeOp5pJsheULuI+qJk5vaJ3KzCaxakg=3D=3D -----END VOLTAGE SECURE BLOCK V3----- Anyone interested in helping to try and decrypt blocks like that and write a Firefox extension? -- Harry Rickards - harry at linux.com http://oftle.com From carlo.bramix at libero.it Thu Feb 18 18:20:46 2010 From: carlo.bramix at libero.it (carlo.bramix) Date: Thu, 18 Feb 2010 18:20:46 +0100 Subject: Release candidate for 2.0.15 Message-ID: Hello, I tried to compile gnupg-2.0.15rc1 under mingw+msys. Everything worked fine except the compilation of scd/ccid-driver.c It required two little fixes: 1) ETIMEDOUT is not defined by common windows headers, so libusb-win32 hardcoded this value into its sources. For this reason, it needs to be defined here too. 2) libusb-win32 cannot modify errno, so the error code is returned directly into the return value of various functions. After doing these fixes gnupg has been compiled successfully. I still need to test it under cygwin. Sincerely, Carlo Bramini. ---------- Initial Header ----------- >From : gnupg-devel-bounces at gnupg.org To : gnupg-users at gnupg.org Cc : gnupg-devel at gnupg.org Date : Thu, 18 Feb 2010 10:41:49 +0100 Subject : Release candidate for 2.0.15 > Hi! > > I just prepared a release candidate for GnuPG 2.0.15. The goal of this > release is to find out whether there are any severe build or runtime > bugs. There are actually not may changes: > > * New command --passwd for GPG. > > * Fixes a regression in 2.0.14 which prevented unprotection of new > or changed gpg-agent passphrases. > > * Make use of Libassuan 2.0 which is available as a DSO. > > as well as a couple of minor bug fixes and some changes to the German > translation. > > The major point is the move to Libassuan 2.0. This is the first version > of Libassuan which may be used as a shared library. We took this change > to cleanup the API a bit with the drawback that some changes to the > caller are required. > > To make development with Libassuan easier we need to get rid of > Libassuan 1 which developer's package can't be installed side by side > with Libassuan 2. Thus it is not easy to maintain software written with > version 1 and 2 at the same time. With the 2.0.15 release we will have > finished the migration of the GnuPG related tools to Libassuan 2. > > Please let us know if there are any problems building this release: > > ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.15rc1.tar.bz2 > ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.15rc1.tar.bz2.sig > > > > Shalom-Salam, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnupg.txt URL: From zy.zylek at gmail.com Sat Feb 20 03:53:11 2010 From: zy.zylek at gmail.com (Zy Zylek) Date: Fri, 19 Feb 2010 20:53:11 -0600 Subject: Questions about "--group" for group encryptions. Message-ID: <8794dff51002191853j667b9658tadf97419c5e7fa8b@mail.gmail.com> I'm looking for a way to include a group of people in gpg file encryption/decryption (not email-based, just gpg encrypted files) without having to incorporate individual names, yet also such that more people can be added to the group in the future and that they will be able to access previously encrypted files because they joined the group after the old files were encrypted. Does the "--group" option in gpg serve this purpose? Or is there another way to go about it? I checked the man file for gpg, read the bit on --group and similar group-related information and it has this: --group name=value1 Sets up a named group, which is similar to aliases in email pro? grams. Any time the group name is a recipient (-r or --recipi? ent), it will be expanded to the values specified. Multiple groups with the same name are automatically merged into a single group. The values are key IDs or fingerprints, but any key description is accepted. Note that a value with spaces in it will be treated as two different values. Note also there is only one level of expansion --- you cannot make an group that points to another group. When used from the command line, it may be necessary to quote the argument to this option to prevent the shell from treating it as multiple arguments. --ungroup name Remove a given entry from the --group list. --no-groups Remove all entries from the --group list. I found on a google search the following information someone provided regarding adding a line to the gpg.conf file: *group name_you_want_to_use = keyid1 keyid2 keyid3 keyid4* That is a little confusing. Does that mean that people with their own individual keys can be added or removed from the group? Does the group have its own key? If an individual's key is in the group then can they decrypt files that have been encrypted before they joined the group using the "group key" as recipient? But if their key has been removed from the group then can they still decrypt previous files that were encrypted using the "group key" as recipient? If I add people to a group via gpg.conf (using the line in bold type font above), and if I later want to add only one person to the group, can I add them with the gpg command with option "--group name=value1" or must I re-enter all of the previous keys in addition to the new one? If I want to remove only one person from the group, can I do that with either the gpg command and "--ungroup name" or alternately remove their key/name from the line in the gpg.conf file? Do I have to add their public key to my keyring before I can add their key to the group? If a "group key" (a singular "group recipient") can be created through either "--group" or the group line in the gpg.conf, and if I create a group, then will only I have administrative control over who is added/removed from the group, or will anybody in the group be able to add/remove anybody from the group? Thank you for your help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmoore3rd at bellsouth.net Sat Feb 20 05:31:50 2010 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Fri, 19 Feb 2010 23:31:50 -0500 Subject: Questions about "--group" for group encryptions. In-Reply-To: <8794dff51002191853j667b9658tadf97419c5e7fa8b@mail.gmail.com> References: <8794dff51002191853j667b9658tadf97419c5e7fa8b@mail.gmail.com> Message-ID: <4B7F65B6.1060800@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Zy Zylek wrote: > I'm looking for a way to include a group of people in gpg file > encryption/decryption (not email-based, just gpg encrypted files) > without having to incorporate individual names, yet also such that more > people can be added to the group in the future and that they will be > able to access previously encrypted files because they joined the group > after the old files were encrypted. > I found on a google search the following information someone provided > regarding adding a line to the gpg.conf file: > > *group name_you_want_to_use = keyid1 keyid2 keyid3 keyid4* > > That is a little confusing. > > Does that mean that people with their own individual keys can be added > or removed from the group? Yes > Does the group have its own key? No, in this instance the File, Email, etc. is encrypted to each of the Keys listed in the Group Line. > If an individual's key is in the group then can they decrypt files that > have been encrypted before they joined the group using the "group key" > as recipient? No. There is _no_ Group Key. An individual can only decrypt those Files encrypted to their Public Key so it must be present in the Group Line at the time of Encryption. > But if their key has been removed from the group then can they still > decrypt previous files that were encrypted using the "group key" as > recipient? See Above. Again, there is NO Group Key. Files are encrypted to every Key specified at the time of Encryption in the gpg.conf 'Group Line'. > If I add people to a group via gpg.conf (using the line in bold type > font above), and if I later want to add only one person to the group, > can I add them with the gpg command with option "--group name=value1" or > must I re-enter all of the previous keys in addition to the new one? Just add their Key ID to the end of the existing Line. Alternatively, if/when they leave the Group simply remove their Key ID from the 'Group Line'. > If I want to remove only one person from the group, can I do that with > either the gpg command and "--ungroup name" or alternately remove their > key/name from the line in the gpg.conf file? See previous answer. > Do I have to add their public key to my keyring before I can add their > key to the group? Yes. If You do not have their Key in Your Keyring there is no Key to encrypt to. Additionally, unless You also have the --trust-model always flag set then You will need to lsign each Key in the Group Line to prevent GPG from asking You if You really want to encrypt to each 'untrusted Key' listed. > If a "group key" (a singular "group recipient") can be created through > either "--group" or the group line in the gpg.conf, and if I create a > group, then will only I have administrative control over who is > added/removed from the group, or will anybody in the group be able to > add/remove anybody from the group? Additions & Subtractions from the Group Encryption will need to be managed by _every_ individual Encrypting to the Group. A 'Group Key' is generally recognized as a single Keypair that every Member of the Group has both the Public & Private part. With a 'Group Key' everyone Encrypts to and Decrypts with the Group Keypair. JOHN ;) Timestamp: Friday 19 Feb 2010, 23:31 --500 (Eastern Standard Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Personal Web Page: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJLf2WzAAoJEBCGy9eAtCsPzfsH/jBeCkGK3ZSd38hHHVw3gqp1 cqjtn83J6RcsR7RX7aUAYX30ZvUUSRFvbmTZ1/zGCiVNoWTOilawwukhiBSvBNte uhc5SjEmCOU3rk9tug1uQn7gQIPiE3LQ5OgvdqHF8pMck9yXPfXcd5hOPPPWj7V0 jvDQX6ZF2rVdRNp67L7hxk5rN0v1Cdm6Gqig/LWGtwFO3UGjFgu8ymBFyA6zYWD/ hdkc6IEB1a6rhomSAUmpGmy8WZ1AiwYiP0JNM/E47LUwvbMAPcIUMqkfIPsWQg7y SrcChdKfsfPGamFtIiQNFSfBRVUkx6iDnwonhHNTYVBgOVWGisdtOd7Rc8s1rEA= =vMBG -----END PGP SIGNATURE----- From dougb at dougbarton.us Sat Feb 20 06:45:58 2010 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 19 Feb 2010 21:45:58 -0800 Subject: Questions about "--group" for group encryptions. In-Reply-To: <8794dff51002191853j667b9658tadf97419c5e7fa8b@mail.gmail.com> References: <8794dff51002191853j667b9658tadf97419c5e7fa8b@mail.gmail.com> Message-ID: <4B7F7716.4050305@dougbarton.us> On 02/19/10 18:53, Zy Zylek wrote: > I'm looking for a way to include a group of people in gpg file > encryption/decryption (not email-based, just gpg encrypted files) > without having to incorporate individual names, yet also such that more > people can be added to the group in the future and that they will be > able to access previously encrypted files because they joined the group > after the old files were encrypted. I'm pretty sure that what you want to accomplish can't be done the way you're describing it, but let's take a step back and work on the description of the problem a bit more. I think I understand what you've described above as far as it goes, but how about a little more detail? Are you working with one file, or a lot of files? Will the set of files be static, or at some future time might more files be added to the list of things that the users will need to access? Will the users be given copies of the encrypted files? The reason for all these questions is that different solutions may be possible based on the answers to them. hope this helps, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From reynt0 at cs.albany.edu Sat Feb 20 21:13:14 2010 From: reynt0 at cs.albany.edu (reynt0) Date: Sat, 20 Feb 2010 15:13:14 -0500 (EST) Subject: Questions about "--group" for group encryptions. In-Reply-To: <8794dff51002191853j667b9658tadf97419c5e7fa8b@mail.gmail.com> References: <8794dff51002191853j667b9658tadf97419c5e7fa8b@mail.gmail.com> Message-ID: On Fri, 19 Feb 2010, Zy Zylek wrote: > I'm looking for a way to include a group of people in gpg file > encryption/decryption (not email-based, just gpg encrypted files) without > having to incorporate individual names, yet also such that more people can > be added to the group in the future and that they will be able to access > previously encrypted files because they joined the group after the old files > were encrypted. . . . I hope the following isn't just a waste of bandwidth, but: Stepping back from the details (omitted from my quote of your post) of your original question, and trying to clarify just your first statement (quoted above): Is what you want a full many-to-many encryption/decryption functionality with minimum keyage and non-static membership in "many"? With public key encryption a basic practice is that encryption (speaking only of encryption here, not authentication) is done using public key, and decryption is done using private key. By that model maybe what you describe is some PuK which "many" knows and can encrypt with, and an associated PrK which "many" also knows and can decrypt with? And people can be added to "many" as you please? Otherwise than this many-to-many, it might sound like what you want is expandable/deflatable set of "ones" for mass one-to-one, which would involve the complexity and time to manage encryption to a different PuK for each "one" in the set, including each "one" in a currrent set would need to know the PuK of every other "one" in that set. And when a new "one" were added to the set, in order to give them access to past encrypted files somehow all previously encrypted files would have to be reencrypted to the new "one"'s PuK so the new "one" too could read the old files. Alternatively, if what you want is one-to-many, you can see how that could be arranged similar to either of the above. The many-to-many might be considered a low-security plan since any member of "many" could reveal the group PrK and thereby make all future as well as past files insecure. In the mass one-to-one, any "one" (one person, not one group, since the real trust locus is person, not key) also could break security by revealing the PrK used by that "one" for the group, but they would have also to reveal individual files as encrypted to their PuK in order for their PrK to be used to decrypt. And files encrypted after the revealer left the group would not have been encrypted to the revealer's PuK. Related issues include how keys are communicated, and where the files might be including to what extent files might be communicated as distinct from being stored. From dshaw at jabberwocky.com Sat Feb 20 23:37:02 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 20 Feb 2010 17:37:02 -0500 Subject: Questions about "--group" for group encryptions. In-Reply-To: <8794dff51002191853j667b9658tadf97419c5e7fa8b@mail.gmail.com> References: <8794dff51002191853j667b9658tadf97419c5e7fa8b@mail.gmail.com> Message-ID: <8675DF39-2B4E-4150-80B7-A64B24B6C6B2@jabberwocky.com> On Feb 19, 2010, at 9:53 PM, Zy Zylek wrote: > I'm looking for a way to include a group of people in gpg file encryption/decryption (not email-based, just gpg encrypted files) without having to incorporate individual names, yet also such that more people can be added to the group in the future and that they will be able to access previously encrypted files because they joined the group after the old files were encrypted. > > Does the "--group" option in gpg serve this purpose? No. The group option creates a group of keys, not a key that covers a given group. In other words, you can get your first requirement (encrypt to a group of people in one shot), but not your second (if more people are added to the group, they will not be able to access previously encrypted data). > Or is there another way to go about it? An easy way would be to make a group key and give each person access to it. The problem is that if you need to support people leaving the group, the old members can still decrypt... David From rich.geddes at verizon.net Sun Feb 21 14:40:04 2010 From: rich.geddes at verizon.net (Richard Geddes) Date: Sun, 21 Feb 2010 08:40:04 -0500 Subject: Shamir's Secret Sharing Scheme integration? Message-ID: <4B8137B4.5030909@verizon.net> Hello, Is there a utility that integrates gnupg with ssss (Shamir's Secret Sharing Scheme)? And maybe using smartcards? If not has anyone seen a HowTo that shows how to integrate them? Richard From classpath at arcor.de Mon Feb 22 00:47:00 2010 From: classpath at arcor.de (Morten Gulbrandsen) Date: Mon, 22 Feb 2010 00:47:00 +0100 Subject: Voltage IBE In-Reply-To: References: Message-ID: <4B81C5F4.2080005@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Harry Rickards wrote: > Hi everyone, > > I appreciate that this may not be the right list, but does anyone know > of a way to decrypt Voltage IBE encrypted messages without having to > use the web interface at the third party server? The ciphertext seems > to be contained in the actual message, as in the following example: This is identity based encryption, I've heard about it. http://www.voltage.com/technology/ibe.htm Identity-Based Encryption (IBE) takes a completely new approach to the problem of encryption. IBE can use any arbitrary string as a public key, enabling data to be protected without the need for certificates. Protection is provided by a key server that controls the mapping of identities to decryption keys. It looks similar to vanish, which is time stamped and duration dependent. Also no encryption, only to a time frame. I only know and understand S/MIME and OpenPGP. IBE Identity based encryption is supposed to be easier than OpenPGP. If I remember correctly. Identity-based encryption (IBE) is a public-key encryption technology that allows a public key to be calculated from an identity, and the corresponding private key to be calculated from the public key. http://www.rfc-editor.org/rfc/rfc5091.txt Looks insecure to me. Sincerely yours, ??? ?????? Morten Gulbrandsen _____________________________________________________________________ Java programmer, C++ programmer CAcert Assurer, GSWoT introducer, Gossamer Spider Web of Trust http://www.gswot.org Please consider the environment before printing this e-mail! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: For keyID and its URL see the OpenPGP message header iEYEAREIAAYFAkuBxfQACgkQ9ymv2YGAKVQ56wCgv6TJu0S1dh3Ss/9dVCmeiYnX 7ikAnRpZgDTtkyjszHR9k01uDbF5VXLz =mxWG -----END PGP SIGNATURE----- From stefanxe at gmx.net Mon Feb 22 09:23:08 2010 From: stefanxe at gmx.net (Stefan Xenon) Date: Mon, 22 Feb 2010 09:23:08 +0100 Subject: Shamir's Secret Sharing Scheme integration? In-Reply-To: <4B8137B4.5030909@verizon.net> References: <4B8137B4.5030909@verizon.net> Message-ID: <4B823EEC.1090003@gmx.net> Hi Richard, I don't know any integration in GnuPG but instead the following open source implementatio may worth a try: http://point-at-infinity.org/ssss/ Regards Stefan Am 21.02.2010 14:40, schrieb Richard Geddes: > Hello, > > Is there a utility that integrates gnupg with ssss (Shamir's Secret > Sharing Scheme)? And maybe using smartcards? If not has anyone seen a > HowTo that shows how to integrate them? > > Richard > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From fweimer at bfk.de Mon Feb 22 09:32:33 2010 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 22 Feb 2010 08:32:33 +0000 Subject: Shamir's Secret Sharing Scheme integration? In-Reply-To: <4B823EEC.1090003@gmx.net> (Stefan Xenon's message of "Mon\, 22 Feb 2010 09\:23\:08 +0100") References: <4B8137B4.5030909@verizon.net> <4B823EEC.1090003@gmx.net> Message-ID: <82mxz1acwu.fsf@mid.bfk.de> * Stefan Xenon: > I don't know any integration in GnuPG but instead the following open > source implementatio may worth a try: http://point-at-infinity.org/ssss/ IIRC, this particular software does not implement Shamir's scheme. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From wk at gnupg.org Mon Feb 22 10:41:58 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Feb 2010 10:41:58 +0100 Subject: Shamir's Secret Sharing Scheme integration? In-Reply-To: <4B8137B4.5030909@verizon.net> (Richard Geddes's message of "Sun, 21 Feb 2010 08:40:04 -0500") References: <4B8137B4.5030909@verizon.net> Message-ID: <87ocjh8v4p.fsf@vigenere.g10code.de> On Sun, 21 Feb 2010 14:40, rich.geddes at verizon.net said: > Is there a utility that integrates gnupg with ssss (Shamir's Secret > Sharing Scheme)? And maybe using smartcards? If not has anyone seen > a HowTo that shows how to integrate them? I don't know of a complete solution but Phil Sutter wrote his master thesis on this. See http://lists.gnupg.org/pipermail/gnupg-devel/2008-July/024506.html The code is at: http://nwl.cc/cgi-bin/git/gitweb.cgi?p=ssd.git;a=summary Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From danm at prime.gushi.org Mon Feb 22 18:31:49 2010 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Mon, 22 Feb 2010 12:31:49 -0500 (EST) Subject: Shamir's Secret Sharing Scheme integration? In-Reply-To: <4B8137B4.5030909@verizon.net> References: <4B8137B4.5030909@verizon.net> Message-ID: On Sun, 21 Feb 2010, Richard Geddes wrote: > Hello, > > Is there a utility that integrates gnupg with ssss (Shamir's Secret Sharing > Scheme)? And maybe using smartcards? If not has anyone seen a HowTo that > shows how to integrate them? I....kinda do. I encoded my will with it before some surgery a few years ago, and documented it in the process, along with some other notes on short circuiting the whole thing. Have a look at www.gushi.org/willworks.txt -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From rich.geddes at verizon.net Tue Feb 23 05:46:14 2010 From: rich.geddes at verizon.net (Richard Geddes) Date: Mon, 22 Feb 2010 23:46:14 -0500 Subject: Shamir's Secret Sharing Scheme integration? In-Reply-To: <4B8137B4.5030909@verizon.net> References: <4B8137B4.5030909@verizon.net> Message-ID: <4B835D96.1010702@verizon.net> Thanks for all the input... good stuff. I can think of a bash script that - generates the passphrase (using /dev/urandom) for a gnupg private key, - pipe the random passphrase into ssss to generate the shares, threshold (s,t), - and every time the passphrase is needed, combine t shares to recreate the original random passphrase. A problem I see with this approach is that an attacker can easily modify the script to output the shares... breaking confidentiality. Even binary code can be reverse-compiled and re-engineered to spill the secrets. Does anyone know of techniques to protect code from being reverse engineered with standard off the shelf techniques...? Thanks Richard Geddes wrote: > Hello, > > Is there a utility that integrates gnupg with ssss (Shamir's Secret > Sharing Scheme)? And maybe using smartcards? If not has anyone seen > a HowTo that shows how to integrate them? > > Richard > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From fweimer at bfk.de Tue Feb 23 08:39:17 2010 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 23 Feb 2010 07:39:17 +0000 Subject: Shamir's Secret Sharing Scheme integration? In-Reply-To: (Roscoe's message of "Tue\, 23 Feb 2010 18\:08\:26 +1100") References: <4B8137B4.5030909@verizon.net> <4B823EEC.1090003@gmx.net> <82mxz1acwu.fsf@mid.bfk.de> Message-ID: <82k4u42yfu.fsf@mid.bfk.de> * Roscoe: > On Mon, Feb 22, 2010 at 7:32 PM, Florian Weimer wrote: >> * Stefan Xenon: >> >>> I don't know any integration in GnuPG but instead the following open >>> source implementatio may worth a try: http://point-at-infinity.org/ssss/ >> >> IIRC, this particular software does not implement Shamir's scheme. > > And what makes you think that? The existence of the -D option. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From eocsor at gmail.com Tue Feb 23 08:08:26 2010 From: eocsor at gmail.com (Roscoe) Date: Tue, 23 Feb 2010 18:08:26 +1100 Subject: Shamir's Secret Sharing Scheme integration? In-Reply-To: <82mxz1acwu.fsf@mid.bfk.de> References: <4B8137B4.5030909@verizon.net> <4B823EEC.1090003@gmx.net> <82mxz1acwu.fsf@mid.bfk.de> Message-ID: On Mon, Feb 22, 2010 at 7:32 PM, Florian Weimer wrote: > * Stefan Xenon: > >> I don't know any integration in GnuPG but instead the following open >> source implementatio may worth a try: http://point-at-infinity.org/ssss/ > > IIRC, this particular software does not implement Shamir's scheme. And what makes you think that? -- Roscoe From carlos.chavez.p at gmail.com Tue Feb 23 20:34:11 2010 From: carlos.chavez.p at gmail.com (Carlos Chavez) Date: Tue, 23 Feb 2010 13:34:11 -0600 Subject: How to sign an email in PHP? Message-ID: <916020b41002231134o32de67a1g6d4ac622a1032504@mail.gmail.com> I am having trouble figuring out how to send a gpg signed email from PHP. I can generate the message, sign it with a detached signature and then include the signature in the message. The problem is that my mail program (Evolution on Linux) always tells me that the signature is invalid. Anyone have an example of how to do this in PHP? I am using the GNUpg functions in PHP (http://www.php.net/manual/en/ref.gnupg.php). Exactly when do I sign the message? Right now I sign the plaintext body of the mail before I add any of the headers for the message boundaries, then do the skeleton where I insert the body and then the signature. Thank you for the help. -- -- Carlos Chavez -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgo at grant-olson.net Wed Feb 24 00:23:42 2010 From: kgo at grant-olson.net (Grant Olson) Date: Tue, 23 Feb 2010 18:23:42 -0500 Subject: How to sign an email in PHP? In-Reply-To: <916020b41002231134o32de67a1g6d4ac622a1032504@mail.gmail.com> References: <916020b41002231134o32de67a1g6d4ac622a1032504@mail.gmail.com> Message-ID: <4B84637E.1070600@grant-olson.net> On 2/23/2010 2:34 PM, Carlos Chavez wrote: > I am having trouble figuring out how to send a gpg signed email > from PHP. I can generate the message, sign it with a detached signature > and then include the signature in the message. The problem is that my > mail program (Evolution on Linux) always tells me that the signature is > invalid. > > Anyone have an example of how to do this in PHP? I am using the > GNUpg functions in PHP (http://www.php.net/manual/en/ref.gnupg.php). > Exactly when do I sign the message? Right now I sign the plaintext body > of the mail before I add any of the headers for the message boundaries, > then do the skeleton where I insert the body and then the signature. > > Thank you for the help. > > -- > -- > Carlos Chavez > Are you attaching it as a normal attachment? Does PHP support pgp/mime? If you even end up accidentally adding a few CRLFs to the body of the PHP message when you fill in the skeleton, that would invalidate the signature. Is there a reason you don't want to clearsign the message? I think it'd be easier to do that. Clearsign and then use the clear signature as email body. That's basically how this email is signed. Then even if you have a few extra linefeeds before or after, the client will say that the message is partially signed. It'll have delimiters built into the text so that any extra stuff won't matter. I think that'll be a lot easier to debug. If it's not working you can view the raw source, save it somewhere, and run gpg commands manually. On the downside, it'll look uglier to clients that aren't configured for gpg. From carlos.chavez.p at gmail.com Wed Feb 24 04:06:51 2010 From: carlos.chavez.p at gmail.com (Carlos Chavez) Date: Tue, 23 Feb 2010 21:06:51 -0600 Subject: How to sign an email in PHP? In-Reply-To: <4B84637E.1070600@grant-olson.net> References: <916020b41002231134o32de67a1g6d4ac622a1032504@mail.gmail.com> <4B84637E.1070600@grant-olson.net> Message-ID: <916020b41002231906j78a750e9we211faf93690507b@mail.gmail.com> On Tue, Feb 23, 2010 at 5:23 PM, Grant Olson wrote: > On 2/23/2010 2:34 PM, Carlos Chavez wrote: > > I am having trouble figuring out how to send a gpg signed email > > from PHP. I can generate the message, sign it with a detached signature > > and then include the signature in the message. The problem is that my > > mail program (Evolution on Linux) always tells me that the signature is > > invalid. > > > > Anyone have an example of how to do this in PHP? I am using the > > GNUpg functions in PHP (http://www.php.net/manual/en/ref.gnupg.php). > > Exactly when do I sign the message? Right now I sign the plaintext body > > of the mail before I add any of the headers for the message boundaries, > > then do the skeleton where I insert the body and then the signature. > > > > Thank you for the help. > > > > -- > > -- > > Carlos Chavez > > > Are you attaching it as a normal attachment? Does PHP support pgp/mime? > > If you even end up accidentally adding a few CRLFs to the body of the > PHP message when you fill in the skeleton, that would invalidate the > signature. > > Is there a reason you don't want to clearsign the message? I think it'd > be easier to do that. Clearsign and then use the clear signature as > email body. That's basically how this email is signed. > > Then even if you have a few extra linefeeds before or after, the client > will say that the message is partially signed. It'll have delimiters > built into the text so that any extra stuff won't matter. > > I think that'll be a lot easier to debug. If it's not working you can > view the raw source, save it somewhere, and run gpg commands manually. > On the downside, it'll look uglier to clients that aren't configured for > gpg. > > I am trying to emulate the way Evolution creates the email so the message will look fine in clients that do not support GPG directly, that is a requirement. I have tried to create the complete message by manually using all the headers I find from my Evolution sent messages. It all seems to work but like I said I always get an error saying that the signature does not match. I guess something in my code is introducing a line feed somewhere but I can not see it. I am also trying to do it using the PEAR extension Mail_mime but I am still having the same problem. I guess there may also be a missing header but I am still going through the documentarion for the pear class which is not very clear. Doing the clearsign works but most customers receiving messages from this system will not have GPG installed or use a compatible client. I will also need to add attachments for documents which are not a problem by themselves but then I will have to make sure they also get signed. -- -- Carlos Chavez -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgo at grant-olson.net Wed Feb 24 04:29:22 2010 From: kgo at grant-olson.net (Grant Olson) Date: Tue, 23 Feb 2010 22:29:22 -0500 Subject: How to sign an email in PHP? In-Reply-To: <916020b41002231906j78a750e9we211faf93690507b@mail.gmail.com> References: <916020b41002231134o32de67a1g6d4ac622a1032504@mail.gmail.com> <4B84637E.1070600@grant-olson.net> <916020b41002231906j78a750e9we211faf93690507b@mail.gmail.com> Message-ID: <4B849D12.1070609@grant-olson.net> On 2/23/2010 10:06 PM, Carlos Chavez wrote: > > I am trying to emulate the way Evolution creates the email so the > message will look fine in clients that do not support GPG directly, that > is a requirement. I have tried to create the complete message by > manually using all the headers I find from my Evolution sent messages. > It all seems to work but like I said I always get an error saying that > the signature does not match. I guess something in my code is > introducing a line feed somewhere but I can not see it. I am also > trying to do it using the PEAR extension Mail_mime but I am still having > the same problem. > > I guess there may also be a missing header but I am still going > through the documentarion for the pear class which is not very clear. > Doing the clearsign works but most customers receiving messages from > this system will not have GPG installed or use a compatible client. I > will also need to add attachments for documents which are not a problem > by themselves but then I will have to make sure they also get signed. > The kicker is that pgp/mime messages will look weird in Outlook Express or Windows Live Mail. According to the RFC ( http://www.ietf.org/rfc/rfc2015.txt ), most of the headers exist outside of the message, so if you're putting them in the message body before signing that isn't right. The only headers that should exist in the message body are Content-Type and Content-Transfer-Encoding. And you'll need to have all the line wraps and line feeds figured out before signing. If you've got lines longer than the 80 characters or so permitted, you'd need to fix that before signing. There's a pretty good example on the rfc page. I'd try to see if you can print or save the entire message as a text file from php before sending. See how it compares to the example from the rfc instead or trying to reverse engineer what you have in evolution. Example message: From: Michael Elkins To: Michael Elkins Mime-Version: 1.0 Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; protocol="application/pgp-signature" --bar & Content-Type: text/plain; charset=iso-8859-1 & Content-Transfer-Encoding: quoted-printable & & =A1Hola! & & Did you know that talking to yourself is a sign of senility? & & It's generally a good idea to encode lines that begin with & From=20because some mail transport agents will insert a greater- & than (>) sign, thus invalidating the signature. & & Also, in some cases it might be desirable to encode any =20 &railing whitespace that occurs on lines in order to ensure =20 & that the message signature is not invalidated when passing =20 & a gateway that modifies such whitespace (like BITNET). =20 & & me --bar Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI= =ndaj -----END PGP MESSAGE----- --bar-- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From gesbbb at yahoo.com Wed Feb 24 17:18:03 2010 From: gesbbb at yahoo.com (Jerry) Date: Wed, 24 Feb 2010 11:18:03 -0500 Subject: How to sign an email in PHP? In-Reply-To: <4B849D12.1070609@grant-olson.net> References: <916020b41002231134o32de67a1g6d4ac622a1032504@mail.gmail.com> <4B84637E.1070600@grant-olson.net> <916020b41002231906j78a750e9we211faf93690507b@mail.gmail.com> <4B849D12.1070609@grant-olson.net> Message-ID: <20100224111803.0eb14527@scorpio.seibercom.net> On Tue, 23 Feb 2010 22:29:22 -0500 Grant Olson articulated: > The kicker is that pgp/mime messages will look weird in Outlook > Express or Windows Live Mail. Outlook Express is depreciated. In any case, the messages will probably not display correctly in several MUAs, such as web based GMail, Juno, etc. -- Jerry gesbbb at yahoo.com |::::======= |::::======= |=========== |=========== | The broad mass of a nation... will more easily fall victim to a big lie than to a small one. Adolf Hitler, "Mein Kampf" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From l.bigonville at edpnet.be Wed Feb 24 18:26:46 2010 From: l.bigonville at edpnet.be (Laurent Bigonville) Date: Wed, 24 Feb 2010 18:26:46 +0100 Subject: SHA2 digest on gpg smartcard In-Reply-To: <20100217184602.65e73819@fornost.bigon.be> References: <20100217184602.65e73819@fornost.bigon.be> Message-ID: <20100224182646.79486640@fornost.bigon.be> Hi (again), nobody knows? :( Laurent Bigonville Le Wed, 17 Feb 2010 18:46:02 +0100, Laurent Bigonville a ?crit : > Hi, > > I've have a OpenGPG smartcard version 2.0 and I would generate digests > stronger than SHA1. > > I've added "personal-digest-preferences SHA256" to my gpg.conf file, > but when I sign a message the headers still uses SHA1. If I force with > --digest-algo (which is not recommended according to the doc) to > SHA256 it works and I'm able to verify the signature. > > I've opened a bug[1], but I was told that it was not a bug. > Then could someone enlighten me about the reasons of this? > > Cheers > > Laurent Bigonville > > [1] https://bugs.g10code.com/gnupg/issue1194 From laurent.jumet at skynet.be Wed Feb 24 18:40:29 2010 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Wed, 24 Feb 2010 18:40:29 +0100 Subject: SHA2 digest on gpg smartcard In-Reply-To: <20100224182646.79486640@fornost.bigon.be> Message-ID: Hello Laurent ! Laurent Bigonville wrote: >> I've have a OpenGPG smartcard version 2.0 and I would generate digests >> stronger than SHA1. >> >> I've added "personal-digest-preferences SHA256" to my gpg.conf file, >> but when I sign a message the headers still uses SHA1. If I force with >> --digest-algo (which is not recommended according to the doc) to >> SHA256 it works and I'm able to verify the signat ure. >> >> I've opened a bug[1], but I was told that it was not a bug. >> Then could someone enlighten me about the reasons of this? In GPG.conf, you may put *your* preferences that will be confronted to those in the receipient key. I suppose the receipient you are encrypting to, doesn't support higher schemes. This is an opinion. I've this in my gpg.conf but don't forget you need to save your key after new settings and upload it to servers: default-preference-list S7 S11 S12 S13 S1 S10 S3 S4 S2 S9 S8 H3 H8 H9 H10 H11 H2 H1 Z1 Z2 Z3 Z0 personal-cipher-preferences S7 S11 S12 S13 S1 S10 S3 S4 S2 S9 S8 personal-digest-preferences H3 H8 H9 H10 H11 H2 H1 personal-compress-preferences Z1 Z2 Z3 Z0 To set the preferences, this can help (use H8 for SHA256): ?????????????????????????????????????????????????????????? ? Cipher-Algos: ? Digest-Algos: ? Compress-Algos: ? ?????????????????????????????????????????????????????????? ? ? ? Z0 Uncompressed ? ? S1 IDEA ? H1 MD5 ? Z1 ZIP ? ? S2 3DES ? H2 SHA1 ? Z2 ZLIB ? ? S3 CAST5 ? H3 RIPEMD160 ? Z3 BZIP2 ? ? S4 BLOWFISH ? ? ? ? ? ? ? ? ? ? ? ? S7 AES ? ? ? ? S8 AES192 ? H8 SHA256 ? ? ? S9 AES256 ? H9 SHA384 ? ? ? S10 TWOFISH ? H10 SHA512 ? ? ? S11 CAMELLIA128 ? H11 SHA224 ? ? ? S12 CAMELLIA192 ? ? ? ? S13 CAMELLIA256 ? ? ? ?????????????????????????????????????????????????????????? -- Laurent Jumet KeyID: 0xCFAF704C From dshaw at jabberwocky.com Wed Feb 24 19:25:17 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 24 Feb 2010 13:25:17 -0500 Subject: SHA2 digest on gpg smartcard In-Reply-To: <20100217184602.65e73819@fornost.bigon.be> References: <20100217184602.65e73819@fornost.bigon.be> Message-ID: <8FB55E7B-FB46-497E-93AA-B35B78EBA57F@jabberwocky.com> On Feb 17, 2010, at 12:46 PM, Laurent Bigonville wrote: > Hi, > > I've have a OpenGPG smartcard version 2.0 and I would generate digests > stronger than SHA1. > > I've added "personal-digest-preferences SHA256" to my gpg.conf file, > but when I sign a message the headers still uses SHA1. If I force with > --digest-algo (which is not recommended according to the doc) to SHA256 > it works and I'm able to verify the signature. > > I've opened a bug[1], but I was told that it was not a bug. > Then could someone enlighten me about the reasons of this? I'm looking at this, and it seems the code that selects a hash does not currently differentiate between the V1 card (where only 160-bit hashes were usable) and the V2 card (where other hashes are possible). David From rjh at sixdemonbag.org Wed Feb 24 21:26:46 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 24 Feb 2010 15:26:46 -0500 Subject: How to sign an email in PHP? In-Reply-To: <20100224111803.0eb14527@scorpio.seibercom.net> References: <916020b41002231134o32de67a1g6d4ac622a1032504@mail.gmail.com> <4B84637E.1070600@grant-olson.net> <916020b41002231906j78a750e9we211faf93690507b@mail.gmail.com> <4B849D12.1070609@grant-olson.net> <20100224111803.0eb14527@scorpio.seibercom.net> Message-ID: <4B858B86.1000502@sixdemonbag.org> On 2/24/10 11:18 AM, Jerry wrote: > Outlook Express is depreciated. Outlook Express is deprecated, and many people here throw deprecations against it -- but Outlook Express is still one of the most common MUAs in existence, and for that reason alone the PGP/MIME interoperability problem should be taken seriously. From zy.zylek at gmail.com Wed Feb 24 21:33:47 2010 From: zy.zylek at gmail.com (Zy Zylek) Date: Wed, 24 Feb 2010 14:33:47 -0600 Subject: Questions about "--group" for group encryptions. In-Reply-To: <8675DF39-2B4E-4150-80B7-A64B24B6C6B2@jabberwocky.com> References: <8794dff51002191853j667b9658tadf97419c5e7fa8b@mail.gmail.com> <8675DF39-2B4E-4150-80B7-A64B24B6C6B2@jabberwocky.com> Message-ID: <8794dff51002241233o29aad858idf8c39f7f2199f32@mail.gmail.com> Hello, I have been wanting to respond to the replies, and am now finally able to. :) First, thank you to those who replied and offered the input. In response to your replies... RE: Adding/removing individual keys to/from a group: The --group (or group config line) feature makes better sense now. I understand now that individual keys can be added to or removed from a group but the group function applies to each individual key within it. RE: "Group Key": While --group has nothing to do with a "group key", it looks like I can create a public/private key pair and designate it as a group key. There is a reduced level of effectiveness using this approach, yet it appears to be the only effective means of a true group-based (not several individual-keys based) type of shared encryption/decryption of files, and in a way that might allow for the addition of new members to the group. Though, I suspect if someone is removed that a new "group key" pair might have to be created, which (if it happens often) might be a bit tedious. RE: --group option, and adding individuals' public keys: That makes sense - that I'd have to add "--group" members' public keys to my keyring before I can add them to the "--group" list. RE: --trust-model always flag set and "lsign": What are the pros/cons to using that flag? At the moment, my main private/public keypair has not (yet) been verified by a proper trust-type authority (via photo ID, etc., etc.). I almost had it verified a while back but was unable to meet with the person. RE: Additions/subtractions from "--group" encryption requiring *every* individual managing the group list separately: Does this basically mean that, although one individual might have the same recurring list of individuals (not requiring change), that the "--group" function is essentially a one-time-only every-time type of feature (if another individual in that group ends up adding/removing someone)? RE: "Group Key" again: While it's possible to use a shared group key, which allows for everyone to encrypt/decrypt with that group keypair, is it possible to increase the security (at least a little) - to prevent just anyone from getting the group keypair - by requiring one specific user (or one user's individual keypair) to serve as a means of authentication for permitting a new person to receive that shared group keypair? RE: "I think I understand what you've described above as far as it goes, but how about a little more detail?" I think that my concept is perhaps the reverse of the "--group" gpg feature. Rather than have a list of public keys of different individuals compiled as a group, which also allows for any member of that group to alter who is included/excluded, I'd like to have one single group keypair (or an alternative to this, if one is available) with which only I can add/remove which public keys of different individuals have access to either that group keypair (or alternative). RE: "Are you working with one file, or a lot of files?" A lot of files. RE: "Will the set of files be static, or at some future time might more files be added to the list of things that the users will need to access?" If you mean static similar to how one might compare static to dynamic, then the files will be static, in the sense that they will not be edited in the future. However, at some future time there will definitely be more (new) files added to the list of things that users will need to access. RE: "Will the users be given copies of the encrypted files?" I'm not sure I understand your question. In the literal sense, yes. This might help a little: User A is group admin, she has file 1, she encrypts it for the group. Any user with access to group-encrypted files can decrypt file 1. User B has file 2, she encrypts it for the group. Any user with access to group-encrypted files can decrypt file 2. User C has file 3, she encrypts it for the group. Any user with access to group-encrypted files can decrypt file 3. User A removes User B from the group, "B" can no longer encrypt/decrypt. User B has no access to group-encrypted files (old: 1, 2, 3, or new: 4+). User A adds User D to the group, "D" has access to group-encrypted files. User D has access to group-encrypted files (old: 1, 2, 3, or new: 4+). User D has file 4, she encrypts it for the group. Any user with access to group-encrypted files can decrypt file 4. RE: "Is what you want a full many-to-many encryption/decryption functionality with minimum keyage and non-static membership in "many"?" I think my ABCD/1234 example above pretty much sums things up but let me see if I understand what you're asking. By "full many-to-many encryption/decryption functionality", do you mean many people and many files? Basically yes (to that). By "minimum keyage", do you mean functionality with as few keys as possible? If that, then not necessarily. If it is possible to collaborate the advantages of having a different key per individual, and yet they all depend on one group keypair (that only User A administrates (adds/removes individuals' keys)) in order to encrypt/decrypt group files, then I do not want minimum keyage (if that's what that means). RE: "By that model maybe what you describe is some PuK which "many" knows and can encrypt with, and an associated PrK which "many" also knows and can decrypt with?" Referencing the model you mentioned - that is using public key to encrypt and private key to decrypt - it sounds like it might (or might not?) be possible (or useful?) to have a separate group public key and a separate group private key, yet to not have them actually function as a "pair" (together), or are you asking something else? I'm not sure I understand that question. RE: "And people can be added to "many" as you please?" If I understand correctly, then yes, adding or removing individuals only by the administrator of the group-key (or group-keypair). RE: "...expandable/deflatable set of "ones" for mass one-to-one..." I don't understand that, sorry, could you paraphrase your "one" and "one" type description that you provided? It was somewhat confusing. Here is your original explanation: "...which would involve the complexity and time to manage encryption to a different PuK for each "one" in the set, including each "one" in a currrent set would need to know the PuK of every other "one" in that set. And when a new "one" were added to the set, in order to give them access to past encrypted files somehow all previously encrypted files would have to be reencrypted to the new "one"'s PuK so the new "one" too could read the old files." Does your explanation match my User A, B, C, D and file 1, 2, 3, 4 example? RE: "Alternatively, if what you want is one-to-many, you can see how that could be arranged similar to either of the above." I might be confusing what "many-to-many", "one-to-many", or "one-to-one" mean). What do those terms mean? This might not makes, mostly because I don't think I yet understand those 3 terms, but I would be interested in implemented a "layered" type of approach if necessary, where potential low-security methods of one approach could be remedied if that approach is "contained within" a higher-security method of another approach. (I hope that didn't sound confusing.) Thank you everybody for your responses! -------------- next part -------------- An HTML attachment was scrubbed... URL: From staxcoding at googlemail.com Wed Feb 24 23:14:51 2010 From: staxcoding at googlemail.com (Tobias Holz) Date: Wed, 24 Feb 2010 23:14:51 +0100 Subject: key question Message-ID: <4B85A4DB.9030108@googlemail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Folks, i succesfully installed gnupg on my Win7 machine. I want to use it with Thunderbird to encrypt personal eMails. Now I've got some questions: 1) What does happen if I lose my private key? Can I burn it to a CD/DVD? 2) Where can I find the key, I just got the passphrase? I generated the Keys with OpenPGP-Plugin for Thunderbird. I got the public key (something_stands_here.asc) and encryption works fine :) Hopefully looking forward Tobias - -- StaxCoding by Tobias Holz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJLhaTaAAoJEJElIS/9dKMdxGoH/jOMNzar3xr7+gdm1r6rhjA3 mEAkFT80uDntEonBHMT1XGpnqxTx+rXkAo/5RnWyHCoOtf/YufPlbsJZPxYAIpFz xtqKD+x/O0l5j89vtFeBEK33PCGPz9e+a4+LPBrBKmtwbbEJ9MreIdibAyphLMva grSoharm+4+SdvbAeD5a0hpzjp6WS7JklG80Ja0KHtoXI0XDSDgQhnOGJv2p+wLG 5D0IhIOIlKqQtJNXzWs9IsdTFW6n6N1FB3Y0vf4XSte3vgNgfdw9PNhi4hW0DpB2 vRGCALPH+f/oqEEJErAbvJgyBnZM/K2Vi0nAELUaJ6ijnCsmCC7i+xF42bOGZIQ= =Bud6 -----END PGP SIGNATURE----- From kgo at grant-olson.net Thu Feb 25 00:30:16 2010 From: kgo at grant-olson.net (Grant Olson) Date: Wed, 24 Feb 2010 18:30:16 -0500 Subject: Questions about "--group" for group encryptions. In-Reply-To: <8794dff51002241233o29aad858idf8c39f7f2199f32@mail.gmail.com> References: <8794dff51002191853j667b9658tadf97419c5e7fa8b@mail.gmail.com> <8675DF39-2B4E-4150-80B7-A64B24B6C6B2@jabberwocky.com> <8794dff51002241233o29aad858idf8c39f7f2199f32@mail.gmail.com> Message-ID: <4B85B688.9010504@grant-olson.net> On 2/24/2010 3:33 PM, Zy Zylek wrote: > > RE: "Group Key" again: > While it's possible to use a shared group key, which allows for everyone > to encrypt/decrypt with that group keypair, is it possible to increase > the security (at least a little) - to prevent just anyone from getting > the group keypair - by requiring one specific user (or one user's > individual keypair) to serve as a means of authentication for permitting > a new person to receive that shared group keypair? > Ultimately, that's a trust issue. You have to trust people to behave properly. If they can access the key, or the unencrypted files, they can copy them somewhere. Some sort of token authentication, like a smart card, or (not for gpg) a SecurID card, makes it harder for people to cheat and hand their password out. > > I'm not sure I understand your question. In the literal sense, yes. This > might help a little: > > User A is group admin, she has file 1, she encrypts it for the group. > Any user with access to group-encrypted files can decrypt file 1. > > User B has file 2, she encrypts it for the group. > Any user with access to group-encrypted files can decrypt file 2. > > User C has file 3, she encrypts it for the group. > Any user with access to group-encrypted files can decrypt file 3. > > User A removes User B from the group, "B" can no longer encrypt/decrypt. > User B has no access to group-encrypted files (old: 1, 2, 3, or new: 4+). > > User A adds User D to the group, "D" has access to group-encrypted files. > User D has access to group-encrypted files (old: 1, 2, 3, or new: 4+). > > User D has file 4, she encrypts it for the group. > Any user with access to group-encrypted files can decrypt file 4. > How are users exchanging files? It almost sounds like what you really want is some sort of secured file share that you can control via an Access Control List. Something like Samba, nfs, scp, web-dav... Yes, users could copy the unencrypted contents somewhere, but they could do the same with gpg. If they need to use the files offline and on the road, and that's why you need encryption, you could store them on an encrypted filesystem locally with something like TrueCrypt or LUKS or BitLocker. When you kill access to the share, they can't get any more updates. Sure, they might be able to grab the old data and copy it somewhere, if you can't revoke their access to (for example) a laptop, but they could have already done that before you killed the access. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From kgo at grant-olson.net Thu Feb 25 01:44:19 2010 From: kgo at grant-olson.net (Grant Olson) Date: Wed, 24 Feb 2010 19:44:19 -0500 Subject: key question In-Reply-To: <4B85A4DB.9030108@googlemail.com> References: <4B85A4DB.9030108@googlemail.com> Message-ID: <4B85C7E3.9000904@grant-olson.net> On 2/24/2010 5:14 PM, Tobias Holz wrote: > Hey Folks, > i succesfully installed gnupg on my Win7 machine. I want to use it > with Thunderbird to encrypt personal eMails. > Now I've got some questions: > 1) What does happen if I lose my private key? Can I burn it to a CD/DVD? You won't be able to read anything encrypted with that key. You'll still be able to verify signatures created with the key, if you can get the public key from a keyserver or something. If it's been stolen, someone else could possibly access your encrypted info and/or impersonate you. If possible, you'll want to revoke it with a revocation certificate: http://www.gnupg.org/gph/en/manual.html#REVOCATION (That whole manual is pretty good. You might want to read the whole thing.) You can back it up properly by exporting the key and burning the file to a cd. "gpg --export-secret-key > key_backup_file" You could also backup your whole keyring, including all the public keys, trust levels, local signatures, etc. That's under "Documents and Settings\user\Application Data\gnupg" on windows XP. Not sure if that's the same on Windows 7. > 2) Where can I find the key, I just got the passphrase? > See above. The actual file is secring.gpg. > I generated the Keys with OpenPGP-Plugin for Thunderbird. I got the > public key (something_stands_here.asc) and encryption works fine :) > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From jesus.diaz.vico at gmail.com Thu Feb 25 01:45:43 2010 From: jesus.diaz.vico at gmail.com (=?ISO-8859-1?Q?Jes=FAs_D=EDaz_Vico?=) Date: Thu, 25 Feb 2010 01:45:43 +0100 Subject: key question In-Reply-To: <4B85A4DB.9030108@googlemail.com> References: <4B85A4DB.9030108@googlemail.com> Message-ID: <4B85C837.90508@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tobias Holz escribi?: > Hey Folks, > i succesfully installed gnupg on my Win7 machine. I want to use it > with Thunderbird to encrypt personal eMails. I'm not a Windows user, so I'll explain what I'll do in Linux, but I suppose it'll be pretty similar and you shouldn't have much problems... If I'm mistaken in something, I'm sure somebody will correct me. > Now I've got some questions: > 1) What does happen if I lose my private key? Can I burn it to a CD/DVD? If you lose your private key and you don't have a backup, then it means you won't be able to decipher messages ciphered with your public key or sign messages (at least not with the keypair you lost). You can burn it to a CD/DVD or copy it to any other storage device if you previously export it to a file, but, and quoting from gpg man page, that might not be a good idea (in security terms): --export-secret-keys --export-secret-subkeys Same as --export, but exports the secret keys instead. This is normally not very useful and a security risk. So, if you are going to copy it somewhere, first make sure that the CD/DVD or whatever will be safe (in a degree depending on your needs, of course). > 2) Where can I find the key, I just got the passphrase? You can list all the keys you have in your system with gpg --list-keys option, once you've identified the key you want to export, you can export it with gpg --output --export (for the public key) and gpg --ouput --export-private-keys for the private key. With the OpenPGP plugin for Thunderbird, if you go to "OpenPGP > Key Management", you can see the keys OpenPGP is aware of, and you can export any one of them right clicking on it, and you can import a new key from a file in "File > Import Keys from File". > I generated the Keys with OpenPGP-Plugin for Thunderbird. I got the > public key (something_stands_here.asc) and encryption works fine :) > > Hopefully looking forward > Tobias > Hope that helps. Jes?s. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuFyBwACgkQqnfodDuqSEJWiQCfYTqr7SmqgRjUjqb1tZkI0Kab 2HIAoMjXEU37osjhaMc/SIGgwKtIahHV =dBlM -----END PGP SIGNATURE----- From jmoore3rd at bellsouth.net Thu Feb 25 01:33:31 2010 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Wed, 24 Feb 2010 19:33:31 -0500 Subject: key question In-Reply-To: <4B85A4DB.9030108@googlemail.com> References: <4B85A4DB.9030108@googlemail.com> Message-ID: <4B85C55B.2070005@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Tobias Holz wrote: > Hey Folks, > i succesfully installed gnupg on my Win7 machine. I want to use it > with Thunderbird to encrypt personal eMails. > Now I've got some questions: > 1) What does happen if I lose my private key? Can I burn it to a CD/DVD? If You actually 'lose' Your Private Key [i.e. Secret/Private half of the Keypair] or lose and/or Forget Your Passphrase You are FUBAR. This is why the Enigmail Manual & Quick Start Guide both _strongly_ encourage the generation of a Revocation Certificate [actually just a Special Signature File] which You should then store somewhere away from Your Keyrings. Enigmail has a 'Wizard' for this. :) > 2) Where can I find the key, I just got the passphrase? Under 'OpenPGP' on the toolbar at the top of Thunderbird You will find an item in the Menu labeled 'Key Management' which will graphically display Your Keyring(s). [Hint: the default setting displays nothing until a Key ID or Email Address is entered into the Search Box /unless/ You have checked the box 'Display All Keys'. Where are the actual Keyring(s) in Win 7? The crypto-geek answer is "under %AppData% ? Roaming Directory/Folder _or_ C:\Program Files\GnuPG assuming You accepted the Defaults when installing GnuPG. :-\ You can also use WinSearch and enter: secring.gpg or pubring.gpg. This is the Secret Keyring and Public Keyring respectively. If You choose to burn either of these [or both] to a Disk or store them on removable media then I also suggest You include the File trustdb.gpg since this File contains Your Assigned & Calculated Key Trust values. It is located in the same Directory/Folder as the other 2 Files. > I generated the Keys with OpenPGP-Plugin for Thunderbird. I got the > public key (something_stands_here.asc) and encryption works fine :) At the risk of being called a heretic by My fellow Members of the Enigmail Development Team I am also going to recommend a companion GPG Frontend to You for use on Windows: GPGshell [http://www.jumaros.de/rsoft/index.html] is an excellent tool for Key Management [manipulation] that offers many 'clickable' options not available within the Enigmail Key Manager as well as greatly simplifying Command Line usage. [Another Hint: in order to fully enjoy & exploit all of GnuPG's many features some Command Line familiarity is gonna be necessary] Going way out on a limb I am going to assume that You are as yet unaware of the gpg.conf File and it's usefulness. Please do not hesitate to Ask more Questions within this Forum/List as well as accept Google as Your Friend. As Questions specific to Enigmail begin to develop I heartily suggest You also Join the Enigmail Mailing List as well. [https://www.mozdev.org/mailman/listinfo/enigmail] ;) HTH more than it confuses. :) JOHN ;) Timestamp: Wednesday 24 Feb 2010, 19:32 --500 (Eastern Standard Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Personal Web Page: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJLhcVYAAoJEBCGy9eAtCsPQ3oIAIAmFY/3blwse4tNLEV0cNwH G3Z0KnbX2t9XoHqUt+AoLFQDXxvFHivsIAu+7p4z7D4Dy5Zw7ya2+Stdmmf147Sy qmPg647cNT3N2YB/VqW/aq36a2cD82mZr8ltoVa+3VD2s1fwe6o2xcNiP1JbdxZW Gp4/x1lzOALwkD3BCKjuv3SIG8Pyh0AZNKJBrkP6q318WjWOv4J6AAwKD3bRLxSr I3CNTooN0GDVoF7nyc/pETsxQbWSDwy348cwvvpe5im5Y2UYTdqAgqhVbFl9DaRL iC9KrFF2bN158Ot7IInUO2cTU9CUQISuE0HUt5pFzqsFOcFHtqLiBzXoyC1+c3s= =m/vO -----END PGP SIGNATURE----- From John at Mozilla-Enigmail.org Thu Feb 25 01:17:36 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Wed, 24 Feb 2010 18:17:36 -0600 Subject: key question In-Reply-To: <4B85A4DB.9030108@googlemail.com> References: <4B85A4DB.9030108@googlemail.com> Message-ID: <4B85C1A0.3050403@Mozilla-Enigmail.org> Tobias Holz wrote: > Hey Folks, > i successfully installed gnupg on my Win7 machine. I want to use it > with Thunderbird to encrypt personal eMails. > Now I've got some questions: > 1) What does happen if I lose my private key? Can I burn it to a CD/DVD? If you lose your secret key or forget your passphrase and cannot recover them, you are toast. There is no way to recover either except from a backup copy. CD/DVD is one method. You may also want to take a look at paperkey, . While you are saving your secret key, generate a revocation certificate and save it with the key rings on the CD and/or print it out with the paperkey copy. You'll need it if you ever lose your secret key or forget your passphrase, and cannot recover either of them. > 2) Where can I find the key, I just got the passphrase? XP & earlier: C:\Documents and Settings\\Application Data\GnuPG\ Vista & Windows 7: C:\Users\\AppData\Roaming\GnuPG\ The file you need to save is secring.gpg. The files are small enough, you should also save a copy of pubring.gpg and trustdb.gpg. > I generated the Keys with OpenPGP-Plugin for Thunderbird. I got the > public key (something_stands_here.asc) and encryption works fine :) Not heard of it that extension. Lots of folks use the Enigmail extension. "something_stands_here' is known as the key ID. There is no benefit to keeping it secret. It is also a good idea to send your key to the keyservers. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at 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" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: From cathy.smith at pnl.gov Thu Feb 25 03:46:33 2010 From: cathy.smith at pnl.gov (Smith, Cathy) Date: Wed, 24 Feb 2010 18:46:33 -0800 Subject: Migrating from PGP to GPG question In-Reply-To: <4A009880.8090807@christiantena.net> References: <4A009880.8090807@christiantena.net> Message-ID: <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> Folks We are starting to migrate from OpenPGP to GnuPG. One of the batch jobs I have to convert uses: pgp +force This is supposed to assume a "yes" to any interactive questions. I wasn't clear after reading the man pages about the gpg --batch option. Can someone tell me if the --batch and the --yes options are mutually exclusive? Thanks. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov From dshaw at jabberwocky.com Thu Feb 25 04:57:16 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 24 Feb 2010 22:57:16 -0500 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> Message-ID: <545B0962-0F86-4AC4-8CDD-D531C17BBEA3@jabberwocky.com> On Feb 24, 2010, at 9:46 PM, Smith, Cathy wrote: > Folks > > We are starting to migrate from OpenPGP to GnuPG. One of the batch jobs I have to convert uses: > pgp +force > > This is supposed to assume a "yes" to any interactive questions. I wasn't clear after reading the man pages about the gpg --batch option. Can someone tell me if the --batch and the --yes options are mutually exclusive? They are not mutually exclusive. If you want both batch operation, and to to answer 'yes' to questions, you should give both --batch and --yes. David From jrollins at finestructure.net Thu Feb 25 05:10:58 2010 From: jrollins at finestructure.net (Jameson Rollins) Date: Wed, 24 Feb 2010 23:10:58 -0500 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> Message-ID: <878wai0xbh.fsf@servo.finestructure.net> On Wed, 24 Feb 2010 18:46:33 -0800, "Smith, Cathy" wrote: > We are starting to migrate from OpenPGP to GnuPG. Just for clarification, GnuPG is software tool that is actually an implementation of the OpenPGP specification [0]. OpenPGP is not actually a piece of software itself, nor is GnuPG a specification. jamie. [0] http://tools.ietf.org/html/rfc4880 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From cathy.smith at pnl.gov Thu Feb 25 05:33:14 2010 From: cathy.smith at pnl.gov (Smith, Cathy) Date: Wed, 24 Feb 2010 20:33:14 -0800 Subject: Migrating from PGP to GPG question In-Reply-To: <878wai0xbh.fsf@servo.finestructure.net> References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> <878wai0xbh.fsf@servo.finestructure.net> Message-ID: <70086D201BD484439914C36F5C8BF16101A1B76B4877@EMAIL04.pnl.gov> We are migrating from OpenPGP which is a freeware version of PGP. Sorry for the confusion. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: Jameson Rollins [mailto:jrollins at finestructure.net] Sent: Wednesday, February 24, 2010 8:11 PM To: Smith, Cathy; gnupg-users at gnupg.org Subject: Re: Migrating from PGP to GPG question On Wed, 24 Feb 2010 18:46:33 -0800, "Smith, Cathy" wrote: > We are starting to migrate from OpenPGP to GnuPG. Just for clarification, GnuPG is software tool that is actually an implementation of the OpenPGP specification [0]. O From f.schwind at chili-radiology.com Thu Feb 25 12:35:17 2010 From: f.schwind at chili-radiology.com (Florian Schwind) Date: Thu, 25 Feb 2010 12:35:17 +0100 Subject: How to decrypt signatures with gpgme? Message-ID: <4B866075.3050109@chili-radiology.com> Hello List, when I create a signature with "gpg --sign", I'm able to use "gpg --decrypt" to get the plaintext from the signature. When I'm try to to this using gpgme resp. gpgme_op_decrypt (gpgme_ctx_t ctx, gpgme_data_t cipher, gpgme_data_t plain) I'm getting a GPG_ERR_NO_DATA error if cipher does not contain any data to decrypt. So is there a way to get the plaintext from the signature using gpgme? Thanks Florian From expires2010 at ymail.com Thu Feb 25 15:24:53 2010 From: expires2010 at ymail.com (MFPA) Date: Thu, 25 Feb 2010 14:24:53 +0000 Subject: key question In-Reply-To: <4B85F433.1040405@Mozilla-Enigmail.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> Message-ID: <1912204946.20100225142453@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 25 February 2010 at 3:53:23 AM, in , John Clizbe wrote: > MFPA wrote: >> Hi John >> On Thursday 25 February 2010 at 12:17:36 AM, you >> wrote: >>> It is also a good idea to send your key to the >>> keyservers. >> But is, of course, a matter of personal choice. > Whatever. Everything in life is a matter of personal > choice. > Was there some point you wished to make? My point was that not everybody wishes/chooses to send their keys to the keyservers. Some people hate the idea and get *very* upset if their key does end up on the servers. - -- Best regards MFPA mailto:expires2010 at ymail.com The truth is rarely pure and never simple -----BEGIN PGP SIGNATURE----- iQCVAwUBS4aIWqipC46tDG5pAQotagQAnjEJcfJttj58GG7oEFrrPhto82gkfcMu ewlVHvcak6tkRVz35WCyVOXQK3cwvF0Zp03tNUM8Xo3vJ2G0IktNy4roCQqCHTwA GuPOb0ioZqh3Wi615xZ4PVAV2iBElRTJtETuYD1CyhlN2VhWsUHsNZ1Zo5JOcwmO cRhbZw+Sm8s= =naYo -----END PGP SIGNATURE----- From expires2010 at ymail.com Thu Feb 25 15:36:14 2010 From: expires2010 at ymail.com (MFPA) Date: Thu, 25 Feb 2010 14:36:14 +0000 Subject: No subject Message-ID: <1131022477.20100225143614@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi - -- Best regards MFPA mailto:expires2010 at ymail.com Ultimate consistency lies in being consistently inconsistent -----BEGIN PGP SIGNATURE----- iQCVAwUBS4aK6aipC46tDG5pAQoWfgP+Kaflz5+32QsDfOJBV+tm33kXb8oDQzMo 5NJUH40YjCcrxbPU3rDiIb9Fznix3BSMyPysoX/+mHwwk10IdpsTdCv1bMAj31dZ Udpy9FZ0MI0HtoefXu6Q1JnQ2mplEY7slfVRjW/7A80NNqCHXjzblyx1CiRbctoH H4lA5mMEbvQ= =95Dh -----END PGP SIGNATURE----- From jrollins at finestructure.net Thu Feb 25 16:58:02 2010 From: jrollins at finestructure.net (Jameson Rollins) Date: Thu, 25 Feb 2010 10:58:02 -0500 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B76B4877@EMAIL04.pnl.gov> References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> <878wai0xbh.fsf@servo.finestructure.net> <70086D201BD484439914C36F5C8BF16101A1B76B4877@EMAIL04.pnl.gov> Message-ID: <873a0p1f5h.fsf@servo.finestructure.net> On Wed, 24 Feb 2010 20:33:14 -0800, "Smith, Cathy" wrote: > We are migrating from OpenPGP which is a freeware version of PGP. Sorry for the confusion. I'm not familiar with OpenPGP, the software. I'm familiar with the PGP Corporation's implementation (which I think is just called "PGP"), but not an implementation called "OpenPGP". Having trouble finding any references to anything other than OpenPGP the spec as well. Would you mind passing on a link? Thanks. jamie. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From John at Mozilla-Enigmail.org Thu Feb 25 19:04:00 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Thu, 25 Feb 2010 12:04:00 -0600 Subject: key question In-Reply-To: <1912204946.20100225142453@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> Message-ID: <4B86BB90.70707@Mozilla-Enigmail.org> MFPA wrote: > On Thursday 25 February 2010 at 3:53:23 AM, in > , John Clizbe wrote: >> MFPA wrote: >>> Hi John > >>> On Thursday 25 February 2010 at 12:17:36 AM, you wrote: > >>>> It is also a good idea to send your key to the keyservers. > >>> But is, of course, a matter of personal choice. > >> Whatever. Everything in life is a matter of personal choice. > >> Was there some point you wished to make? > > My point was that not everybody wishes/chooses to send their keys to > the keyservers. Then you need not send your key to the keyserver network. Pretty simple personal choice, huh? Don't want to? Don't do it. Whether one chooses to send his key to the keyservers or not, it is still a good idea and in the interest of the OpenPGP community to utilize the keyservers. *Public* key encryption is fostered by the *public* dissemination of keys and the keyservers are, IMO, the best mechanism for that. I stand by my earlier statement. > Some people hate the idea and get *very* upset if their key does end > up on the servers. Ohhhhhhhhhhhhhhh... I see. Do they take their ball and go home? Do they jump up and down? Stomp their feet? Hold their breath until they turn blue? Do they forward private email to a public list? Such key sequestration is a minority viewpoint and I doubt even a good number of folks on a fully encrypted forum such as PGPNet would agree with you and would instead support keyserver use. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at 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" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Feb 25 19:36:57 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Feb 2010 19:36:57 +0100 Subject: How to decrypt signatures with gpgme? In-Reply-To: <4B866075.3050109@chili-radiology.com> (Florian Schwind's message of "Thu, 25 Feb 2010 12:35:17 +0100") References: <4B866075.3050109@chili-radiology.com> Message-ID: <87k4u16u2e.fsf@vigenere.g10code.de> On Thu, 25 Feb 2010 12:35, f.schwind at chili-radiology.com said: > when I create a signature with "gpg --sign", I'm able to use "gpg > --decrypt" to get the plaintext from the signature. You might want to use: gpg --verify --output PAINTEXT.TXT SIGNED.GPG > So is there a way to get the plaintext from the signature using gpgme? What about this: - Function: gpgme_error_t gpgme_op_verify (gpgme_ctx_t CTX, gpgme_data_t SIG, gpgme_data_t SIGNED_TEXT, gpgme_data_t PLAIN) The function `gpgme_op_verify' verifies that the signature in the data object SIG is a valid signature. If SIG is a detached signature, then the signed text should be provided in SIGNED_TEXT and PLAIN should be a null pointer. Otherwise, if SIG is a normal (or cleartext) signature, SIGNED_TEXT should be a null pointer and PLAIN should be a writable data object that will contain the plaintext after successful verification. [...] Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From carlos.chavez.p at gmail.com Thu Feb 25 17:59:38 2010 From: carlos.chavez.p at gmail.com (Carlos Chavez) Date: Thu, 25 Feb 2010 10:59:38 -0600 Subject: How to sign an email in PHP? In-Reply-To: <4B858B86.1000502@sixdemonbag.org> References: <916020b41002231134o32de67a1g6d4ac622a1032504@mail.gmail.com> <4B84637E.1070600@grant-olson.net> <916020b41002231906j78a750e9we211faf93690507b@mail.gmail.com> <4B849D12.1070609@grant-olson.net> <20100224111803.0eb14527@scorpio.seibercom.net> <4B858B86.1000502@sixdemonbag.org> Message-ID: <916020b41002250859y43d68123mda5644d26a55ad38@mail.gmail.com> On Wed, Feb 24, 2010 at 2:26 PM, Robert J. Hansen wrote: > On 2/24/10 11:18 AM, Jerry wrote: > > Outlook Express is depreciated. > > Outlook Express is deprecated, and many people here throw deprecations > against it -- but Outlook Express is still one of the most common MUAs > in existence, and for that reason alone the PGP/MIME interoperability > problem should be taken seriously. > > I finally got it to work! Thanks to Grant for pointing me to the RFC. I can now sign the message and successfully verify the signature when it arrives. So far Evolution, Thunderbird and Outlook work without a hitch. I have to write the whole email manually in PHP because the PEAR libraries for Mime do not quite get the headers right but I do not see that as a problem. My next test is to sign a message that includes an attachment which is going to be a bit more difficult. -- -- Carlos Chavez -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Thu Feb 25 20:01:48 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 25 Feb 2010 14:01:48 -0500 Subject: How to sign an email in PHP? In-Reply-To: <916020b41002250859y43d68123mda5644d26a55ad38@mail.gmail.com> References: <916020b41002231134o32de67a1g6d4ac622a1032504@mail.gmail.com> <4B84637E.1070600@grant-olson.net> <916020b41002231906j78a750e9we211faf93690507b@mail.gmail.com> <4B849D12.1070609@grant-olson.net> <20100224111803.0eb14527@scorpio.seibercom.net> <4B858B86.1000502@sixdemonbag.org> <916020b41002250859y43d68123mda5644d26a55ad38@mail.gmail.com> Message-ID: <4B86C91C.9080908@fifthhorseman.net> On 02/25/2010 11:59 AM, Carlos Chavez wrote: > I have to write the whole email manually in PHP because the PEAR libraries for > Mime do not quite get the headers right Please file bugs against the PEAR libraries in question so that they can be fixed. Thanks! Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From cathy.smith at pnl.gov Thu Feb 25 20:05:09 2010 From: cathy.smith at pnl.gov (Smith, Cathy) Date: Thu, 25 Feb 2010 11:05:09 -0800 Subject: Migrating from PGP to GPG question In-Reply-To: <878wai0xbh.fsf@servo.finestructure.net> References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> <878wai0xbh.fsf@servo.finestructure.net> Message-ID: <70086D201BD484439914C36F5C8BF16101A1B795F1B1@EMAIL04.pnl.gov> Here is the information for the freeware version of PGP. http://www.pgpi.org/ Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: Jameson Rollins [mailto:jrollins at finestructure.net] Sent: Wednesday, February 24, 2010 8:11 PM To: Smith, Cathy; gnupg-users at gnupg.org Subject: Re: Migrating from PGP to GPG question On Wed, 24 Feb 2010 18:46:33 -0800, "Smith, Cathy" wrote: > We are starting to migrate from OpenPGP to GnuPG. Just for clarification, GnuPG is software tool that is actually an implementation of the OpenPGP specification [0]. O From faramir.cl at gmail.com Thu Feb 25 21:15:35 2010 From: faramir.cl at gmail.com (Faramir) Date: Thu, 25 Feb 2010 17:15:35 -0300 Subject: Shamir's Secret Sharing Scheme integration? In-Reply-To: <82mxz1acwu.fsf@mid.bfk.de> References: <4B8137B4.5030909@verizon.net> <4B823EEC.1090003@gmx.net> <82mxz1acwu.fsf@mid.bfk.de> Message-ID: <4B86DA67.2010508@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Florian Weimer escribi?: > * Stefan Xenon: > >> I don't know any integration in GnuPG but instead the following open >> source implementatio may worth a try: http://point-at-infinity.org/ssss/ > > IIRC, this particular software does not implement Shamir's scheme. Are you sure? The title of the page is "Shamir's Secret Sharing Scheme" Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLhtpnAAoJEMV4f6PvczxAxCcIAJppkdHb5yKaghVmkXn/kJ/L uu053jF7GRWag5idf+KESJbPomZxN5fQo+8vkEsN4gJN4l9uvPlJREALGGZdZham F6ZSadcknhEhvrlqsZbkQah19A3RoBlOtz40iypyFCZKpcSDLXcbNZ0C0XPbNfzD DJq6Jcg/snkNK3EYXkgzubRLk0+ntQmKYG7mOYKjPL/rahP6bvtXi9TbrhQeXMOW 6QdCQ7nWR91/Pt9f04n1/E6IThaCp/3iGEpwN1NM6wa6FrMjppP7+6v7nUnBwFCW FM/FJeI86p56QRLB8PwnYhw1ZkGIXETJndMkxZttSQRNJHtRHpfz2JJYUKvP8yc= =jFla -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Thu Feb 25 21:23:30 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 25 Feb 2010 15:23:30 -0500 Subject: key question In-Reply-To: <1912204946.20100225142453@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> Message-ID: <4B86DC42.3070602@sixdemonbag.org> On 2/25/10 9:24 AM, MFPA wrote: > Some people hate the idea and get *very* upset if their key does end > up on the servers. What you're advocating here is "DRM on the honor system." Don't copy the key, don't distribute the key, don't upload the key, don't do anything with the key, without the explicit permission of the key owner. Me, I consider DRM on the honor system to be the exact same as any other kind of DRM -- something to be overcome and then ignored. If someone asks me nicely, "please do not upload this key," I will probably say yes. But it is a *huge* leap to go from there to "do not upload keys without the owners' permission." From cathy.smith at pnl.gov Thu Feb 25 23:17:57 2010 From: cathy.smith at pnl.gov (Smith, Cathy) Date: Thu, 25 Feb 2010 14:17:57 -0800 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> Message-ID: <70086D201BD484439914C36F5C8BF16101A1B795F253@EMAIL04.pnl.gov> Folks Another question about this migration. Is it possible to do a mass import of a single user's keyring or do I have to do it for each individual key. I've not been able to find anything so far about anything that addresses this. Thanks. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Smith, Cathy Sent: Wednesday, February 24, 2010 6:47 PM To: gnupg-users at gnupg.org Subject: Migrating from PGP to GPG question Folks We are starting to migrate from OpenPGP to GnuPG. One of the batch jobs I have to convert uses: pgp +force This is supposed to assume a "yes" to any interactive questions. I wasn't clear after reading the man pages about the gpg --batch option. Can someone tell me if the --batch and the --yes options are mutually exclusive? Thanks. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From dshaw at jabberwocky.com Thu Feb 25 23:46:05 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 25 Feb 2010 17:46:05 -0500 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B795F253@EMAIL04.pnl.gov> References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> <70086D201BD484439914C36F5C8BF16101A1B795F253@EMAIL04.pnl.gov> Message-ID: On Feb 25, 2010, at 5:17 PM, Smith, Cathy wrote: > Folks > > Another question about this migration. Is it possible to do a mass import of a single user's keyring or do I have to do it for each individual key. I've not been able to find anything so far about anything that addresses this. Yes, you can do a mass import of a keyring. This is not always true, but is true for most keyrings, including those from PGP and PGPi (which you indicated you were using). David From free10pro at gmail.com Thu Feb 25 23:30:00 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Thu, 25 Feb 2010 14:30:00 -0800 Subject: key question In-Reply-To: <1912204946.20100225142453@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> Message-ID: <1267137001.10876.85.camel@localhost> On Thu, 2010-02-25 at 14:24 +0000, MFPA wrote: > My point was that not everybody wishes/chooses to send their keys to > the keyservers. > > Some people hate the idea and get *very* upset if their key does end > up on the servers. In my case, the reason that I uploaded my keys to public keyservers was to make it possible for anyone who wanted to privately communicate with me to do so. Even if I didn't know them. If the reason for keeping the public key to yourself is that you don't want anyone, except for a selected few, to know your "secret" e-mail address, then create two e-mail addresses. One will only be shared with people you know intimately, and the other will be for the public. I never understood how anyone would want to use PGP for e-mail privacy, and, subsequently, keep the public key a secret! I don't see any reason why a person would keep his key off the public keyservers, short of preventing spam. And you know what, he would get spammed anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 665 bytes Desc: This is a digitally signed message part URL: From free10pro at gmail.com Thu Feb 25 23:34:58 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Thu, 25 Feb 2010 14:34:58 -0800 Subject: key question In-Reply-To: <4B86DC42.3070602@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> Message-ID: <1267137298.10876.87.camel@localhost> On Thu, 2010-02-25 at 15:23 -0500, Robert J. Hansen wrote: > On 2/25/10 9:24 AM, MFPA wrote: > > Some people hate the idea and get *very* upset if their key does end > > up on the servers. > > What you're advocating here is "DRM on the honor system." Don't copy > the key, don't distribute the key, don't upload the key, don't do > anything with the key, without the explicit permission of the key owner. > > Me, I consider DRM on the honor system to be the exact same as any other > kind of DRM -- something to be overcome and then ignored. > > If someone asks me nicely, "please do not upload this key," I will > probably say yes. But it is a *huge* leap to go from there to "do not > upload keys without the owners' permission." Friend don't let friends -- PGP Key ID: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 665 bytes Desc: This is a digitally signed message part URL: From laurent.jumet at skynet.be Thu Feb 25 23:50:32 2010 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Thu, 25 Feb 2010 23:50:32 +0100 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B795F253@EMAIL04.pnl.gov> Message-ID: Hello Smith, ! "Smith, Cathy" wrote: > Another question about this migration. Is it possible to do a mass import > of a single user's keyring or do I have to do it for each individual key. > I've not been able to find anything so far about anything that addresses > this. I would try gpg pubring.pgp as GPG assumes usually the most relevant action. Adding keyring pubring.pgp in gpg.conf adds current file to list of keyrings. And gpg --import pubring.pgp should import the whole keyring too. -- Laurent Jumet KeyID: 0xCFAF704C From free10pro at gmail.com Thu Feb 25 23:37:37 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Thu, 25 Feb 2010 14:37:37 -0800 Subject: key question In-Reply-To: <4B86DC42.3070602@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> Message-ID: <1267137457.10876.88.camel@localhost> On Thu, 2010-02-25 at 15:23 -0500, Robert J. Hansen wrote: > On 2/25/10 9:24 AM, MFPA wrote: > > Some people hate the idea and get *very* upset if their key does end > > up on the servers. > > What you're advocating here is "DRM on the honor system." Don't copy > the key, don't distribute the key, don't upload the key, don't do > anything with the key, without the explicit permission of the key owner. > > Me, I consider DRM on the honor system to be the exact same as any other > kind of DRM -- something to be overcome and then ignored. > > If someone asks me nicely, "please do not upload this key," I will > probably say yes. But it is a *huge* leap to go from there to "do not > upload keys without the owners' permission." Friends don't let friends share PGP keys. ;-) -- PGP Key ID: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 From free10pro at gmail.com Thu Feb 25 23:03:11 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Thu, 25 Feb 2010 14:03:11 -0800 Subject: key question In-Reply-To: <1267094298.10876.56.camel@localhost> References: <4B85A4DB.9030108@googlemail.com> <1267094298.10876.56.camel@localhost> Message-ID: <1267135391.10876.64.camel@localhost> My error. I didn't CC the following message to the mailing list. On Thu, 2010-02-25 at 02:38 -0800, Paul Richard Ramer wrote: > I won't add to the other good replies, except for this. Concerning > the > revocation certificate that you would be behooved to create, you > should > take care to protect it. If an enemy (and we hope you don't have > any :-)) got a hold of your revocation certificate, he could revoke > your > key by uploading the certificate to public keyservers. > > Even though your copy of your private and public keys wouldn't be > revoked, all of the copies of your public key on the public keyservers > would be revoked. This, of course, would be a major impediment to > people wanting to privately communicate with you. > > Other than that, feel free to ask your questions on this mailing list. > We are here to help. > > Paul > -- > Privacy is good. Use PGP. > > +---------------------------------------------------------------------+ > | PGP Key ID: 0x3DB6D884 | > | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | > +---------------------------------------------------------------------+ -- Privacy is good. Use PGP. +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 665 bytes Desc: This is a digitally signed message part URL: From yawar.amin at gmail.com Fri Feb 26 02:29:30 2010 From: yawar.amin at gmail.com (Yawar Amin) Date: Thu, 25 Feb 2010 20:29:30 -0500 Subject: key question In-Reply-To: <4B86BB90.70707@Mozilla-Enigmail.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> Message-ID: <4B8723FA.3030809@gmail.com> On 2/25/10 1:04 PM, John Clizbe said: > MFPA wrote: > >> On Thursday 25 February 2010 at 3:53:23 AM, in >> , John Clizbe wrote: >> >>> MFPA wrote: >>> >>>> Hi John >>>> >>>> On Thursday 25 February 2010 at 12:17:36 AM, you wrote: >>>> >>>>> It is also a good idea to send your key to the keyservers. >>>>> >>>> But is, of course, a matter of personal choice. >>>> >>> Whatever. Everything in life is a matter of personal choice. >>> >>> Was there some point you wished to make? >>> >> My point was that not everybody wishes/chooses to send their keys to >> the keyservers. >> > > Then you need not send your key to the keyserver network. Pretty simple personal > choice, huh? Don't want to? Don't do it. > > Whether one chooses to send his key to the keyservers or not, it is still a good > idea and in the interest of the OpenPGP community to utilize the keyservers. > *Public* key encryption is fostered by the *public* dissemination of keys and > the keyservers are, IMO, the best mechanism for that. I stand by my earlier > I interpret that word, public, differently. To me just because a key _can_ be made public doesn't mean it automatically _should_. > statement. > > >> Some people hate the idea and get *very* upset if their key does end >> up on the servers. >> > > Ohhhhhhhhhhhhhhh... I see. Do they take their ball and go home? Do they jump up > and down? Stomp their feet? Hold their breath until they turn blue? Do they > forward private email to a public list? > They may have reason--by looking at signatures on a public keyserver, anyone can figure out which people you communicate with securely. How would you like the idea of governments worldwide starting to keep tabs on you if one of the people who've signed your key turns out to be a criminal, a terror suspect, or a child porn collector? Uploading a signed public key to the 'net is a sure way of taking away people's freedom to keep their associations private. They may choose to give that up for themselves, but you shouldn't slam them for keeping their options open. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Feb 26 04:24:29 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 25 Feb 2010 22:24:29 -0500 Subject: key question In-Reply-To: <4B8723FA.3030809@gmail.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <4B8723FA.3030809@gmail.com> Message-ID: <4B873EED.2090008@sixdemonbag.org> On 2/25/10 8:29 PM, Yawar Amin wrote: > I interpret that word, public, differently. To me just because a key > _can_ be made public doesn't mean it automatically _should_. What in life is automatic, besides death and taxes? We are not talking about automatic here. We are talking instead about what is reasonable and in accordance with the general expectations of the community. I've not heard any organized outcry for "DRM on the honor system", and I've not heard any good arguments for it. I've heard a loosely organized outcry for sharing public keys widely, and good arguments for it. Based on this, I'm going to follow the community practice of sharing keys widely, unless there are compelling reasons to do otherwise. I suspect most users are in the same boat. > They may have reason--by looking at signatures on a public keyserver, > anyone can figure out which people you communicate with securely. I invite you to look at my key and figure out with whom I communicate securely. Looking over the key I use now and the keys I've used in the past, I don't see any signatures there from people I've traded more than a handful of secured emails with. You might think the signatures on 0xFEAF8109 are indicative of something -- but really all that it's indicative of is that I attended the keysigning party at OSCON 2006. > How would you like the idea of governments worldwide starting to > keep tabs on you if one of the people who've signed your key turns > out to be a criminal, a terror suspect, or a child porn collector? You *must* be kidding. Listen, if there's some sociopath who likes raping eleven year olds on camera, and my name happens to be in his address book, or he happened to sign my key, or my name is *in any way* connected with his, then yes, I like the idea of my government coming around to ask me, "do you know anything about this?" When it comes to hideous crimes being perpetrated against children, I kind of support the idea of law-enforcement officers doing their jobs. Sure, sure, there are a ton of other more questionable investigations they could be conducting -- but your examples here are *awful*. > Uploading a signed public key to the 'net is a sure way of taking > away people's freedom to keep their associations private. If you want to keep your association with someone private, give it a local (non-exportable) signature. Exportable signatures are meant for the case where the signer *wants* to attest to the world their association. From expires2010 at ymail.com Fri Feb 26 15:49:00 2010 From: expires2010 at ymail.com (MFPA) Date: Fri, 26 Feb 2010 14:49:00 +0000 Subject: key question In-Reply-To: <4B873EED.2090008@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <4B8723FA.3030809@gmail.com> <4B873EED.2090008@sixdemonbag.org> Message-ID: <1567563532.20100226144900@my_localhost> Hi Robert On Friday 26 February 2010 at 3:24:29 AM, you wrote: > Exportable signatures are meant for the case where the signer *wants* to > attest to the world their association. I thought signing somebody's key was just stating to the world that you believe the claimed identity of the person who controls that key at the time you are signing it - not an indication that you are in any way "associated." -- Best regards MFPA mailto:expires2010 at ymail.com War is a matter of vital importance to the State. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 269 bytes Desc: not available URL: From reynt0 at cs.albany.edu Fri Feb 26 16:32:44 2010 From: reynt0 at cs.albany.edu (reynt0) Date: Fri, 26 Feb 2010 10:32:44 -0500 (EST) Subject: Questions about "--group" for group encryptions. In-Reply-To: <8794dff51002241233o29aad858idf8c39f7f2199f32@mail.gmail.com> References: <8794dff51002191853j667b9658tadf97419c5e7fa8b@mail.gmail.com> <8675DF39-2B4E-4150-80B7-A64B24B6C6B2@jabberwocky.com> <8794dff51002241233o29aad858idf8c39f7f2199f32@mail.gmail.com> Message-ID: (responding to only the parts of ZZ's post which seem directed to my prior post) On Wed, 24 Feb 2010, Zy Zylek wrote: . . . > By "full many-to-many encryption/decryption functionality", > do you mean many people and many files? Basically yes (to that). I apologize for being too brief. By "many-to-many" I meant like a graph theory analysis, where "many" refers to people, and "many-to-many" means like a bunch of people each one of which knows a shared public-private keypair, used to encrypt or decrypt files to which each member of the "many" group has access. Ie with some single en/decrypt action using one single keypair anyone of many people can accomplish en/decryption to many other people. A mass "one-to-one" alternative would be each individual member of the group needing to know an individual public-private keypair for each other member of the group. Ie group en/decryption would be more like a mass of individual, one-to-one actions. Similar questions exist about file maintenaance. Would files be kept in some single location where each member of the group would freely deposit encrypted files and each member would freely access the files (a many-to-many way of doing file maintenance)? Or would each member of the group keep only files he/she had created and each other member have to know of each files' individual existence and location and access them there (a kind of one-to-one); or maybe each member of the group would have to send a copy of each encrypted file he/she creates to each other member of the group, so each could maintain a copy of every file (a kind of mass one-to-one file maintenance)? > By "minimum keyage", do you mean functionality with as few keys as possible? > If that, then not necessarily. If it is possible to collaborate the > advantages of having a different key per individual, and yet they all depend > on one group keypair (that only User A administrates (adds/removes > individuals' keys)) in order to encrypt/decrypt group files, then I do not > want minimum keyage (if that's what that means). I did mean as few keys as possible, thinking just of use for your project. But what you say, a "different key per individual" and "one group keypair", sounds maybe like the following? People can in general have however many keypairs they want (which is correct); and included among those keypairs would be a keypair that is issued by some administrator A and that is shared by everyone to whom admin A gives it, and that is to be used just for the group's files? Yes, that is a possibility. > . . . > Referencing the model you mentioned - that is using public key to encrypt > and private key to decrypt - it sounds like it might (or might not?) be > possible (or useful?) to have a separate group public key and a separate > group private key, yet to not have them actually function as a "pair" > (together), or are you asking something else? . . . A public-private key "pair" means they depend on each other to work together. That is the basic idea of having public and private keys in the first place. > . . . > RE: "...expandable/deflatable set of "ones" for mass one-to-one..." > > I don't understand that, sorry, could you paraphrase your "one" and "one" > type description that you provided? It was somewhat confusing. I apologize. I just meant the number of people in the group could increase or decrease. In this case, each single member joining the group has to be dealt with as an individual who has to be told the public key of each other member (to be able to encrypt files for those others to be able to decrypt); and has to be able to decrypt old files using his/her new-to-the-group private key, so all old files would have to be freshly encrypted to the new member's public key. And when any person leaves the group all other individual members have to be notified to stop using that person's keypair. > Does your explanation match my User A, B, C, D and file 1, 2, 3, 4 example? I can not answer that simply, so I'll hope my answers above help. > RE: "Alternatively, if what you want is one-to-many, you can see how that > could be arranged similar to either of the above." One-to-many could be something like one administrator creating all files and controlling access to them by many users, and maybe the admin using a single keypair of which all members know one part, which the members can use to decrypt the files; or maybe the admin using a different keypair for each individual group member. HTH. From expires2010 at ymail.com Fri Feb 26 16:53:27 2010 From: expires2010 at ymail.com (MFPA) Date: Fri, 26 Feb 2010 15:53:27 +0000 Subject: key question In-Reply-To: <4B86BB90.70707@Mozilla-Enigmail.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> Message-ID: <373551548.20100226155327@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 25 February 2010 at 6:04:00 PM, in , John Clizbe wrote: > Then you need not send your key to the keyserver > network. Pretty simple personal choice, huh? Don't want > to? Don't do it. Fair enough. > Whether one chooses to send his key to the keyservers > or not, it is still a good idea and in the interest of > the OpenPGP community to utilize the keyservers. There are privacy issues, especially if user-ids on the key contain email addresses. In some cases, the authorities knowing an individual used encryption could be a problem. There is the issue of controlling the image that is portrayed by the signatures on your key. Of course, if you are signing messages to a public list such as this, it *is* a good idea to put the key on a server. > *Public* key encryption is fostered by the *public* > dissemination of keys and the keyservers are, IMO, the > best mechanism for that. Keyservers are certainly good for quick circulation of a key revocation. Other than that, how the presence of my key on a keyserver foster the use of encryption when emailing me? It will probably not be noticed by anybody who doesn't use OpenPGP already. >> Some people hate the idea and get *very* upset if >> their key does end up on the servers. > Ohhhhhhhhhhhhhhh... I see. Do they take their ball and > go home? Do they jump up and down? Stomp their feet? > Hold their breath until they turn blue? Do they forward > private email to a public list? I apologise for that indiscretion. It was threaded as a reply to my post on the public list, and it didn't occur to me that it might have been sent just to me. Sorry if I offended you. > Such key sequestration is a minority viewpoint and I > doubt even a good number of folks on a fully encrypted > forum such as PGPNet would agree with you and would > instead support keyserver use. What's not to agree with in my statement that not everybody wants to put their keys on the keyservers? Some PGPNET members prefer to use Biglumber, or to post their key on their own website. Quite a few members use the keyservers, and some are active in networks such as GSWoT. Some members don't choose to have their key on the servers, and there was heated discussion some time back when somebody signed everybody's keys and uploaded them to a keyserver. - -- Best regards MFPA mailto:expires2010 at ymail.com I would like to help you out. Which way did you come in? -----BEGIN PGP SIGNATURE----- iQCVAwUBS4fufqipC46tDG5pAQpdpQP+Jt6wFJyyfGenY/9zNZqLGRqVXkv1vMxz 5wxYHUHOtLCEgUWugajfR7TQ7/4PBm1R6lN4+7rtltepswGUiikniEkHfhBLJx+t K22Aa+vr3ZxS5bA2K/rsvNQyrPcr0O0Wqrst4oxIs8qamToxPpsBTHUMTONxfG11 gRypxuzUFig= =yb7f -----END PGP SIGNATURE----- From expires2010 at ymail.com Fri Feb 26 17:23:20 2010 From: expires2010 at ymail.com (MFPA) Date: Fri, 26 Feb 2010 16:23:20 +0000 Subject: key question In-Reply-To: <1267137001.10876.85.camel@localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <1267137001.10876.85.camel@localhost> Message-ID: <205633239.20100226162320@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Paul On Thursday 25 February 2010 at 10:30:00 PM, you wrote: > In my case, the reason that I uploaded my keys to public keyservers was > to make it possible for anyone who wanted to privately communicate with > me to do so. Even if I didn't know them. Do many people check the keyservers for a possible key when they contact somebody they have not emailed before? > If the reason for keeping the public key to yourself is that you don't > want anyone, except for a selected few, to know your "secret" e-mail > address, then create two e-mail addresses. One will only be shared with > people you know intimately, and the other will be for the public. Or upload a key with no email address in the user-id. If you use multiple email addresses and change them regularly, this is simplest. Of course, some mail apps use the email address to choose the encryption key, so some contacts may be inconvenienced by this. > I never understood how anyone would want to use PGP for e-mail privacy, > and, subsequently, keep the public key a secret! I don't see any reason > why a person would keep his key off the public keyservers, short of > preventing spam. And you know what, he would get spammed anyway. I don't think there is much evidence of spammers harvesting email addresses from keyservers but you would expect it to happen to an extent. Use of encryption may put an individual under suspicion of illegal or subversive activity, or in some places may be illegal itself. Isn't that a good enough reason to not want a key on a public server showing your name and/or an email address that can be traced to you? - -- Best regards MFPA mailto:expires2010 at ymail.com You can't build a reputation on what you are going to do -----BEGIN PGP SIGNATURE----- iQCVAwUBS4f1gKipC46tDG5pAQr5dgP+OPE+I9WGuYSkv8H0qYQuoodgY8fpYLw9 F7N/Lnzh8gPKKdTem71ifku+HMb6qUqPRKURUy2lC33u5QDObl4bYTUd5x5L/H1w 0FeWgR1AI4JVGCYLXb/wSnEe900CDEbGi8gRyI7oiKZpPhm+fSHfcZTpiRNW4hqK Y5il1bwtfgU= =OLRs -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Fri Feb 26 17:24:22 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 26 Feb 2010 11:24:22 -0500 Subject: key question In-Reply-To: <1567563532.20100226144900@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <4B8723FA.3030809@gmail.com> <4B873EED.2090008@sixdemonbag.org> <1567563532.20100226144900@my_localhost> Message-ID: <4B87F5B6.8060703@sixdemonbag.org> On 2/26/10 9:49 AM, MFPA wrote: > I thought signing somebody's key was just stating to the world that > you believe the claimed identity of the person who controls that key > at the time you are signing it - not an indication that you are in any > way "associated." I'm scratching my head here trying to figure out how you can reasonably affirm the claimed identity of the person who controls the key if you are in no way associated with them. A signature on a key says, "I believe this key really corresponds to this person." But if you have no association whatsoever with that person, how can you make a signature? The existence of the signature necessitates at least *some* association. Even a trusted timestamp service that makes signatures without any human intervention makes an association claim: "at this date and time, someone sent this document to me for signing." From dshaw at jabberwocky.com Fri Feb 26 17:33:03 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 26 Feb 2010 11:33:03 -0500 Subject: key question In-Reply-To: <4B87F5B6.8060703@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <4B8723FA.3030809@gmail.com> <4B873EED.2090008@sixdemonbag.org> <1567563532.20100226144900@my_localhost> <4B87F5B6.8060703@sixdemonbag.org> Message-ID: <113B0E28-C8C7-4C06-B8EF-D4323FC8FCF9@jabberwocky.com> On Feb 26, 2010, at 11:24 AM, Robert J. Hansen wrote: > On 2/26/10 9:49 AM, MFPA wrote: >> I thought signing somebody's key was just stating to the world that >> you believe the claimed identity of the person who controls that key >> at the time you are signing it - not an indication that you are in any >> way "associated." > > I'm scratching my head here trying to figure out how you can reasonably > affirm the claimed identity of the person who controls the key if you > are in no way associated with them. There is associated and then there is associated. I suspect MFPA is using the term in the "met casually, perhaps at a keysigning event" sense, and not in the "friends with", or "partners in crime with" sense. Both are associated. The latter two are (forgive me) more associated. David From rjh at sixdemonbag.org Fri Feb 26 18:04:36 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 26 Feb 2010 12:04:36 -0500 Subject: key question In-Reply-To: <373551548.20100226155327@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> Message-ID: <4B87FF24.3000005@sixdemonbag.org> On 2/26/10 10:53 AM, MFPA wrote: > There are privacy issues, especially if user-ids on the key contain > email addresses. This isn't persuasive. It's been hammered out tons of times, and no one has ever presented a strong argument for keeping email addresses secret. Usually the same arguments are marshaled against it again and again, and those are the same arguments that have not been persuasive. > In some cases, the authorities knowing an individual used encryption > could be a problem. Why? Because they have a key on the keyservers? If this is what you're worried about, rest easy: there are so many easier ways to learn whether someone uses encrypted email that I can't imagine competent law-enforcement searching the keyservers. For instance, in the United States the authorities can get your email headers without a warrant. That means to, from, subject, routing information, and all the kluges. Check the kluges on this email and I'm pretty sure you'll see kluges related to Enigmail. Presto, at that point people know I'm using a crypto-aware MTA. Investigators also don't develop very many leads based on "gee, this person uses crypto." Many more leads are developed based on kludge investigation -- what security geeks call "traffic analysis." If they nab a child pornographer and discover that you always emailed him between one and three days before the child pornographer uploaded a new set of images, well... that's the kind of interesting coincidence which will start a federal investigation. The fact you have a crypto key, not so much. > There is the issue of controlling the image that is portrayed by the > signatures on your key. That image can only be portrayed if the viewers are ignorant of how the WoT works. What you are saying here is, "we must change the way we act in order to accommodate the prejudices of the ignorant." Did that in high school -- it was the most disastrous social experiment of my life. I've seen nothing in the last twenty years to make me think I should repeat this experiment. > Other than that, how the presence of my key on a keyserver foster the > use of encryption when emailing me? It will probably not be noticed > by anybody who doesn't use OpenPGP already. The second sentence is a tautology. "OpenPGP technologies will probably not be used by people who don't use OpenPGP already." It's trivially true, which is to say that it's a true statement which leads nowhere. Speaking for myself, I've used the keyservers on several occasions. I'll meet someone in person, they'll give me their key ID and fingerprint, and then later on I'll pull down their key ID, verify their fingerprint, and then use it for communication with them. I have my OpenPGP fingerprint at the bottom of my business card for just this reason. When I hand out cards at conferences, I not only tell people how to contact me, but I give people all the information they need to contact me securely. I know several other people who do the same thing. > What's not to agree with in my statement that not everybody wants to > put their keys on the keyservers? I don't think we agree that's your statement. Not everybody believes the world is round, or that the Earth orbits the sun. You can always find at least *one* person who believes some nonsense, and the fact that not *everyone* agrees is not evidence that these minority fringe viewpoints should be allowed to substantially influence mainstream usage. The fact you are arguing so passionately for this point of view leads me to believe you have a horse in this race, and that you want to persuade other people to not upload keys by default. If all you're saying is, "there are people in the world who do not understand the keyserver network and get unhinged when others upload their public keys to it," then sure, I agree. Thread's dead, next subject, we'll continue to use the keyserver network and they'll continue to get unhinged. From expires2010 at ymail.com Fri Feb 26 18:38:52 2010 From: expires2010 at ymail.com (MFPA) Date: Fri, 26 Feb 2010 17:38:52 +0000 Subject: key question In-Reply-To: <4B86DC42.3070602@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> Message-ID: <1216241405.20100226173852@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Robert On Thursday 25 February 2010 at 8:23:30 PM, you wrote: > On 2/25/10 9:24 AM, MFPA wrote: >> Some people hate the idea and get *very* upset if their key does end >> up on the servers. > What you're advocating here is "DRM on the honor system." Don't copy > the key, don't distribute the key, don't upload the key, don't do > anything with the key, without the explicit permission of the key owner. I am *not* advocating the implementation of any form of Digital Restrictions Malware (DRM). Uploading a somebody else's key without first checking it is OK by them is a breach of their privacy and could well be illegal/unlawful in jurisdictions with data protection legislation (for example, if a company published a customer's key, showing their name and/or email address, to a server). > Me, I consider DRM on the honor system to be the exact same as any other > kind of DRM -- something to be overcome and then ignored. > If someone asks me nicely, "please do not upload this key," I will > probably say yes. But it is a *huge* leap to go from there to "do not > upload keys without the owners' permission." I don't see the connection between DRM and a perfectly proper respect for individual privacy. The majority of keys contain an email address in the UID. To me, it is no more acceptable to publish somebody's email address without their permission than it would be to publish their phone number or postal address. - -- Best regards MFPA mailto:expires2010 at ymail.com Volvo, Video, Velcro. (I came, I saw, I stuck around.) -----BEGIN PGP SIGNATURE----- iQCVAwUBS4gHNqipC46tDG5pAQqgsgP+K7G1M6RmXqor4VPOJVvOylvg1nxgVsBe O8+MJwjFmOxRYPtQksZjbpeFXWdiN3CgurSfEpVZVevdBIwPgi4fkT1tghtu8YVp s5fHKhWhQlbQ5JRgew3O/PjahVqTPVxIiBFTUdOG9IT4TcuAVpUHPgGbEUXrH29T 9T2o1+4L6Vo= =OS5L -----END PGP SIGNATURE----- From vorner at ucw.cz Fri Feb 26 17:20:34 2010 From: vorner at ucw.cz (Michal 'vorner' Vaner) Date: Fri, 26 Feb 2010 17:20:34 +0100 Subject: gpg-agent rejects correct password for ssh keys Message-ID: <20100226162034.GA9914@dragonfly.kolej.mff.cuni.cz> Good morning I have trouble with gpg-agent and its --enable-ssh-support. When I start it (for test by eval `gpg-agent --daemon --sh --enable-ssh-support`), I add my ssh key by ssh-add. It first asks for a passphrase of the key (in console), then gpg-agent asks for a new passphrase to store the key encrypted (by pinentry-gtk). I type it, retype it and try to ssh somewhere. The agent asks for a passphrase to decrypt the key. I type it again and, this is the problem, it says it is incorrect. I'm sure I typed it correctly (I tried several times the whole procedure, deleting the key and sshcontrol key between attempts), I even tried with empty passphrase. The key works fine with ssh-agent. This is its --version output: gpg-agent (GnuPG) 2.0.14 libgcrypt 1.4.5 I tried to use google, but it doesn't seem to give me any reasonable results. Could anyone point me in the right direction how to investigate what is wrong? I tried to get some debug output from the agent, but it either goes background or does not print the environment variables no matter which combination of --server, --daemon, --no-detach, --debug I tried. What do I do wrong? Thank you -- Have you ever been told you are an airplane? Michal 'vorner' Vaner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rjh at sixdemonbag.org Fri Feb 26 19:05:56 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 26 Feb 2010 13:05:56 -0500 Subject: key question In-Reply-To: <1216241405.20100226173852@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> Message-ID: <4B880D84.4060608@sixdemonbag.org> On 2/26/10 12:38 PM, MFPA wrote: > I am *not* advocating the implementation of any form of > Digital Restrictions Malware (DRM). You can say you're not advocating DRM -- but if it looks like a duck, swims like a duck, flies like a duck and quacks like a duck, then it's a duck. "Digital": yes, the public key is in a digital form. "Rights" : yes, you're advocating the owner possesses intrinsic rights. "Management": yes, you're advocating the owner should be allowed to have total control over how the key gets distributed. That's pretty extreme management. But, hey. If you don't like DRM on the honor system, I'm happy to call it ORCON ("Originator Controlled"). ORCON material doesn't get copied, shared, promulgated, forwarded on, without the originator's explicit permission. It is the most extreme form of DRM imaginable. I thought I was being generous by saying you were advocating DRM on the honor system instead of ORCON -- ORCON is much more onerous. My exposure to ORCON material came from my work with electronic voting systems. Government officials are sometimes willing to give electronic voting geeks a peek behind the curtain, so long as there's an ORCON agreement signed in blood with the Devil himself as an eyewitness. You're advocating public keys be treated like the inner secrets of how electronic voting machines work. So am I. It's just that you're advocating they all be kept secret by default and publication being an exception to the rule -- and I'm advocating they all be kept public by default and secrecy being the exception to the rule. > Uploading a somebody else's key without first checking it is OK by > them is a breach of their privacy You're claiming they have a reasonable expectation that, if they share data that is clearly marked *public*, the recipient should understand *public* means "clear it with me first"? I don't think that's a reasonable expectation. The key says "public" right at the very top, and I think it's unreasonable to expect people to infer that it means "no, don't share it." This is why the burden is on the key provider: if you don't want the key shared, you have to explicitly tell someone about it. If you don't tell someone about it, they are allowed to think the phrase "public" means just that. > and could well be illegal/unlawful > in jurisdictions with data protection legislation (for example, if a > company published a customer's key, showing their name and/or email > address, to a server). That's not the key sharer's problem. That's the problem of the person who provided the key. If you know it would be unlawful for you to share information, don't share it. > I don't see the connection between DRM and a perfectly proper respect > for individual privacy. By implication, then, I lack a proper respect for individual privacy. At this point this seems to be dropping straight into the ad-hominem range. From faramir.cl at gmail.com Fri Feb 26 18:17:52 2010 From: faramir.cl at gmail.com (Faramir) Date: Fri, 26 Feb 2010 14:17:52 -0300 Subject: key question In-Reply-To: <205633239.20100226162320@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <1267137001.10876.85.camel@localhost> <205633239.20100226162320@my_localhost> Message-ID: <4B880240.40906@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 MFPA escribi?: ... > Do many people check the keyservers for a possible key when they > contact somebody they have not emailed before? Well, I have done that once or twice... ... > Use of encryption may put an individual under suspicion of illegal or > subversive activity, or in some places may be illegal itself. Isn't > that a good enough reason to not want a key on a public server showing > your name and/or an email address that can be traced to you? Right, and in those cases, I think people using illegal encryption tools should not rely on other people keeping the public key secret, after all, uploading the wrong key to a keyserver can be just one click away from uploading the right one... and people make mistakes. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLiAJAAAoJEMV4f6PvczxAuBgIAJkrmS4/o9ZWi34EPe9TMiNp GOw44cCP8/GsmhPa+SiqmH9l5F4LhXWzBOZy0Yu8hwcQmp2OZIxK0kFFuztU6+0Q w0l0NNze0WT81Knlu2zI78UxfUhczNgK32SmRGOL7xUtafn8lJZO0TdLiFhv74eS FjRr2nWyhPUY3R3jIbeJrRl/Jp3GbpECgX/l7wP8BNJzisk3/C8x+ZlfJ+P49EkQ 0/VM00JQnxNux+o/YhHqXMYJMqHJzmPvOl8CyKSasDmZ9kmP7TkMBXedng33r2ZW gkdEBaMjC8a6FiJvrX7/F0dxJjBqYcDLMHW/3Ccp1S+N8VGVL2bepmK3eyqvqgs= =NkdG -----END PGP SIGNATURE----- From kgo at grant-olson.net Fri Feb 26 19:30:16 2010 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 26 Feb 2010 13:30:16 -0500 Subject: key question In-Reply-To: <1216241405.20100226173852@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> Message-ID: <4B881338.3060000@grant-olson.net> On 2/26/2010 12:38 PM, MFPA wrote: > > I am *not* advocating the implementation of any form of > Digital Restrictions Malware (DRM). > > Uploading a somebody else's key without first checking it is OK by > them is a breach of their privacy and could well be illegal/unlawful > in jurisdictions with data protection legislation (for example, if a > company published a customer's key, showing their name and/or email > address, to a server). > As a practical matter, even if your contacts agree to respect your wishes, it's still pretty easy for them to accidentally send it to the keyservers. Perhaps mis-typing a command when they try to upload their own key. Perhaps clicking the wrong button. Perhaps because they just don't really know how gpg works and start typing random commands. From a practical perspective, whether it's right or wrong, you've got to assume that if they can, they will, and that key will be out there forever. One of the reasons to use public/private key encryption is because you don't always trust the other parties to do the correct thing. So if you are worried about the keyservers having information that could somehow implicate you in whatever, you'd need to obfuscate your UID, as you mentioned in another post. Asking people not to publish the key doesn't offer any real protection. And if you've done that, you might as well publish the key yourself. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Fri Feb 26 21:08:15 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 26 Feb 2010 15:08:15 -0500 Subject: key question In-Reply-To: <4B881338.3060000@grant-olson.net> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B881338.3060000@grant-olson.net> Message-ID: On Feb 26, 2010, at 1:30 PM, Grant Olson wrote: > On 2/26/2010 12:38 PM, MFPA wrote: >> >> I am *not* advocating the implementation of any form of >> Digital Restrictions Malware (DRM). >> >> Uploading a somebody else's key without first checking it is OK by >> them is a breach of their privacy and could well be illegal/unlawful >> in jurisdictions with data protection legislation (for example, if a >> company published a customer's key, showing their name and/or email >> address, to a server). >> > > As a practical matter, even if your contacts agree to respect your > wishes, it's still pretty easy for them to accidentally send it to the > keyservers. Perhaps mis-typing a command when they try to upload their > own key. Perhaps clicking the wrong button. Perhaps because they just > don't really know how gpg works and start typing random commands. An interesting tidbit here is that the OpenPGP spec actually handles this accidental submission case. There is a keyserver no-modify flag that can be set on a key, which requests that the keyserver reject any key that isn't submitted by the key owner. Alas, while GnuPG supports the flag, no keyserver does. (And in fact, supporting it would require a pretty significant redesign of the keyserver network). David From expires2010 at ymail.com Fri Feb 26 21:14:47 2010 From: expires2010 at ymail.com (MFPA) Date: Fri, 26 Feb 2010 20:14:47 +0000 Subject: key question In-Reply-To: <4B880D84.4060608@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> Message-ID: <1734230733.20100226201447@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Robert On Friday 26 February 2010 at 6:05:56 PM, you wrote: > On 2/26/10 12:38 PM, MFPA wrote: >> I am *not* advocating the implementation of any form of >> Digital Restrictions Malware (DRM). > You can say you're not advocating DRM -- but if it looks like a duck, > swims like a duck, flies like a duck and quacks like a duck, then it's a > duck. But if it bears only a slight resemblance to a duck, it is probably *not* a duck. > "Digital": yes, the public key is in a digital form. OK. > "Rights" : yes, you're advocating the owner possesses intrinsic rights. I am simply advocating the owner's right to privacy. Nothing spectacular, nor anything specific to PGP keys. > "Management": yes, you're advocating the owner should be allowed to have > total control over how the key gets distributed. That's pretty > extreme management. I have not knowingly advocated anything so extreme. The reasonable expectation that somebody will extend the common courtesy of checking with the owner before publishing their key falls somewhat short of the owner having total control over their key. > But, hey. If you don't like DRM on the honor system, I'm happy to call > it ORCON ("Originator Controlled"). The term "ORCON" reminds me of a 1970s TV programme about an alien. (-; > ORCON material doesn't get copied, > shared, promulgated, forwarded on, without the originator's explicit > permission. It is the most extreme form of DRM imaginable. I thought I > was being generous by saying you were advocating DRM on the honor system > instead of ORCON -- ORCON is much more onerous. I am not advocating that at all. I see the merit of a system that only allowed the key owner to publish the key to a server. How this could reasonably be achieved is not clear to me. And was not what I was discussing here. > My exposure to ORCON material came from my work with electronic voting > systems. Government officials are sometimes willing to give electronic > voting geeks a peek behind the curtain, so long as there's an ORCON > agreement signed in blood with the Devil himself as an eyewitness. Typical of a government to be ultra-secretive about the wrong things. You would think trust in electronic voting systems would flow from transparency, not secrecy. How can the voters have confidence that the system cannot be manipulated by those running it? > You're advocating public keys be treated like the inner secrets of how > electronic voting machines work. So am I. It's just that you're > advocating they all be kept secret by default and publication being an > exception to the rule -- and I'm advocating they all be kept public by > default and secrecy being the exception to the rule. I think the inner secrets of how electronic voting machines work should be open-source and available for peer-review. I think personally-identifiable information, including an individual's openPGP key, should not be made public without the consent of the individual. >> Uploading a somebody else's key without first checking it is OK by >> them is a breach of their privacy > You're claiming they have a reasonable expectation that, if they share > data that is clearly marked *public*, the recipient should understand > *public* means "clear it with me first"? > I don't think that's a reasonable expectation. The key says "public" > right at the very top, and I think it's unreasonable to expect people to > infer that it means "no, don't share it." > This is why the burden is on the key provider: if you don't want the key > shared, you have to explicitly tell someone about it. If you don't tell > someone about it, they are allowed to think the phrase "public" means > just that. I think it is reasonable to expect the recipient to know that it says "PGP PUBLIC KEY BLOCK." I don't see any reason why they would split the words and interpret each one as a standalone; if people do that, I'm waiting to hear from those who think the key can't be used with GPG, it will open a door or start a car, and that if they had a pile of them they could build a wall. (-; The use of the word "public" in the descriptor "public key" was an unfortunate choice if people are going to interpret things in that manner. I think it is a reasonable expectation that the key owner would have uploaded their key to the keyservers themselves if they wanted it to be there. If the key is not already on the servers, that is a pretty strong indicator that the key owner wants it that way. >> and could well be illegal/unlawful >> in jurisdictions with data protection legislation (for example, if a >> company published a customer's key, showing their name and/or email >> address, to a server). > That's not the key sharer's problem. That's the problem of the person > who provided the key. If you know it would be unlawful for you to share > information, don't share it. I don't understand your comment. It's not unlawful for the individual to share their own information. It would be unlawful for the recipient of that information to share it with others without consent from the individual, or to keep it for longer than reasonably necessary, or to use it for any purpose other than what the customer was told it would be used for. So, the merchant told the customer he would communicate by encrypted email if the customer supplied their public key. The customer was not told the merchant would upload the key to a server; if the merchant did upload it, the merchant would have acted unlawfully. >> I don't see the connection between DRM and a perfectly proper respect >> for individual privacy. > By implication, then, I lack a proper respect for individual privacy. > At this point this seems to be dropping straight into the ad-hominem range. I was thinking maybe you might explain to me the connection you draw between DRM and respecting individual privacy, since I do not see one. It would appear I have offended you; for that I am very sorry. - -- Best regards MFPA mailto:expires2010 at ymail.com Vegetarian: Indian word for lousy hunter!!! -----BEGIN PGP SIGNATURE----- iQCVAwUBS4grwaipC46tDG5pAQot8QQArRG5BnDnup4QBTGCFnDajTSzp14Xm7t4 itHb3BOElFuz2uIJTVbO0cqyMS0Oq8YxsmPrDIxPIkx1RHqljQCZcn0Jo8bfdtko FnfjYERkNny+ZiM05WU2G65IriNjID7trkD6MdrvxiUS3hsjjiYy68AGqd3YtVll 4CWflvpTPCE= =WfUj -----END PGP SIGNATURE----- From mailing-lists-mmvi at bretschneidernet.de Fri Feb 26 19:34:28 2010 From: mailing-lists-mmvi at bretschneidernet.de (Martin Bretschneider) Date: Fri, 26 Feb 2010 19:34:28 +0100 Subject: key generation: email-address necessary? Message-ID: <201002261934.28476.mailing-lists-mmvi@bretschneidernet.de> Hi, I want to recreate my GnuPG keys. My question is if I can omit the email address? Since I do not want my email addresses to appear on the keyservers because of spammers and so on. I only want to put my name and maybe my toplevel domain in the comment field. Is the some kind of problem with this behavoir? Can email clients find out what key to use if there is no known email address? What do you think? Kind regards from the CeBIT town;) Martin -- http://www.bretschneidernet.de/ OpenPGP-key: 0x4EA52583 _o)(o_ Albert Einstein: -./\\//\.- Few are those who see with their _\_VV_/_ own eyes and feel with their own hearts. From kgo at grant-olson.net Fri Feb 26 21:37:03 2010 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 26 Feb 2010 15:37:03 -0500 Subject: key question In-Reply-To: References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B881338.3060000@grant-olson.net> Message-ID: <4B8830EF.2060800@grant-olson.net> > > Alas, while GnuPG supports the flag, no keyserver does. > > David > Just curious... Does support just mean it sets the bit? Or will it turn an attempt to --send-keys on that key into a no-op? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Fri Feb 26 21:39:07 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 26 Feb 2010 15:39:07 -0500 Subject: key question In-Reply-To: <4B8830EF.2060800@grant-olson.net> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B881338.3060000@grant-olson.net> <4B8830EF.2060800@grant-olson.net> Message-ID: <97334E1F-BA6F-403E-83EB-51DAEE32FF63@jabberwocky.com> On Feb 26, 2010, at 3:37 PM, Grant Olson wrote: > >> >> Alas, while GnuPG supports the flag, no keyserver does. >> >> David >> > > Just curious... Does support just mean it sets the bit? Or will it turn > an attempt to --send-keys on that key into a no-op? Support means it gives the user the ability to set and clear the bit (it is set by default). David From dshaw at jabberwocky.com Fri Feb 26 21:42:11 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 26 Feb 2010 15:42:11 -0500 Subject: key generation: email-address necessary? In-Reply-To: <201002261934.28476.mailing-lists-mmvi@bretschneidernet.de> References: <201002261934.28476.mailing-lists-mmvi@bretschneidernet.de> Message-ID: <7F35684A-C5AD-4D34-BF80-C831A759F97B@jabberwocky.com> On Feb 26, 2010, at 1:34 PM, Martin Bretschneider wrote: > Hi, > > I want to recreate my GnuPG keys. My question is if I can omit the email > address? Since I do not want my email addresses to appear on the > keyservers because of spammers and so on. I only want to put my name and > maybe my toplevel domain in the comment field. > > Is the some kind of problem with this behavoir? Can email clients find > out what key to use if there is no known email address? There is no problem with this from the crypto or GnuPG/OpenPGP or keyserver perspective. They don't care what the user ID field is, and whether it contains a name, an email address, or both. But: as you note, this can be a problem for some email clients, which tend to try and locate keys via an email address in the user ID field. If you're willing to forego that piece of functionality, then it generally can be made to work via manual configuration for that key. David From expires2010 at ymail.com Fri Feb 26 22:03:14 2010 From: expires2010 at ymail.com (MFPA) Date: Fri, 26 Feb 2010 21:03:14 +0000 Subject: key question In-Reply-To: <4B881338.3060000@grant-olson.net> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B881338.3060000@grant-olson.net> Message-ID: <108451922.20100226210314@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Grant On Friday 26 February 2010 at 6:30:16 PM, you wrote: > As a practical matter, even if your contacts agree to respect your > wishes, it's still pretty easy for them to accidentally send it to > the keyservers. Perhaps mis-typing a command when they try to upload > their own key. Perhaps clicking the wrong button. Perhaps because > they just don't really know how gpg works and start typing random > commands. Yes, for example in GPGshell, "Send to Key-server" and "Update from Key-server" are adjacent context menu items. And the submenus that they generate are almost identical, so it is easy to not spot if you have clicked the wrong one. I also would prefer it if GPG itself asked for confirmation of action (including displaying the key-ID and user-IDs) for the --send-keys command, with the assumption of "no" unless you typed "y" > From a practical perspective, whether it's right or wrong, you've got to > assume that if they can, they will, But you may still wish they didn't and couldn't (-; > and that key will be out there forever. Yes, unfortunately. > One of the reasons to use public/private key encryption is > because you don't always trust the other parties to do the correct thing. > So if you are worried about the keyservers having information that could > somehow implicate you in whatever, you'd need to obfuscate your UID, as > you mentioned in another post. Asking people not to publish the key > doesn't offer any real protection. And if you've done that, you might > as well publish the key yourself. Not including your name or your email address in the UID offers protection against the accidental upload scenario. But somebody could still generate a key with a UID suggesting nefarious activities, sign your key with it, and upload it. Or their UID could simply identify whose was the key with the obfuscated UID. - -- Best regards MFPA mailto:expires2010 at ymail.com If you can't convince them, confuse them. -----BEGIN PGP SIGNATURE----- iQCVAwUBS4g3GqipC46tDG5pAQqByQQApxVwdqtUdGONlXENU7Nmnt/wm2PG/BSC NybXrNs2H+1hn1jo1MsRiqeXLmsObviQyAW1wPW3ieCf3STsTRA6iESnl6jc2r6n OmmImS3ItBjNTybz/qzoScZFRYw0K79ASptn0TQuhVExiuRB/Bb4YvmytpVHri6Q S/QQuhUVGbY= =hKiF -----END PGP SIGNATURE----- From expires2010 at ymail.com Fri Feb 26 22:10:41 2010 From: expires2010 at ymail.com (MFPA) Date: Fri, 26 Feb 2010 21:10:41 +0000 Subject: key question In-Reply-To: <97334E1F-BA6F-403E-83EB-51DAEE32FF63@jabberwocky.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B881338.3060000@grant-olson.net> <4B8830EF.2060800@grant-olson.net> <97334E1F-BA6F-403E-83EB-51DAEE32FF63@jabberwocky.com> Message-ID: <434621938.20100226211041@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 26 February 2010 at 8:39:07 PM, in , David Shaw wrote: > On Feb 26, 2010, at 3:37 PM, Grant Olson wrote: >>> Alas, while GnuPG supports the flag, no keyserver >>> does. >>> David >> Just curious... Does support just mean it sets the >> bit? Or will it turn an attempt to --send-keys on >> that key into a no-op? > Support means it gives the user the ability to set and > clear the bit (it is set by default). Would there not be some merit in honouring the flag by (at least) giving an extra warning to answer if you execute --send-keys to upload a key with that bit set? - -- Best regards MFPA mailto:expires2010 at ymail.com Don't anthropomorphize computers - they hate it -----BEGIN PGP SIGNATURE----- iQCVAwUBS4g42aipC46tDG5pAQpbhgP/UR/YSCW6ns0SZbrSBaiHVppLI2tZLg2D iGLChDodKWh/OI93e6wlZlxtgDv5ZywdzXcM+8yehCNiW4ifmaHnpA9NAMlYcS/u Uuw5aG/CE1uhnLsnbwX8QzSvUBsaMaLm0oJZRq+2LyippQu/27L4PvS8f1oWKXnp 1eX02sMESpY= =eGNU -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Fri Feb 26 22:14:58 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 26 Feb 2010 16:14:58 -0500 Subject: key question In-Reply-To: <1734230733.20100226201447@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> Message-ID: <4B8839D2.4080206@sixdemonbag.org> On 2/26/10 3:14 PM, MFPA wrote: > But if it bears only a slight resemblance to a duck, it is probably > *not* a duck. You are asserting that (a) the person who created the public key owns the information, (b) the person owns the information has the right to control how it is disseminated, and (c) that if someone shares the information in violation of the owner's wishes they are doing something morally and/or legally wrong. You have to assert (a). Ownership is the legal and/or moral right to control how a resource is utilized. I own my car because I have the legal and moral right to control who drives it. You are claiming the originator of the key material has the legal and moral right to control how it is disseminated: therefore, you are making a claim the originator of the key *owns* the information contained in that key. You have to assert (b). It follows logically from (a). (a) implies (b). And you are asserting (c). You're dressing it up in polite rhetoric about the right to privacy, but at the end of the day you're asserting that people are doing something wrong if they violate the information owner's wishes. In other words, you're in the same boat as the MPAA. Looks like a duck, swims like a duck, quacks like a duck: it's a duck. > The reasonable expectation that somebody will extend the common > courtesy of checking with the owner before publishing their key > falls somewhat short of the owner having total control over their > key. You are presupposing the expectation is reasonable. I am not willing to grant that as a given. > I think personally-identifiable information, including an > individual's openPGP key, should not be made public without the > consent of the individual ... I think it is a reasonable expectation > that the key owner would have uploaded their key to the keyservers > themselves if they wanted it to be there. Again, you are begging the question. We're trying to figure out whether it is reasonable to expect people to keep public keys secret without the owner's permission. What you're saying here is, "it's reasonable because I think it is reasonable." You're assuming the truth of the proposition in question, and using it to try and establish the truth of the proposition in question. > If the key is not already on the servers, that is a pretty strong > indicator that the key owner wants it that way. It's an indicator the key owner has not uploaded it to that network. For instance, what if the key has been uploaded to PGP's keyserver (which, last I checked, did not sync with the network, but is publicly accessible), but not the global network? Is that evidence the key owner wants it publicized, but just not publicized on the global network? Etc., etc. There are a *ton* of edge cases here. The absence of a key on the keyserver network is, itself, only evidence that it's not there. It doesn't show motive, any more than my having a shotgun in my closet shows my motive to commit murder. > I don't understand your comment. It's not unlawful for the > individual to share their own information. It would be unlawful for > the recipient of that information to share it with others without > consent from the individual I am unaware of your qualifications to talk about universally-applicable law. I cannot accept your expert opinion on this subject without it first being established that you are an expert. From expires2010 at ymail.com Fri Feb 26 22:40:14 2010 From: expires2010 at ymail.com (MFPA) Date: Fri, 26 Feb 2010 21:40:14 +0000 Subject: key question In-Reply-To: <113B0E28-C8C7-4C06-B8EF-D4323FC8FCF9@jabberwocky.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <4B8723FA.3030809@gmail.com> <4B873EED.2090008@sixdemonbag.org> <1567563532.20100226144900@my_localhost> <4B87F5B6.8060703@sixdemonbag.org> <113B0E28-C8C7-4C06-B8EF-D4323FC8FCF9@jabberwocky.com> Message-ID: <1582877174.20100226214014@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi David On Friday 26 February 2010 at 4:33:03 PM, you wrote: > On Feb 26, 2010, at 11:24 AM, Robert J. Hansen wrote: >> On 2/26/10 9:49 AM, MFPA wrote: >>> I thought signing somebody's key was just stating to the world that >>> you believe the claimed identity of the person who controls that key >>> at the time you are signing it - not an indication that you are in any >>> way "associated." >> >> I'm scratching my head here trying to figure out how you can reasonably >> affirm the claimed identity of the person who controls the key if you >> are in no way associated with them. > There is associated and then there is associated. I suspect MFPA > is using the term in the "met casually, perhaps at a keysigning > event" sense, and not in the "friends with", or "partners in crime with" sense. > Both are associated. The latter two are (forgive me) more associated. This is an example of what I meant:- Somebody met me once, briefly. They showed me a genuine-looking passport that didn't look as if it had been tampered with, they looked like the photo in the passport (though, hopefully, less ill!), and the name in the passport matched the UID on the key. My signature says I believe this person has the name they claim to have. Nothing more and nothing less. I would not consider myself to be "associated" with this person, although I concede that my signature on their key associates us in the web of trust. - -- Best regards MFPA mailto:expires2010 at ymail.com COMMITTEE: A body that keeps minutes and wastes hours. -----BEGIN PGP SIGNATURE----- iQCVAwUBS4g/x6ipC46tDG5pAQqt8gP/VazjXsg96lC46tXhFFuVz+tBmnqO2byw VHqq8ODKOS+1grR8kzjrdYZLGfDLUYYvqshAdaM888xqJ3VarFtI/mKAm1CC0QTp jzVUQrdBZadryLPioPXmW4JTs3YnipQgUBJinJE8IRXPkM5fOPLUC5d5yj7Ubngu Y9HHA9gSjow= =Ps7x -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Fri Feb 26 23:08:28 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 26 Feb 2010 17:08:28 -0500 Subject: key question In-Reply-To: <434621938.20100226211041@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B881338.3060000@grant-olson.net> <4B8830EF.2060800@grant-olson.net> <97334E1F-BA6F-403E-83EB-51DAEE32FF63@jabberwocky.com> <434621938.20100226211041@my_localhost> Message-ID: <8FDF7163-7DFD-4346-8443-F9C93845691C@jabberwocky.com> On Feb 26, 2010, at 4:10 PM, MFPA wrote: >>> Just curious... Does support just mean it sets the >>> bit? Or will it turn an attempt to --send-keys on >>> that key into a no-op? > >> Support means it gives the user the ability to set and >> clear the bit (it is set by default). > > Would there not be some merit in honouring the flag by (at least) > giving an extra warning to answer if you execute --send-keys to upload > a key with that bit set? I don't think so. At best it's a false sense of security to block or warn on "gpg --send-keys xxxx" but not on (for example) "gpg --export xxxx" (which is then followed by by sending the key via a web browser or email). It also doesn't affect PGP. I'd rather not give the user the impression that this is more than it is. Plus (and I'll admit to a level of amusement in this situation), virtually all keys generated with GPG have the no-modify bit set, as it's the default. It would thus block/warn on most every key. David From dshaw at jabberwocky.com Fri Feb 26 23:12:29 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 26 Feb 2010 17:12:29 -0500 Subject: key question In-Reply-To: <108451922.20100226210314@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B881338.3060000@grant-olson.net> <108451922.20100226210314@my_localhost> Message-ID: <34B793E5-33EA-432F-8497-D3C85A2622FC@jabberwocky.com> On Feb 26, 2010, at 4:03 PM, MFPA wrote: > Not including your name or your email address in the UID offers > protection against the accidental upload scenario. But somebody could > still generate a key with a UID suggesting nefarious activities, sign > your key with it, and upload it. Or their UID could simply identify > whose was the key with the obfuscated UID. The nefarious UID signature is not uncommon. There are many "president at whitehouse.gov" keys (and other famous figures) that have signed well-known keys. It's just easily-ignored noise, though, and has no impact on the web of trust. David From John at Mozilla-Enigmail.org Sat Feb 27 00:46:58 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Fri, 26 Feb 2010 17:46:58 -0600 Subject: key question In-Reply-To: <205633239.20100226162320@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <1267137001.10876.85.camel@localhost> <205633239.20100226162320@my_localhost> Message-ID: <4B885D72.6080805@Mozilla-Enigmail.org> MFPA wrote: >> I never understood how anyone would want to use PGP for e-mail privacy, >> and, subsequently, keep the public key a secret! I don't see any reason >> why a person would keep his key off the public keyservers, short of >> preventing spam. And you know what, he would get spammed anyway. > > I don't think there is much evidence of spammers harvesting email > addresses from keyservers but you would expect it to happen to an > extent. We've discussed keyserver SPAM for a bit over five years among the development team as well as on the Enigmail list. Keyserver SPAM happens. Addresses are harvested. We've tested and documented it. However, the quantity of keyserver SPAM is statistically indistinguishable from that attributable to random noise. That's the reason several of us downplay it's significance. It's a drop in the bucket compared to the general firehose of SPAM. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at 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" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: From expires2010 at ymail.com Sat Feb 27 01:30:21 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 27 Feb 2010 00:30:21 +0000 Subject: key question In-Reply-To: <34B793E5-33EA-432F-8497-D3C85A2622FC@jabberwocky.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B881338.3060000@grant-olson.net> <108451922.20100226210314@my_localhost> <34B793E5-33EA-432F-8497-D3C85A2622FC@jabberwocky.com> Message-ID: <492760390.20100227003021@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi David On Friday 26 February 2010 at 10:12:29 PM, you wrote: > The nefarious UID signature is not uncommon. There are many > "president at whitehouse.gov" keys (and other famous figures) that have > signed well-known keys. It's just easily-ignored noise, though, and > has no impact on the web of trust. No impact on the web of trust. But your online presence (and possibly that of somebody else with the same name) can feed into decisions about employing you or doing business with you, often/usually made by people who don't actually understand the information they find. - -- Best regards MFPA mailto:expires2010 at ymail.com Look, it's a hat! It's not going to hurt you. -----BEGIN PGP SIGNATURE----- iQCVAwUBS4hnqqipC46tDG5pAQrosQQAgJcCy9zvllPkG7edCUIm+T26xJ1pkV79 YYW78kkr+ACk7LQpO5oufPF1Z1OKT63Dprnj+//iGuWtbpHsqPvGF9c1oC3Xz76o VQL6Fj1KJDHsZ5NX997Nt2DmZuzqaSQ/GVg9keFhFiA7/uUFCwKEr/9O4EMIW65J 7gJeigrz1YU= =MSlL -----END PGP SIGNATURE----- From rich.geddes at verizon.net Sat Feb 27 01:55:06 2010 From: rich.geddes at verizon.net (Richard Geddes) Date: Fri, 26 Feb 2010 19:55:06 -0500 Subject: key question In-Reply-To: <4B85A4DB.9030108@googlemail.com> References: <4B85A4DB.9030108@googlemail.com> Message-ID: <4B886D6A.3010802@verizon.net> As well as backing up your private key and password on other electronic storage (CD/memory stick... encrypted of course), I recommend that you print your private key, a revocation certificate, and your passphrase on paper, and store that document in a safe place... a secure lock box, ... a safety deposit box in a bank. I've had bad luck with CD/DVD media going bad, and consider them an unreliable resource simply because of integrity problems. Also, you may want to use Shamir's Secret Sharing Scheme to split up your passphrase among ***trusted*** friends, so that no single friend has the passphrase, but requires several of them to regenerate your passphrase when you loose your passphrase. Trust, in this context, really is about, statistically, how often someone follows the rules set up to maintain a secure environment, and not what or who you feel good about or admire. Trust is only created when you set up these types of structures... anything else is going on faith. Richard Tobias Holz wrote: > Hey Folks, > i succesfully installed gnupg on my Win7 machine. I want to use it > with Thunderbird to encrypt personal eMails. > Now I've got some questions: > 1) What does happen if I lose my private key? Can I burn it to a CD/DVD? > 2) Where can I find the key, I just got the passphrase? > > I generated the Keys with OpenPGP-Plugin for Thunderbird. I got the > public key (something_stands_here.asc) and encryption works fine :) > > Hopefully looking forward > Tobias > _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From dshaw at jabberwocky.com Sat Feb 27 03:51:26 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 26 Feb 2010 21:51:26 -0500 Subject: key question In-Reply-To: <492760390.20100227003021@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B881338.3060000@grant-olson.net> <108451922.20100226210314@my_localhost> <34B793E5-33EA-432F-8497-D3C85A2622FC@jabberwocky.com> <492760390.20100227003021@my_localhost> Message-ID: <1D9075A4-BC95-42DA-9A2C-B48C7BBC89D0@jabberwocky.com> On Feb 26, 2010, at 7:30 PM, MFPA wrote: > On Friday 26 February 2010 at 10:12:29 PM, you wrote: > > >> The nefarious UID signature is not uncommon. There are many >> "president at whitehouse.gov" keys (and other famous figures) that have >> signed well-known keys. It's just easily-ignored noise, though, and >> has no impact on the web of trust. > > > No impact on the web of trust. But your online presence (and possibly > that of somebody else with the same name) can feed into decisions > about employing you or doing business with you, often/usually made by > people who don't actually understand the information they find. There isn't much you can do about that, really. Forget keyservers for a moment - some random person can post the same sort of fake "relationship" information on their blog, and it would show up with a Google search for your name. David From expires2010 at ymail.com Sat Feb 27 04:52:02 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 27 Feb 2010 03:52:02 +0000 Subject: key question In-Reply-To: <4B8839D2.4080206@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> Message-ID: <333644023.20100227035202@my_localhost> Hi Robert On Friday 26 February 2010 at 9:14:58 PM, you wrote: > You are asserting that (a) the person who created the public key owns > the information, Actually, I am asserting that the public key is likely to contain personal information appertaining to the person who created that key. That person is the "data subject." "Ownership" of personal information is an odd concept. Who "owns" your date of birth or your bank account number, for example? > (b) the person owns the information has the right to > control how it is disseminated, and The data subject does have various rights concerning the personal information that is about him. > (c) that if someone shares the > information in violation of the owner's wishes they are doing something > morally and/or legally wrong. In many cases, yes. I've given an example in an earlier message in this thread of "legally wrong." As for morality, sharing somebody's personal information in violation of their wishes is, at best, a breach of trust. > [...] > And you are asserting (c). You're dressing it up in polite rhetoric > about the right to privacy, but at the end of the day you're asserting > that people are doing something wrong if they violate the information > owner's wishes. It would probably be difficult to talk about violation of Data Protection laws and principles without also talking about the right to privacy. > In other words, you're in the same boat as the MPAA. Looks like a duck, > swims like a duck, quacks like a duck: it's a duck. I was not aware that the MPAA had anything to do with safeguarding people's personal information. >> The reasonable expectation that somebody will extend the common >> courtesy of checking with the owner before publishing their key >> falls somewhat short of the owner having total control over their >> key. > You are presupposing the expectation is reasonable. I am not willing to > grant that as a given. Reasonable or otherwise, expecting that somebody will check with you first does not amount to your having "total control," IMHO. >> I think personally-identifiable information, including an >> individual's openPGP key, should not be made public without the >> consent of the individual ... I think it is a reasonable expectation >> that the key owner would have uploaded their key to the keyservers >> themselves if they wanted it to be there. > Again, you are begging the question. We're trying to figure out whether > it is reasonable to expect people to keep public keys secret without the > owner's permission. What you're saying here is, "it's reasonable > because I think it is reasonable." You're assuming the truth of the > proposition in question, and using it to try and establish the truth of > the proposition in question. We are discussing two things here: the public key itself and the personal information that is often found in the User-IDs on the public key. Assuming the presence of personal information, depending on the relationship between the parties involved and the circumstances under which the key was supplied, there are legal issues to consider. Of course, one of those legal issues could well be whether the data subject failed to properly safeguard their own personal information when they included it in the UID on their key (-; A more difficult question in the absence of personal data. I think - my opinion only; other opinions are also available - that if somebody chooses not to use the keyservers, that is their choice and they should not be forced to use them. (A bit like not being forced to have your phone number listed in the phone book.) >> If the key is not already on the servers, that is a pretty strong >> indicator that the key owner wants it that way. > It's an indicator the key owner has not uploaded it to that network. > For instance, what if the key has been uploaded to PGP's keyserver > (which, last I checked, did not sync with the network, but is publicly > accessible), but not the global network? Is that evidence the key owner > wants it publicized, but just not publicized on the global network? > Etc., etc. There are a *ton* of edge cases here. You would need to ask the key owner. The key does not remain in perpetuity on the PGP directory, for a start, and UIDs are removed if you don't reply to confirmation emails every few months. These substantial differences could well lead to somebody wishing their key to be on one and not the other. Alternatively, they may prefer to share it directly, to distribute it from an email auto-responder, to post it on their own website, to post it on BigLumber, or whatever. They might indicate this preference in their email headers or signature, in the comment field at the top of messages, in a signature notation... Sharing the key widely does not have to include the use of keyservers. > The absence of a key on the keyserver network is, itself, only evidence > that it's not there. It doesn't show motive, any more than my having a > shotgun in my closet shows my motive to commit murder. OK, you got me. >> I don't understand your comment. It's not unlawful for the >> individual to share their own information. It would be unlawful for >> the recipient of that information to share it with others without >> consent from the individual > I am unaware of your qualifications to talk about universally-applicable > law. My use of the phrase "in some places may be illegal" in Message-ID <205633239.20100226162320 at my_localhost> earlier in the thread indicates I am not talking about "universally-applicable law," whatever that might be. My "qualification" is through experience and research both as a consumer forced to deal with such issues and through being required to handle customers' personal information in compliance with the relevant legal requirements. > I cannot accept your expert opinion on this subject without it > first being established that you are an expert. I have made no claim to be an "expert" and would not expect anybody to accept the words of an anonymous stranger without doing a modicum of their own research. Specifically, I was referring to UK law, although equivalent safeguards are in place in every country in the EU and the EEA. Similar principles are applied in the laws of many other countries. References include:- http://www.rogerclarke.com/DV/PaperOECD.html http://ec.europa.eu/justice_home/fsj/privacy/instruments/oecdguideline_en.htm http://www.opsi.gov.uk/acts/acts1998/ukpga_19980029_en_1 http://www.ico.gov.uk/ http://en.wikipedia.org/wiki/International_Safe_Harbor_Privacy_Principles http://www.accurateinformationsystems.com/downloads/International_Data_Protection_Laws.pdf And Google or similar will find you many more. -- Best regards MFPA mailto:expires2010 at ymail.com If you can't convince them, confuse them. From expires2010 at ymail.com Sat Feb 27 05:55:07 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 27 Feb 2010 04:55:07 +0000 Subject: key question In-Reply-To: <4B87FF24.3000005@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> Message-ID: <20645864.20100227045507@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 26 February 2010 at 5:04:36 PM, in , Robert J. Hansen wrote: > On 2/26/10 10:53 AM, MFPA wrote: >> There are privacy issues, especially if user-ids on the key contain >> email addresses. > This isn't persuasive. It's been hammered out tons of > times, and no one has ever presented a strong argument > for keeping email addresses secret. Maybe not but there is a perceived need, as evidenced by services like spamgourmet and all the disposable email address outfits In any case, I've never seen a convincing argument *for* including email addresses in the UID of a PGP key. >> In some cases, the authorities knowing an individual >> used encryption could be a problem. > Why? Because they have a key on the keyservers? OK, as a reason not to upload somebody's key to a server without their consent, this was poor. I suspect an individual in those circumstances would take great care that whoever had their key knew to keep it secure. >> There is the issue of controlling the image that is >> portrayed by the signatures on your key. > That image can only be portrayed if the viewers are > ignorant of how the WoT works. What you are saying > here is, "we must change the way we act in order to > accommodate the prejudices of the ignorant." Well, now you put it that way... >> Other than that, how the presence of my key on a >> keyserver foster the use of encryption when emailing >> me? > Speaking for myself, I've used the keyservers on > several occasions. I'll meet someone in person, they'll > give me their key ID and fingerprint, and then later on > I'll pull down their key ID, verify their fingerprint, > and then use it for communication with them. If their key lived at their own website or on an email responder, for example, you could still do this - except the note of the fingerprint and key-id would also need to contain a URL. >> What's not to agree with in my statement that not >> everybody wants to put their keys on the keyservers? > I don't think we agree that's your statement. Not > everybody believes the world is round, or that the > Earth orbits the sun. You can always find at least > *one* person who believes some nonsense, and the fact > that not *everyone* agrees is not evidence that these > minority fringe viewpoints should be allowed to > substantially influence mainstream usage. OK OK, the post I was replying to when I started this stated "It is also a good idea to send your key to the keyservers." I do not see this statement as any kind of self-evident truth, yet I have been thoroughly taken to task for questioning it. The keyservers are just one of the platforms available for disseminating your key. What makes them the *best* platform? Nothing in this thread so far has convinced me of their supremacy. > The fact you are arguing so passionately for this point > of view leads me to believe you have a horse in this > race, and that you want to persuade other people to not > upload keys by default. I would no more deliberately publish somebody's key without their consent than I would pass on their phone number or address. I would expect that to be normal, without the need to persuade anybody. - -- Best regards MFPA mailto:expires2010 at ymail.com No matter where you go, there you are. -----BEGIN PGP SIGNATURE----- iQCVAwUBS4ilsqipC46tDG5pAQq7jAQAqijYzD96kV894BFofqqpGsp8j38a8a1p MRe6B3NQQTz9CP+rqS5Gs98aSuinMLteTqDpFKESYwOwTQbH4KXzxqxVTS5/E+u4 l75fgjo77VHQazOuPXsCjFuVvpNjhOKF3BHTYiexFebzcndLcXiNg/pAhU/OxofA Vk1EAVOp7m8= =R8XD -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sat Feb 27 07:11:29 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 27 Feb 2010 01:11:29 -0500 Subject: key question In-Reply-To: <20645864.20100227045507@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> Message-ID: <4B88B791.7000100@sixdemonbag.org> On 2/26/10 11:55 PM, MFPA wrote: > Maybe not but there is a perceived need, as evidenced by services > like spamgourmet and all the disposable email address outfits There is a perceived need for $150 bowls of soup, as evidenced by dozens of high-priced gourmet restaurants in major cities. The existence of a market for a service is not evidence that the service is generally useful or needed. > In any case, I've never seen a convincing argument *for* including > email addresses in the UID of a PGP key. First, the status quo doesn't need arguments in its favor. The status quo exists. *Changing* the status quo is what requires arguments in its favor. Second, then you don't have to include it in yours. Why are you bringing this up? I don't care what your UID is, and I don't want you to have a vote in whether I put an email address in mine. > If their key lived at their own website or on an email responder, > for example, you could still do this - except the note of the > fingerprint and key-id would also need to contain a URL. In which case you're still hosting it publicly, so why not use the keyservers? > OK OK, the post I was replying to when I started this stated "It is > also a good idea to send your key to the keyservers." I do not see > this statement as any kind of self-evident truth, yet I have been > thoroughly taken to task for questioning it. This is not "taking you to task." This is listening to your claims, and giving strong arguments against them. My father is a judge. Growing up, if I were to assert the sky was blue he would ask how I knew the sky was blue. (No, I'm not kidding.) It's a weird way to grow up, but it's served me very well in my life. All claims must be scrutinized and examined. If they survive the scrutiny, good. If they don't, then let's make note of them and remember not to waste time on these claims in the future. > The keyservers are just one of the platforms available for > disseminating your key. What makes them the *best* platform? You've set up a straw man. Nobody is arguing the keyserver network is the best platform. What is best will depend on each person's individual valuation of the many factors that go into this question. That said, it is broadly true that it's a good idea to send keys to the keyserver network. The reasons why have already been well-explained. Your reasons why not are either unfounded or debunked. In your voluminous defense of privacy rights, you've not given any numbers for what fraction of users need or want to keep their public keys private. If you're arguing that the "good idea" we've advocated is not a good idea, you need to show there are substantial numbers of users who will be negatively impacted. You haven't. You've talked about the danger of reputation being slandered by implication of association: but as David Shaw has pointed out, if someone wants to do that there are much easier ways to do it than with keys. You've talked about making it easy for law enforcement to learn who communicates securely with whom: but as I've said, law enforcement (at least in the US, and probably also the UK) has much easier ways to learn this. You've talked about spam: but as John Clizbe has pointed out, although keyservers do get harvested for addresses there is no statistically significant difference in the spamflood between putting a key on the server or keeping it private. You'd have to ask him about his methodology and his precise numbers, but I'm sure he'd be willing to provide them if you asked. (I used to share your concerns about spam, up until John showed me his numbers and convinced me.) The status quo is, "it is generally a good idea to send your key to the keyserver network." If you want to change that, the burden is on you to present persuasive evidence supporting a change. So far I've not seen it, which means the status quo stands. From free10pro at gmail.com Sat Feb 27 08:11:35 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Fri, 26 Feb 2010 23:11:35 -0800 Subject: problem with ownertrust value In-Reply-To: References: Message-ID: <1267254695.3938.22.camel@localhost> On Fri, 2009-12-04 at 02:11 -0200, Juan Manuel Fernandez Arauz wrote: > Hello, i have the this doubt: > > I have tried this: > gpg --local-user UID1 --edit-key UID3 > > trust > 5 > > and later: > gpg --local-user UID2 --edit-key UID3 > > trust > 1 > > But if i later execute this again: > gpg --local-user UID1 --edit-key UID3 > > i see "trust: dont know", and it supose that that value was for UID2, > not for UID1. > So i think im setting the ownertrust value for all users. Not quite. You are not setting the ownertrust value for all users but for yourself, as a person. The ownertrust value is about how much you, as a person, trust the possessor of the key to validate keys that he signs. Even though you tried setting the ownertrust by specifying a different "local user" each time, GnuPG didn't change the value in relation to the "local user" but in relation to you the person. > How can i set the ownertrust value user by user for a given UID? You can't. See the above. --Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 665 bytes Desc: This is a digitally signed message part URL: From laurent.jumet at skynet.be Sat Feb 27 09:59:21 2010 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Sat, 27 Feb 2010 09:59:21 +0100 Subject: key generation: email-address necessary? In-Reply-To: <201002261934.28476.mailing-lists-mmvi@bretschneidernet.de> Message-ID: Hello Martin ! Martin Bretschneider wrote: > I want to recreate my GnuPG keys. My question is if I can omit the email > address? Since I do not want my email addresses to appear on the > keyservers because of spammers and so on. I only want to put my name and > maybe my toplevel domain in the comment field. > Is the some kind of problem with this behavoir? Can email clients find > out what key to use if there is no known email address? > What do you think? You can use whatever you want to identify your key. But in some cases, mail programs expect to find your e-mail. -- Laurent Jumet KeyID: 0xCFAF704C From mailing-lists-mmvi at bretschneidernet.de Sat Feb 27 11:50:13 2010 From: mailing-lists-mmvi at bretschneidernet.de (Martin Bretschneider) Date: Sat, 27 Feb 2010 11:50:13 +0100 Subject: key generation: email-address necessary? In-Reply-To: References: Message-ID: <201002271150.13492.mailing-lists-mmvi@bretschneidernet.de> Am Samstag 27 Februar 2010 schrieb Laurent Jumet: Hi Laurent, > Martin Bretschneider wrote: > > I want to recreate my GnuPG keys. My question is if I can omit the > > email address? Since I do not want my email addresses to appear on > > the keyservers because of spammers and so on. I only want to put my > > name and maybe my toplevel domain in the comment field. > > Is the some kind of problem with this behavoir? Can email clients > > find out what key to use if there is no known email address? > > What do you think? > > You can use whatever you want to identify your key. > But in some cases, mail programs expect to find your e-mail. that was my expectation as well. But what do the email clients do then? Do they say "no key available" or do the look for the name? What are your experiences? TIA Martin -- http://www.bretschneidernet.de/ OpenPGP-key: 0x4EA52583 (o__o) Ernest Hemingway: //\/\\ I like to listen. I have learned a great deal V_/\_V from listening carefully. Most people never listen. From gesbbb at yahoo.com Sat Feb 27 12:25:17 2010 From: gesbbb at yahoo.com (Jerry) Date: Sat, 27 Feb 2010 06:25:17 -0500 Subject: key question In-Reply-To: <4B87FF24.3000005@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> Message-ID: <20100227062517.6c5ac5d8@scorpio.seibercom.net> On Fri, 26 Feb 2010 12:04:36 -0500 Robert J. Hansen articulated: > Investigators also don't develop very many leads based on "gee, this > person uses crypto." Many more leads are developed based on kludge > investigation -- what security geeks call "traffic analysis." If they > nab a child pornographer and discover that you always emailed him > between one and three days before the child pornographer uploaded a > new set of images, well... that's the kind of interesting coincidence > which will start a federal investigation. The fact you have a crypto > key, not so much. Maybe not totally apropos to this discussion; however, I worked in "traffic analysis" for several years. If given enough leeway, you would be amazed at the information you can gather about an individual, and at its astonishing accuracy rate. Just listening on various mail forums, I have been able to learn more about certain individuals than they would believe possible, or want known. Its all in knowing (and having the proper equipment and authority) in where to look. -- Jerry gesbbb at yahoo.com |::::======= |::::======= |=========== |=========== | tomorrow you may no longer feel guilty. From jmoore3rd at bellsouth.net Sat Feb 27 14:24:07 2010 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Sat, 27 Feb 2010 08:24:07 -0500 Subject: key question In-Reply-To: <20100227062517.6c5ac5d8@scorpio.seibercom.net> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20100227062517.6c5ac5d8@scorpio.seibercom.net> Message-ID: <4B891CF7.6030501@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Jerry wrote: > Maybe not totally apropos to this discussion; however, I worked in > "traffic analysis" for several years. If given enough leeway, you would > be amazed at the information you can gather about an individual, and at > its astonishing accuracy rate. > > Just listening on various mail forums, I have been able to learn more > about certain individuals than they would believe possible, or want > known. Its all in knowing (and having the proper equipment and > authority) in where to look. UAV & Missile Operators don't need to know what the message said; just where You are at the time it is Sent. Radio transmissions are targeted using "Huff-Duff" & GPS; Email is 'targeted' from the kludges. True enemies in 'hot combat' don't care what You're saying; only that You never 'speak' again. ? JOHN ;) Timestamp: Saturday 27 Feb 2010, 08:23 --500 (Eastern Standard Time) - -- "There are two kinds of people, those who do the work and those who take the credit. Try to be in the first group; there is less competition there." - --Indira Ghandi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Personal Web Page: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJLiRz1AAoJEBCGy9eAtCsPTrMIAKF3pduOatVIePKgJxkKKAR7 HymACsEHjfs5gkgXzRcbqpHEtyqGy1TiAoJjAGM6FWVvo7SFvI5yJ2rojIceuv5d uAaUDc6sx7bAgNTFZ+GZJPYBy4kxb6mLbDmutvhChXPaIxPEt+SFhBqqCbD7DICK iXIBpYeNWBWL+w12g6uWGLVF5kgM3IwwSn5VPxbRPyv9uvLng5tAbib+wlUhY+ln DcVihZv3PMHeRqeMS2nqjURlZh4FeLUZoqc7ck3j0oCM8xIG38Aa2Ob7SJdqIXyq rGd3nxrTtUconL8x9Sdd/nZSTar/AuWTdEhgOWZX/eC6i6qUGpOBRXRo5qSy1SU= =0q7a -----END PGP SIGNATURE----- From shavital at mac.com Sat Feb 27 14:29:22 2010 From: shavital at mac.com (Charly Avital) Date: Sat, 27 Feb 2010 08:29:22 -0500 Subject: OFF LIST In-Reply-To: <20100227062517.6c5ac5d8@scorpio.seibercom.net> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20100227062517.6c5ac5d8@scorpio.seibercom.net> Message-ID: <4B891E32.7010504@mac.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, news of the 8.8, or 8.3 earthquake that has stricken Chile have been posted in many on-line dailies. I have tried unsuccessfully to access a few portals in Chile (e.g. White Pages, the dailies) they seem to be down. I have also tried unsuccessfully to phone to some very close friends who live in Chile, not in the affected areas. I have also e-mailed Faramir directly, trying to have news. It is probable that the Telecom infrastructure that has not been affected by the earthquake is swamped with access attempts. I apologize for this intrusion, and thank in advance any information that subscribers to this list may have on the situation in the capital (Santiago), and in coastal resorts like Vi?a del Mar, Cachagua, Algarrobo (it's summer time in Chile now). Charly -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: GnuPG for Privacy Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLiR4wAAoJEM3GMi2FW4PveLAH/iqi2n4gOh33zkrLgdSoH0pC iVuOLlAlt00LcD7X3FnP6naLsFov/Lvv/CGYqedYieOl9lHJbJjY7m3IOq04unn4 3yhcGrZB+FjLw5CWHx+FxhI7Lvl4uUChPWiYrBqaLqJMXFxLAKQpys1DqyijzfCx ecNVbNe8PQmjg6azLJLnL0C26nVLxSI3tvgsXRHr/oDrBPT394il4tWFItch2+uO a1YEIzdH5q66aqN3dLURtoxk2iduKtrkelJIC0SddzH27DgIarxwO53ay8KhMIsw KcfbyeFfShmnDOJsJhRp9wYeFSvJw6h6woE+mlsJy0YfsQEf5w0YmSGKZBdnhAE= =OdLZ -----END PGP SIGNATURE----- From gesbbb at yahoo.com Sat Feb 27 15:26:12 2010 From: gesbbb at yahoo.com (Jerry) Date: Sat, 27 Feb 2010 09:26:12 -0500 Subject: OT: key question In-Reply-To: <4B891CF7.6030501@bellsouth.net> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20100227062517.6c5ac5d8@scorpio.seibercom.net> <4B891CF7.6030501@bellsouth.net> Message-ID: <20100227092612.29e67b6d@scorpio.seibercom.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 27 Feb 2010 08:24:07 -0500 John W. Moore III articulated: > UAV & Missile Operators don't need to know what the message said; just > where You are at the time it is Sent. Radio transmissions are > targeted using "Huff-Duff" & GPS; Email is 'targeted' from the > kludges. True enemies in 'hot combat' don't care what You're saying; > only that You never 'speak' again. ? I spent a great deal of time with HF/DF and its aerial variants. Fun but boring. However, the sender is usually not the target of said search, but rather the recipient. Locating the location of an enemy combatant when the transmission is CQ is a whole new ball game. - -- Jerry gesbbb at yahoo.com |::::======= |::::======= |=========== |=========== | I kissed my first girl and smoked my first cigarette on the same day. I haven't had time for tobacco since. Arturo Toscanini -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLiSuKAAoJEGnxpuiKsj5SMD0H/jdLjbvEImszwpR5n5zNz+hL A5SFgrmTMD5Q0RUk4G6gEo8z+lxSWyJ1V0qTMFs/fPM12yrxSgVjq0BWHdzhO9X7 66RM6p2vBC8FusqXUh5J5gR8RqZNyoUL/hwp2dXtFf9ALXdw891q0uN2PkrsyBCT GXVfYQaCVzW3qHqLGGp/uPzVrZBHIMhdRl+qLJT7h0sN3LTTLSC+yTKpM5IpaReV gG1Q7tRvaxv4WpJZiMELuRd51sgU5NFc1TUP5vAVnK6RmXSMKNFffu3eUFEIotjM ReprZvShopBmnymiqCtWDFG8pMxUd3WyXR2gpPT+hyuIA+QswMohoCVA8fHMUWY= =0L+o -----END PGP SIGNATURE----- From laurent.jumet at skynet.be Sat Feb 27 15:20:11 2010 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Sat, 27 Feb 2010 15:20:11 +0100 Subject: key generation: email-address necessary? In-Reply-To: <201002271150.13492.mailing-lists-mmvi@bretschneidernet.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello Martin ! Martin Bretschneider wrote: >> You can use whatever you want to identify your key. >> But in some cases, mail programs expect to find your e-mail. > that was my expectation as well. But what do the email clients do then? > Do they say "no key available" or do the look for the name? What are > your experiences? They can call another key with a similar name. :-) It's not easy to answer that question, as it depends on your own system. When you read a signed message, GPG provides a way to call automatically the sender's public key on your designed servers, when it doesn't find it in your PubRing; it goes on the Net, retrieves the key, incorporates it in your KeyRing and than verifyes the signature on the message. This process can abort if ID's doesn't match. - -- Laurent Jumet KeyID: 0xCFAF704C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iHEEAREDADEFAkuJLJoqGGh0dHA6Ly93d3cucG9pbnRkZWNoYXQubmV0LzB4Q0ZB RjcwNEMuYXNjAAoJEPUdbaDPr3BMRQgAnRkeHmnE/EI3kHwqWvgK7x8qN3j9AJsE LM/iV7sUasdYum08JlMDg7C+rA== =TRjg -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Sat Feb 27 15:58:53 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 27 Feb 2010 09:58:53 -0500 Subject: key question In-Reply-To: <4B87FF24.3000005@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> Message-ID: On Feb 26, 2010, at 12:04 PM, Robert J. Hansen wrote: >> In some cases, the authorities knowing an individual used encryption >> could be a problem. > > Why? Because they have a key on the keyservers? If this is what you're > worried about, rest easy: there are so many easier ways to learn whether > someone uses encrypted email that I can't imagine competent > law-enforcement searching the keyservers. > > For instance, in the United States the authorities can get your email > headers without a warrant. That means to, from, subject, routing > information, and all the kluges. Check the kluges on this email and I'm > pretty sure you'll see kluges related to Enigmail. Presto, at that > point people know I'm using a crypto-aware MTA. Do you really mean to suggest that a US authority getting email headers - even without a warrant - is easier than typing a name into a search box on a keyserver? No question that the authority *can* get such headers, but I question the "easier". Have you read the various (leaked) guides the ISPs have for delivery of such materials? They are fascinating, but in no way speedy. I'd expect a truly competent law-enforcement agent would get both - order the requested material from the ISP, and while he's waiting for delivery, take the 20 seconds to search a keyserver. (Of course, all this assumes that we're presuming guilt-by-encryption, or at least suspicion-by-encryption, which I don't really buy in any event). In any event, Rob, could you do me a huge favor and clarify what statement you are trying to make here? Jumping into a mail thread late is always fraught with misunderstanding, but, I've re-skimmed the thread, and I'm honestly still not sure what you're trying to say. It seems (and I could be utterly wrong), that MFPA is saying "Not everyone wants their key on the keyservers, so please don't automatically send other people's keys there. If the key owner wants the key on the keyservers, he'll send it himself." You seem to be saying "This is not based on good logic as I see it, and therefore.... (something)." What's the "(something)"? That you reserve the right to send other people's keys to the keyserver? That it's foolish to request that other people don't send them? Something else? Or perhaps I mischaracterize both your and MFPA's positions. What am I missing here? David From rjh at sixdemonbag.org Sat Feb 27 17:22:27 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 27 Feb 2010 11:22:27 -0500 Subject: key question In-Reply-To: References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> Message-ID: <4B8946C3.5050607@sixdemonbag.org> On 2/27/10 9:58 AM, David Shaw wrote: > Do you really mean to suggest that a US authority getting email > headers - even without a warrant - is easier than typing a name into > a search box on a keyserver? No. You're right, that's clearly easier. However, that only tells you whether someone has the technical capability to use encryption -- much the same way that a shotgun in my closet tells you I have the technical capability to commit murder. Generally speaking, law-enforcement is much more interested in whether a capability is exercised than if a capability exists. Checking the keyserver network reveals the capability; it doesn't reveal if it's been exercised. As a result, the possibility of law-enforcement officers checking the keyserver network doesn't seem to be a strong argument against the use of the keyserver network. The major exception is if you live in a jurisdiction where possession of crypto is itself a criminal offense. If you live in Cuba and you're using GnuPG, then you should not have your key on the servers and you have a perfectly reasonable fear about people uploading your key there. > In any event, Rob, could you do me a huge favor and clarify what > statement you are trying to make here? Jumping into a mail thread > late is always fraught with misunderstanding, but, I've re-skimmed > the thread, and I'm honestly still not sure what you're trying to > say. His position seems to have shifted. At some points he's said, "What's not to agree with in my statement that not everybody wants to put their keys on the keyservers?" I fully agree with this. However, he also seems to be advocating the advice of "generally speaking, it's a good idea to put keys on the keyservers" be changed to "generally speaking, it's not a good idea to share public keys without the key owner's explicit permission." This is a pretty big change in the conventional wisdom. Before I'll sign on to that I'll have to see some strong reasoning, and I haven't. > It seems (and I could be utterly wrong), that MFPA is saying "Not > everyone wants their key on the keyservers, so please don't > automatically send other people's keys there. If the key owner > wants the key on the keyservers, he'll send it himself." MFPA has made it clear his objection applies to any kind of sharing of public keys without the owner's consent. It's not limited to the keyserver network. He considers it the equivalent of passing on someone's home address to a complete stranger. ("I would no more deliberately publish somebody's key without their consent than I would pass on their phone number or address.") For myself, I do not send keys up to servers without first checking it with the recipient. This seems like good manners to me. However, I don't view it as mandatory and I don't think we should view it as the appalling breach of morality that MFPA seems to. > "This is not based on good logic as I see it, and therefore.... > (something)." What's the "(something)"? That the status quo ante is upheld. Status quo ante being, "the keyservers are generally a good idea, and generally speaking they should be used, and people should expect their public keys will wind up on them sooner or later, either through their direct action or through the accidents of others." It is not universally applicable advice, but I think that as far as general advice goes it's pretty good. From mailing-lists-mmvi at bretschneidernet.de Sat Feb 27 17:29:16 2010 From: mailing-lists-mmvi at bretschneidernet.de (Martin Bretschneider) Date: Sat, 27 Feb 2010 17:29:16 +0100 Subject: key generation: email-address necessary? In-Reply-To: References: Message-ID: <201002271729.16452.mailing-lists-mmvi@bretschneidernet.de> Am Samstag 27 Februar 2010 schrieb Laurent Jumet: > Hello Martin ! > > Martin Bretschneider wrote: > >> You can use whatever you want to identify your key. > >> But in some cases, mail programs expect to find your e-mail. > > > > that was my expectation as well. But what do the email clients do > > then? Do they say "no key available" or do the look for the name? > > What are your experiences? > > They can call another key with a similar name. :-) > > It's not easy to answer that question, as it depends on your own > system. When you read a signed message, GPG provides a way to call > automatically the sender's public key on your designed servers, when > it doesn't find it in your PubRing; it goes on the Net, retrieves > the key, incorporates it in your KeyRing and than verifyes the > signature on the message. This process can abort if ID's doesn't > match. I know that it depends on the system; this is why I wrote the email since I think that here are people that know GnuPG in combination with several email clients... Let's break down the problem: A and B have public keys on some keyserver. A has no email address in his public key, B does. AFAIK there are these four use cases concering emails and OpenPGP: 1: A sends a signed email to B. 2: A sends a (signed and) encrypted email to B. 3: B sends a signed email to A. 4: B sends a (signed and) encrypted email to A. Use case 1 and 2 should be no problem. Based on the key information saved in the signature the email client of B should get the public key of A. The email adress does not matter. Use case 3 should also be no problem since it does not deals with A public key. Use case 4 is the problematic one, B's email client does not know anything about A. B's email client could search for A fore- and surename on a keyserver... What do you think? TIA Martin -- http://www.bretschneidernet.de/ OpenPGP-key: 0x4EA52583 _o)(o_ Sallust: -./\\//\.- Nam idem velle atque idem _\_VV_/_ nolle, ea demum firma amicitia est. From kgo at grant-olson.net Sat Feb 27 18:38:25 2010 From: kgo at grant-olson.net (Grant Olson) Date: Sat, 27 Feb 2010 12:38:25 -0500 Subject: key generation: email-address necessary? In-Reply-To: <201002271150.13492.mailing-lists-mmvi@bretschneidernet.de> References: <201002271150.13492.mailing-lists-mmvi@bretschneidernet.de> Message-ID: <4B895891.1040205@grant-olson.net> On 2/27/2010 5:50 AM, Martin Bretschneider wrote: > > that was my expectation as well. But what do the email clients do then? > Do they say "no key available" or do the look for the name? What are > your experiences? > > TIA Martin Enigmail will lookup the key by key ID (0xDEADBEEF) when you tell it to retrieve the public key. So that will work. When you send someone an encrypted email and it doesn't match an email address from the key-ring, it will prompt you to select which key you want to use for that user for encryption. Pretty painless. Not sure what other clients do. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From laurent.jumet at skynet.be Sat Feb 27 18:44:34 2010 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Sat, 27 Feb 2010 18:44:34 +0100 Subject: key generation: email-address necessary? In-Reply-To: <201002271729.16452.mailing-lists-mmvi@bretschneidernet.de> Message-ID: Hello Martin ! Martin Bretschneider wrote: >> It's not easy to answer that question, as it depends on your own >> system. When you read a signed message, GPG provides a way to call >> automatically the sender's public key on your designed servers, when >> it doesn't find it in your PubRing; it goes on the Net, retrieves >> the key, incorporates it in your KeyRing and than verifyes the >> signature on the message. This process can abort if ID's doesn't >> match. > Let's break down the problem: A and B have public keys on some > keyserver. A has no email address in his public key, B does. I didn't test all events. I only noticed that in some cases, the e-mailer fails, or GPG fails, in getting the right key. Anyway, if this happens, you can examine manually the message and get manually the key. -- Laurent Jumet KeyID: 0xCFAF704C From kloecker at kde.org Sat Feb 27 19:20:33 2010 From: kloecker at kde.org (Ingo =?iso-8859-1?q?Kl=F6cker?=) Date: Sat, 27 Feb 2010 19:20:33 +0100 Subject: key generation: email-address necessary? In-Reply-To: <201002271150.13492.mailing-lists-mmvi@bretschneidernet.de> References: <201002271150.13492.mailing-lists-mmvi@bretschneidernet.de> Message-ID: <201002271921.04181@thufir.ingo-kloecker.de> On Saturday 27 February 2010, Martin Bretschneider wrote: > Am Samstag 27 Februar 2010 schrieb Laurent Jumet: > > Hi Laurent, > > > Martin Bretschneider wrote: > > > I want to recreate my GnuPG keys. My question is if I can omit > > > the email address? Since I do not want my email addresses to > > > appear on the keyservers because of spammers and so on. I only > > > want to put my name and maybe my toplevel domain in the comment > > > field. > > > Is the some kind of problem with this behavoir? Can email clients > > > find out what key to use if there is no known email address? > > > What do you think? > > > > > You can use whatever you want to identify your key. > > But in some cases, mail programs expect to find your e-mail. > > that was my expectation as well. But what do the email clients do > then? Do they say "no key available" or do the look for the name? > What are your experiences? When you want to send an encrypted messages with KMail/Kontact then KMail/Kontact first checks whether there is a key specified in the address book. If the address book entry does not specify a key then KMail/Kontact tries to look up the keys based on the email addresses. If it does not find keys for all recipients then it shows a dialog were you can specify which keys to use. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From expires2010 at ymail.com Sat Feb 27 20:21:06 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 27 Feb 2010 19:21:06 +0000 Subject: key question In-Reply-To: <4B88B791.7000100@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> Message-ID: <753752138.20100227192106@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 27 February 2010 at 6:11:29 AM, in , Robert J. Hansen wrote: > There is a perceived need for $150 bowls of soup, as > evidenced by dozens of high-priced gourmet restaurants > in major cities. The existence of a market for a > service is not evidence that the service is generally > useful or needed. Point taken. >> In any case, I've never seen a convincing argument >> *for* including email addresses in the UID of a PGP >> key. > First, the status quo doesn't need arguments in its > favor. The status quo exists. *Changing* the status > quo is what requires arguments in its favor. I have always been taught to challenge the status quo. "Because that's the way we do it" is *never* a good reason to continue doing something in a particular way. I understand that showing your email address in the UID makes it easier for people to find your key, the perceived advantage being that this makes it more likely you will receive encrypted mail. My contention is that the de facto standard of revealing email addresses in key UIDs could actually be mitigating *against* the use of encrypted mail, by discouraging people from publishing keys or even from using openPGP in the first place. There is a widespread perception (rightly or wrongly) that exposing your email address publicly on the internet will lead to that email address being spammed into oblivion. The new openPGP user is exhorted to create a key pair using their name and email address as the UID, and to upload this key to a server. That advice, coupled with the default configuration's enforcement of including an email address (or something that appears to be one) clearly has the potential to scare potential users from experimenting with openPGP in the first place. > Second, then you don't have to include it in yours. > Why are you bringing this up? Because you suggested in an earlier post in this thread that it was somehow acceptable to publish somebody's key to a server without their consent. To me, wantonly publishing other people's contact details appears contrary to the desire to protect personal privacy. > I don't care what your > UID is, and I don't want you to have a vote in whether > I put an email address in mine. I don't want such a vote. Whether somebody chooses to include an email address in their UID is up to the individual. I have not seen anything that convinces me it is better for me to include one. >> If their key lived at their own website or on an email >> responder, for example, you could still do this - >> except the note of the fingerprint and key-id would >> also need to contain a URL. > In which case you're still hosting it publicly, so why > not use the keyservers? Because by hosting it yourself, you have control over what signatures and UIDs appear on the published key. Or is that just an illusion? >> OK OK, the post I was replying to when I started this >> stated "It is also a good idea to send your key to >> the keyservers." I do not see this statement as any >> kind of self-evident truth, yet I have been >> thoroughly taken to task for questioning it. > This is not "taking you to task." This is listening to > your claims, and giving strong arguments against them. Many of the replies I've read in this thread have that character. Others have tended more towards criticising me for holding a different opinion and/or dismissing anything I said. Maybe I'm just being over-sensitive, but I got the impression I had touched some raw nerves somewhere along the way. > That said, it is broadly true that it's a good idea to > send keys to the keyserver network. The reasons why > have already been well-explained. Your reasons why not > are either unfounded or debunked. The collective response on this thread has indeed debunked a few myths for me. The main issue I'll never be converted on is the potential privacy problem of publishing somebody else's key to the servers. > In your voluminous defense of privacy rights, you've > not given any numbers for what fraction of users need > or want to keep their public keys private. If you're > arguing that the "good idea" we've advocated is not a > good idea, you need to show there are substantial > numbers of users who will be negatively impacted. You > haven't. If I was able to show that, those who need/want such privacy would be making a poor job of trying to enforce it. I don't care how many users this affects. For me, what matters is that any key I encounter *could* relate to one of them. Whoever's details may on a key (or in the body of an email, or anywhere else), I have no business publishing them. > You've talked about the danger of reputation being > slandered by implication of association: but as David > Shaw has pointed out, if someone wants to do that there > are much easier ways to do it than with keys. True. I only mentioned it because a contact experienced business problems as a result of this. > You've talked about making it easy for law enforcement > to learn who communicates securely with whom: but as > I've said, law enforcement (at least in the US, and > probably also the UK) has much easier ways to learn > this. Echelon. Records from ISPs. Traffic analysis... > You've talked about spam Spam was one of my initial concerns, so I created a key containing my name and a real email address that I actually do use. That key has sat at BigLumber for over 5 years and on the keyservers for about three years. That address generally attracts 2-3 spam messages a month. The only messages encrypted to that key have been when I requested Login tokens from BigLumber. > The status quo is, "it is generally a good idea to send > your key to the keyserver network." That is a very different statement to the one you made a few lines up; changing "keys" to "your key" resolves the privacy problem of exposing other people's contact details. > If you want to change that, the burden is on you to present > persuasive evidence supporting a change. So far I've not > seen it, which means the status quo stands. I think that rather than just bald exhortation to use the keyservers, people could usefully be pointed to a discussion of the pros and cons so that they can make an informed choice. I would also welcome an end to the presumption that people will want to include their email address in their UID. - -- Best regards MFPA mailto:expires2010 at ymail.com Reality is nothing but a collective hunch. -----BEGIN PGP SIGNATURE----- iQCVAwUBS4lwraipC46tDG5pAQoB3QQAnRVJg+c1iw315vOMc+8v2FcUFrcPyN7o SjbKN1cgbc//OlAgKDmpxvcwe0UHM/ke+2C1NVJlpdrvZ6OTnUzLFdYRqKgHiYDq R9+8TjdJVzeAFT7ecFo/vtu/q97N7AzjTYf/tGMDvT73lZRM9a1L+w3teqz+Oe68 sDfvuzzFIV4= =PCLd -----END PGP SIGNATURE----- From dougb at dougbarton.us Sat Feb 27 20:21:47 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 27 Feb 2010 11:21:47 -0800 Subject: key generation: email-address necessary? In-Reply-To: <201002261934.28476.mailing-lists-mmvi@bretschneidernet.de> References: <201002261934.28476.mailing-lists-mmvi@bretschneidernet.de> Message-ID: <4B8970CB.2000805@dougbarton.us> On 02/26/10 10:34, Martin Bretschneider wrote: > Hi, > > I want to recreate my GnuPG keys. My question is if I can omit the email > address? Since I do not want my email addresses to appear on the > keyservers because of spammers and so on. 1. It's been repeated many times on the list that those who have investigated the issue have determined that the amount of spam to addresses harvested from keyservers is negligible at worst. 2. You're far more likely to get spam to an address by using it to post to a public mailing list. 3. The whole idea of taking any kind of steps to hide your address from spammers has been overtaken by events. They will get your address. They will send you spam. That's just how the world works now, and pretending that you can do anything about it by "hiding" your e-mail address is just foolishness. 4. The proper place to deal with spam is on the receiving end. First your mail server, and second your MUA. "Smart clients" like Thunderbird have built in spam fighting. Unix command line tools have access to things like bogofilter. 5. And finally something germane to the list, the amount of trouble you will cause for yourself and others by omitting your e-mail address will far exceed any benefit you may get from "hiding" your address from the spammers. hope this helps, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dshaw at jabberwocky.com Sat Feb 27 21:02:54 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 27 Feb 2010 15:02:54 -0500 Subject: key question In-Reply-To: <4B8946C3.5050607@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <4B8946C3.5050607@sixdemonbag.org> Message-ID: On Feb 27, 2010, at 11:22 AM, Robert J. Hansen wrote: > On 2/27/10 9:58 AM, David Shaw wrote: >> Do you really mean to suggest that a US authority getting email >> headers - even without a warrant - is easier than typing a name into >> a search box on a keyserver? > > No. You're right, that's clearly easier. However, that only tells you > whether someone has the technical capability to use encryption -- much > the same way that a shotgun in my closet tells you I have the technical > capability to commit murder. Much as the email headers do in your example. If the mail is not encrypted, the headers just show that it might be. In practice, headers won't show much as the majority of modern mail programs have the capability for encryption of one sort or another, even without add-ons. It's rarely exercised, of course. > As a result, the possibility of law-enforcement officers checking the > keyserver network doesn't seem to be a strong argument against the use > of the keyserver network. > > The major exception is if you live in a jurisdiction where possession of > crypto is itself a criminal offense. If you live in Cuba and you're > using GnuPG, then you should not have your key on the servers and you > have a perfectly reasonable fear about people uploading your key there. > >> In any event, Rob, could you do me a huge favor and clarify what >> statement you are trying to make here? Jumping into a mail thread >> late is always fraught with misunderstanding, but, I've re-skimmed >> the thread, and I'm honestly still not sure what you're trying to >> say. > > His position seems to have shifted. At some points he's said, > > "What's not to agree with in my statement that not everybody wants to > put their keys on the keyservers?" > > I fully agree with this. However, he also seems to be advocating the > advice of "generally speaking, it's a good idea to put keys on the > keyservers" be changed to "generally speaking, it's not a good idea to > share public keys without the key owner's explicit permission." > > This is a pretty big change in the conventional wisdom. Before I'll > sign on to that I'll have to see some strong reasoning, and I haven't. I agree that "generally speaking, it's a good idea to put keys on the keyservers". I don't know if that makes it conventional wisdom, or who the arbiter of such wisdom might be, but clearly a very common use of OpenPGP is for encrypted mail. If you want encrypted mail, putting your key on a keyserver is very helpful in reaching that goal. The word "generally" takes care of the exceptions (as there always exceptions for one reason or another). So basically, yes, if you're using OpenPGP, keyservers are great. With regards to the second statement, you give a great reason yourself a few paragraphs up: "If you live in Cuba and you're using GnuPG, then you should not have your key on the servers and you have a perfectly reasonable fear about people uploading your key there". Is that not a good reason to request that a key stay off the keyservers? I don't find the behavior *behind* this reason very good, as if someone lived in a place where encryption was banned, they'd be foolish and naive to think that their key would stay off the keyservers merely because they requested it - one accident, and it's published, and no way to withdraw it. People who live in places where encryption is illegal need to do a lot more than simply not send their keys to a keyserver if they want to remain safe. Personally, I don't find most don't-publish arguments (spam, traffic analysis, etc) compelling, and I correspondingly do send my key to the keyservers (in my case, it would be particularly silly not to). However, I never send anything to the keyservers (or publish otherwise) if it isn't mine. I don't know what their situation is, and it's not up to me to decide it for them. Even if I did know their situation, as in the Cuba example above, and disagreed with them on how to handle their key, it still is not my key, and not my decision to make. I don't know if that makes it conventional wisdom, but I have acted that way since I became involved in the OpenPGP world many years ago. Whether it's wise or not, I'd at least hope it's common politeness. Keys ending up on keyservers contrary to the desires of the key owner has been a problem for a long time. Note the addition of the no-modify flag when OpenPGP was first published as an RFC in 1998. That was added after experience with PGP 2. The whole point of that flag is to only allow the owner to publish their key. Similarly, note that the PGP Global Directory only allows key uploads from the key owner, avoiding this problem. The earlier PGP "certserver" had the capability, though I don't believe it was always turned on. Clearly this is enough of a problem that work was done to avoid it. > For myself, I do not send keys up to servers without first checking it > with the recipient. This seems like good manners to me. However, I > don't view it as mandatory and I don't think we should view it as the > appalling breach of morality that MFPA seems to. So you are saying "I do not do this". And MFPA is saying "I think nobody should do this" ? Where's the problem? From where I'm standing, that looks like something that passes for rough agreement, or - dare I say it - conventional wisdom. ;) David From rjh at sixdemonbag.org Sat Feb 27 21:03:15 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 27 Feb 2010 15:03:15 -0500 Subject: key question In-Reply-To: <753752138.20100227192106@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> Message-ID: <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> On Feb 27, 2010, at 2:21 PM, MFPA wrote: > I have always been taught to challenge the status quo. "Because that's > the way we do it" is *never* a good reason to continue doing something > in a particular way. The status quo has something going for it: it works. 95% of all new ideas are awful and should be discarded. New ideas are how the status quo changes for the better, but that doesn't mean we should throw out the status quo just because an idea comes along which happens to be new. > My > contention is that the de facto standard of revealing email addresses > in key UIDs could actually be mitigating *against* the use of > encrypted mail, by discouraging people from publishing keys or even > from using openPGP in the first place. It's an interesting idea, but I don't see any facts to back it up. How many users are dissuaded? Is this a major concern, or not a concern? What does the published literature say about it? And so on, and so on. Speculation is great, but speculation isn't fact -- and we need to change the way we do things based on facts, not on speculations. We can agree on facts, but our speculations will likely not overlap very much at all. > That advice, coupled with the > default configuration's enforcement of including an email address (or > something that appears to be one) clearly has the potential to scare > potential users from experimenting with openPGP in the first place. The same way the shotgun in my closet clearly has the potential to be used as a murder weapon. Potential != actuality. All manner of potential things do not come to pass. Before we change the way we do business, I'd like to know that we're changing to address a real problem, not merely a potential problem where no one really knows if it's a real problem or not. The world has enough interesting problems to solve without us having to go off chasing ghosts. > Because you suggested in an earlier post in this thread that it was > somehow acceptable to publish somebody's key to a server without their > consent. I don't think I said it was "acceptable." I would find it to be in poor taste, myself, if it were done deliberately. However, I don't think it would amount to a moral or ethical failing. > Because by hosting it yourself, you have control over what signatures > and UIDs appear on the published key. Or is that just an illusion? Illusion. Let's say that Joe downloads your key from the web page. Joe then syncs his entire keyring with the keyserver. (This is a feature in PGP; you can also do the same thing with GnuPG, if you don't mind getting a little crazy with awk and sed scripts.) Your key then gets on the server, and... etc. Maybe Joe is doing it deliberately. Maybe he has a misconfigured installation. Maybe he thinks he's doing you a favor. Whatever. The point is, the world is full of Joes, and sooner or later your key will wind up on the server. Once you make any public release of your key, it is only a matter of time until that key winds up on the keyserver network. You can either keep your public key very secret and only give it to people who have need-to-know and make them sign a nondisclosure agreement written in the blood of their children, or you can accept the fact that it will be put on the keyserver and take appropriate steps. > The collective response on this thread has indeed debunked a few myths > for me. The main issue I'll never be converted on is the potential > privacy problem of publishing somebody else's key to the servers. This is an argument from emotional conviction. That doesn't mean it's invalid or inappropriate or that you shouldn't have this response -- don't get me wrong. I like emotions; emotions are pretty cool things. I just don't like arguing from emotional conviction, because I either share in the response or I don't. If I do, then you don't need to say anything because I'm already on your side. If I don't, then you don't need to say anything because you can't persuade me into having that particular emotional response. I either have it or I don't. But just like there's nothing you can say to *me*, there's nothing I can say to *you*. The instant you say "I will never be converted!", well, okay: thanks for letting me know. I won't try to persuade you, because you've made it clear you won't be persuaded. > If I was able to show that, those who need/want such privacy would be > making a poor job of trying to enforce it. So the lack of evidence is, itself, evidence? That sounds more like a conspiracy theory. > I don't care how many users > this affects. For me, what matters is that any key I encounter *could* > relate to one of them. This is an idealistic view of the world. I like idealism. I admire idealism. I just think it's impractical and destructive. What you're saying here is, "even if the advice were sound for one million users, and destructive to the privacy of just one, I still would not change because any key I encounter could be that one." The perfect is the enemy of the good. From rjh at sixdemonbag.org Sat Feb 27 21:23:25 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 27 Feb 2010 15:23:25 -0500 Subject: key question In-Reply-To: References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <4B8946C3.5050607@sixdemonbag.org> Message-ID: On Feb 27, 2010, at 3:02 PM, David Shaw wrote: > Much as the email headers do in your example. If the mail is not encrypted, the headers just show that it might be. In practice, headers won't show much as the majority of modern mail programs have the capability for encryption of one sort or another, even without add-ons. It's rarely exercised, of course. Yes and no. I think the presence of an Enigmail header, for instance, is probably more indicative of encrypted traffic than just someone's key being present on a server. Still, this is kind of a side show. What started this was MFPA's contention that just by having your key on the keyserver network you could be bringing yourself to the attention of government investigators. When a murder victim is found, the police start looking for the murder weapon. They don't start by looking at all possible murder weapons and hope to find a murder victim nearby. Likewise, if the police find encrypted traffic on a suspect's laptop they will begin to search for the originator of the traffic. They're not likely to start by rounding up the usual suspects found by harvesting the key server. There are exceptions to this rule. I mentioned Cuba, where possession of crypto is itself a crime (or was, last I heard: if there are any Cubans on the list, I would love to know if this is still true). That said, exceptions to a rule are expected -- there are few rules so general they do not admit exceptions. > I agree that "generally speaking, it's a good idea to put keys on the keyservers". I don't know if that makes it conventional wisdom, or who the arbiter of such wisdom might be, but clearly a very common use of OpenPGP is for encrypted mail. I likewise have suspicions and doubts about conventional wisdom. (You could just as easily say, "conventional wisdom is that you can tell a lot about someone by the signatures on their key" -- I can see an argument being made for that being conventional wisdom. It's *wrong*, but that doesn't keep it from being conventional wisdom.) However, on the scale of conventional wisdom, where on one end there's "never get involved in a land war in Asia" and "never go against a Sicilian when death is on the line," [1] and on the other there's "the signatures on a key tell you a lot about a person", I think the conventional wisdom of "generally speaking, it's a good idea to put keys on the keyservers" is closer to the former category than the latter. :) Admittedly, I am no arbiter of what's conventional wisdom. The preceding is just my own personal interpretation of what prevailing CW is. [1] http://www.imdb.com/title/tt0093779/quotes > With regards to the second statement, you give a great reason yourself a few paragraphs up: "If you live in Cuba and you're using GnuPG, then you should not have your key on the servers and you have a perfectly reasonable fear about people uploading your key there". Is that not a good reason to request that a key stay off the keyservers? I think it's a great example of a clear exception to a general rule. > So you are saying "I do not do this". And MFPA is saying "I think nobody should do this" ? Not really. That's a side issue. The real question is this: "The status quo is that new users are routinely told, 'generally speaking, it is a good idea to upload your key to the keyservers.' Does this need to change?" > Where's the problem? He says "yes and here's why," and I say, "your arguments do not appear sound, and here's why." From expires2010 at ymail.com Sat Feb 27 21:39:57 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 27 Feb 2010 20:39:57 +0000 Subject: key question In-Reply-To: <4B8946C3.5050607@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <4B8946C3.5050607@sixdemonbag.org> Message-ID: <1305648811.20100227203957@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 27 February 2010 at 4:22:27 PM, in , Robert J. Hansen wrote: > His position seems to have shifted. As the thread has progressed, the posts I'm replying to have shifted from "It is a good idea to send your key to the keyservers," to an assertion that it's also a good idea to publish other people's keys whether they want them published or not. > At some points he's said, > "What's not to agree with in my statement that not > everybody wants to put their keys on the keyservers?" > I fully agree with this. However, he also seems to be > advocating the advice of "generally speaking, it's a > good idea to put keys on the keyservers" be changed to > "generally speaking, it's not a good idea to share > public keys without the key owner's explicit > permission." > This is a pretty big change in the conventional wisdom. > Before I'll sign on to that I'll have to see some > strong reasoning, and I haven't. >> It seems (and I could be utterly wrong), that MFPA is >> saying "Not everyone wants their key on the >> keyservers, so please don't automatically send other >> people's keys there. If the key owner wants the key >> on the keyservers, he'll send it himself." That is exactly what I am saying. Most peoples keys contain personal contact details and the decision to place that information in the public domain rests solely with the person whose details they are. > MFPA has made it clear his objection applies to any > kind of sharing of public keys without the owner's > consent. It's not limited to the keyserver network. > He considers it the equivalent of passing on someone's > home address to a complete stranger. ("I would no more > deliberately publish somebody's key without their > consent than I would pass on their phone number or > address.") Pretty much, yes. Not forgetting the possible legal implications under data protection legislation in the EU and other places. > "the keyservers are generally a good idea, and > generally speaking they should be used, and people > should expect their public keys will wind up on them > sooner or later, either through their direct action or > through the accidents of others." > It is not universally applicable advice, but I think > that as far as general advice goes it's pretty good. I don't think it is bad advice when put like that. Maybe the person being advised could be pointed to a summary discussion of pros and cons, and of alternatives to keyservers - but that would probably be information overload. It is definitely good advice to bear in mind that your key may well end up on a keyserver whether you want it to or not. That will feed into the decision of what information to include in your UIDs. I find the attitude that it is OK to publicise somebody else's details without consent abhorrent, and suggestive of a disregard for other people's privacy. Given the importance of personal privacy, it seems to me that it's too easy to accidentally upload the wrong key to a server. I'm not sure if anything could usefully be changed to address this; even if people read confirmations before pressing "y" when using GnuPG, such mistakes are all-too-easy in other packages and front-ends as well. - -- Best regards MFPA mailto:expires2010 at ymail.com The problem is not that we're paranoid; it's that we're not paranoid enough. -----BEGIN PGP SIGNATURE----- iQCVAwUBS4mDJqipC46tDG5pAQoYzgP/WP6E+qDRzfdwTVCXrcvXgONsVvXhCAQ8 3FJVYb/TeoLVcm26J88IBQvhECsoI+4RBcMgRVBwXTn0KU8E5PUF+4Or5d3NpuNp RkmuPPOlNUfj6xqMRkylm5pe9kYI8UvDnEGlEOy0XonDJ1Mfq/4aZHpJvy5NHmaK P+aRJ+1cjaE= =NiBO -----END PGP SIGNATURE----- From expires2010 at ymail.com Sat Feb 27 21:51:45 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 27 Feb 2010 20:51:45 +0000 Subject: key generation: email-address necessary? In-Reply-To: <201002271150.13492.mailing-lists-mmvi@bretschneidernet.de> References: <201002271150.13492.mailing-lists-mmvi@bretschneidernet.de> Message-ID: <1528580523.20100227205145@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Martin On Saturday 27 February 2010 at 10:50:13 AM, you wrote: > that was my expectation as well. But what do the email clients do then? > Do they say "no key available" or do the look for the name? What are > your experiences? I use The Bat! which matches on email address only. If there is more than one match, earlier versions of The Bat! pick one to use whilst later versions allow the user to choose. If there is no match, the encryption fails. This can be overcome by creating a group in gpg.conf, named as the email address and containing the key ID for that email address. - -- Best regards MFPA mailto:expires2010 at ymail.com Change is inevitable except from a vending machine -----BEGIN PGP SIGNATURE----- iQCVAwUBS4mF6KipC46tDG5pAQrg3wQAq7tFOvu5NpAhVtrVIyfUjmwN1Sa6Cz8l IMQMf/3mDlyih7iQ92mU6+JXT4HzDx3YHgWsfxgqPJio+qha1oVxiPIovFH5BD+w rBbNDXzTe+UXEQa7Xn0rzQjCO2oHM5g4O/cwVoP12Qpi22sn0v9WSKf/KrA5sb7Z U0tTBK1YJQo= =yq0L -----END PGP SIGNATURE----- From expires2010 at ymail.com Sat Feb 27 22:03:44 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 27 Feb 2010 21:03:44 +0000 Subject: key question In-Reply-To: References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <4B8946C3.5050607@sixdemonbag.org> Message-ID: <1276454148.20100227210344@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Robert On Saturday 27 February 2010 at 8:23:25 PM, you wrote: > On Feb 27, 2010, at 3:02 PM, David Shaw wrote: >> With regards to the second statement, you give a great reason >> yourself a few paragraphs up: "If you live in Cuba and you're using >> GnuPG, then you should not have your key on the servers and you >> have a perfectly reasonable fear about people uploading your key >> there". Is that not a good reason to request that a key stay off >> the keyservers? > I think it's a great example of a clear exception to a general rule. And whist you have stated that you check first, you have advocated that it's OK not to. Somebody following your advice could land this hypothetical Cuban in a whole lot of trouble. - -- Best regards MFPA mailto:expires2010 at ymail.com Don't ask me, I'm making this up as I go! -----BEGIN PGP SIGNATURE----- iQCVAwUBS4mIuKipC46tDG5pAQqD9AQAs+WD9zZdoAg2H0brYrqFqzOq8jrqqtVP 3KXfJiHfBD37V95yK5J1APLUjVpjZ3hxmepxcNn1YBIVKZafEkejBZNKsKWhWOeZ 0y4vH0hJWN+zFhxfv2DJZ4aBvAWSJnWZHigoca71qkFxU4M05IWUG1Wwm8d7nzC2 0GwLiicbx2c= =gl+x -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sat Feb 27 22:10:19 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 27 Feb 2010 16:10:19 -0500 Subject: key question In-Reply-To: <1276454148.20100227210344@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <4B8946C3.5050607@sixdemonbag.org> <1276454148.20100227210344@my_localhost> Message-ID: <8DDC5DE2-C0B1-4E91-BC03-520419192436@sixdemonbag.org> > And whist you have stated that you check first, you have advocated > that it's OK not to. Somebody following your advice could land this > hypothetical Cuban in a whole lot of trouble. The hypothetical Cuban had a lot bigger problems the instant he shared his public key with people he shouldn't have trusted to keep it secret. Keep it on the list, please, and not in private mail. From rjh at sixdemonbag.org Sat Feb 27 22:16:14 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 27 Feb 2010 16:16:14 -0500 Subject: key question In-Reply-To: <8DDC5DE2-C0B1-4E91-BC03-520419192436@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <4B8946C3.5050607@sixdemonbag.org> <1276454148.20100227210344@my_localhost> <8DDC5DE2-C0B1-4E91-BC03-520419192436@sixdemonbag.org> Message-ID: On Feb 27, 2010, at 4:10 PM, Robert J. Hansen wrote: > Keep it on the list, please, and not in private mail. Oh, ack. I completely misread the To- line, and didn't see the cc: to gnupg-users. My error, and my apologies to MFPA. :) From expires2010 at ymail.com Sat Feb 27 22:28:18 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 27 Feb 2010 21:28:18 +0000 Subject: OFF LIST In-Reply-To: <4B891E32.7010504@mac.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20100227062517.6c5ac5d8@scorpio.seibercom.net> <4B891E32.7010504@mac.com> Message-ID: <418213655.20100227212818@my_localhost> Hi Charly On Saturday 27 February 2010 at 1:29:22 PM, you wrote: > I have also e-mailed Faramir directly, trying to have news. Farimir has just posted on PGPNET that he is fine, his house resisted the quake, his family are OK. Phones down so he has been unable to contact some friends. -- Best regards MFPA mailto:expires2010 at ymail.com Reality is nothing but a collective hunch. From kgo at grant-olson.net Sat Feb 27 22:54:56 2010 From: kgo at grant-olson.net (Grant Olson) Date: Sat, 27 Feb 2010 16:54:56 -0500 Subject: Fwd: Re: key question Message-ID: <4B8994B0.8010009@grant-olson.net> Doh! Originally sent off list... Maybe Robert got a psychic vibe... On 2/27/2010 2:21 PM, MFPA wrote: > > I don't want such a vote. Whether somebody chooses to include an email > address in their UID is up to the individual. I have not seen anything > that convinces me it is better for me to include one. > > It sounds like you're using the software to do the opposite thing that many people do. I think digital signatures are utilized much more than encrypted communication. And digital signatures are about authenticating to a real person, and not anonymity. If you don't want to publish your email for the anonymity/privacy reasons you've outlined, then you probably don't want to use your legal name either. And it looks like you don't. Which is fine for encrypting documents. But it renders two key features of digital signatures meaningless. Authentication and Non-repudiation go out the window. How do I authenticate that an anonymous entity is really an anonymous entity? That doesn't make any sense. How do I get into a dispute with an anonymous entity about whether he really agreed to do X? And although it does prove message integrity, that, in and of itself, doesn't mean much for an anonymous entity. So a few examples to elaborate. I'm going to use MFPA as the anonymous user who doesn't have a real ID for clarity sake. It's better than "anonymous entity". Just to be clear, I'm not really talking about you or making any personal attacks in the examples. You're just the generic guy with the non-identifiable key. Farfetched example. An email from MFPA pops up on the list. "My house burnt down. Lost my key. Lost my rev certificate. Here's my new info." Five minutes later, another email from MFPA. "That dude generated a fake key. Keep using the old one. The new one is bad!" A third email from MFPA. "That last dude is lying. Turns out he stole my laptop before burning my house down." Who do we trust? Which key do we use? We have no way of knowing who the real MFPA is, because he was anonymous to begin with. How could I sign your key? It sounds like you don't want anyone to sign it anyway, plenty of other people want to sign keys and build the web of trust. I can't verify your key in any way. You're anonymous. There's no way to prove you're MFPA. So I can't sign your key. Lets assume among your circle of friends, who know each other personally in real life, you sign off on each others keys. And I somehow know one of your friends, and we sign each others keys. To me, it's a meaningless assertion for someone to claim that they've verified that you're the real MFPA. That doesn't mean anything to me because you're anonymous to me. It also doesn't mean anything if you've signed off on someone's key. What does it mean to me that MFPA vouched for someone else's identity? Another meaningless assertion. I'm not really using OpenPGP encryption at all. I may never need to send an encrypted email. None of my real-life friends, family, co-workers use it. Not Cuban, Iranian, or in the Falun Gong. I use it for two things, (1) to post on computer geek mailing lists, and (2) to verify software packages. For (1), I guess I'm not too concerned about digital signatures. The PGP Global Directory is good enough authentication for me. For (2), I actually am. It'd be nice to have the software packages signed by a validated key. If people don't use personally identifying information, the web of trust breaks. The only way for me to actually validate a key is to meet with the software packager personally. And I think many people fall into that camp. Authentication is more important to them than anonymity and encryption. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From John at Mozilla-Enigmail.org Sun Feb 28 00:09:08 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Sat, 27 Feb 2010 17:09:08 -0600 Subject: key question In-Reply-To: <753752138.20100227192106@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> Message-ID: <4B89A614.8030901@Mozilla-Enigmail.org> This may be a dup - I think the original went out with the wrong From addr MFPA wrote: > Hi > On Saturday 27 February 2010 at 6:11:29 AM, in > , Robert J. Hansen wrote: >>> In any case, I've never seen a convincing argument *for* including email >>> addresses in the UID of a PGP key. Nor have we seen compelling arguments for their omission as a general rule >> First, the status quo doesn't need arguments in its favor. The status quo >> exists. *Changing* the status quo is what requires arguments in its >> favor. > > I have always been taught to challenge the status quo. "Because that's the > way we do it" is *never* a good reason to continue doing something in a > particular way. It is never a good reason when it is the sole justification. It's a perfectly valid reason when it has evolved from the ideas of a lot of Very Smart People?. > I understand that showing your email address in the UID makes it easier for > people to find your key, the perceived advantage being that this makes it > more likely you will receive encrypted mail. My contention is that the de > facto standard of revealing email addresses in key UIDs could actually be > mitigating *against* the use of encrypted mail, by discouraging people from > publishing keys or even from using openPGP in the first place. An /interesting/ thesis, However, to be taken seriously you need to back it up with more than conjecture. There are plenty of obstacles to the widespread use of encryption in the computing literature without grasping at straws to create more. > There is a widespread perception (rightly or wrongly) that exposing your > email address publicly on the internet will lead to that email address being > spammed into oblivion. The new openPGP user is exhorted to create a key pair > using their name and email address as the UID, and to upload this key to a > server. That advice, coupled with the default configuration's enforcement of > including an email address (or something that appears to be one) clearly has > the potential to scare potential users from experimenting with openPGP in the > first place. Widespread perception? Indeed? Please quantify. There are over 2.8 million keys on the SKS keyservers with an average of just under 350 new keys added every day.[0] The "keyserver SPAM" discussion surfaces maybe three to four times per year across three lists. Odds on users will get more SPAM from asking a question on a public mailing list such as this one than they will from that attributable to keyservers. "(rightly or wrongly)" Or imaginary? Rather than trying to convince us of new "obstacles" without providing any evidence, you may wish to review what the HCI folks say are the obstacles: "Why Johnny Can't Encrypt"[1], "Why Johnny Still Can't Encrypt"[2], "How to Make Secure Email Easier to Use"[3], and a personal favorite, "Secrecy, Flagging, and Paranoia: Adoption Criteria in Encrypted E-Mail"[4]. >>> If their key lived at their own website or on an email responder, for >>> example, you could still do this - except the note of the fingerprint and >>> key-id would also need to contain a URL. > >> In which case you're still hosting it publicly, so why not use the >> keyservers? > > Because by hosting it yourself, you have control over what signatures and > UIDs appear on the published key. Or is that just an illusion? Mostly Illusion. You only control the copy you publish or make available. You have control over what signatures appear /until/ someone else has a copy of the key. After that, you rely on their manners and ability to not make mistakes. >>> OK OK, the post I was replying to when I started this stated "It is also >>> a good idea to send your key to the keyservers." I do not see this >>> statement as any kind of self-evident truth, yet I have been thoroughly >>> taken to task for questioning it. > >> This is not "taking you to task." This is listening to your claims, and >> giving strong arguments against them. > > Many of the replies I've read in this thread have that character. Others have > tended more towards criticising me for holding a different opinion and/or > dismissing anything I said. Maybe I'm just being over-sensitive, but I got > the impression I had touched some raw nerves somewhere along the way. Many of the points you argue in this thread have been exhaustively discussed on the list. You could compare this to a novel reading of law taking on a mountain of precedent. It takes more than just the presentation of a case to convince this body. I've seen errant ideas criticized, not any person. The only irritant for me was a breach of email etiquette. >> That said, it is broadly true that it's a good idea to send keys to the >> keyserver network. The reasons why have already been well-explained. Your >> reasons why not are either unfounded or debunked. > > The collective response on this thread has indeed debunked a few myths for > me. The main issue I'll never be converted on is the potential privacy > problem of publishing somebody else's key to the servers. I think most of us agree that the publishing of another person's key(s) is mostly attributable to a) accident, or b) ignorance. I don't think malice normally is a factor. >> You've talked about spam > > Spam was one of my initial concerns, so I created a key containing my name > and a real email address that I actually do use. That key has sat at > BigLumber for over 5 years and on the keyservers for about three years. That > address generally attracts 2-3 spam messages a month. The only messages > encrypted to that key have been when I requested Login tokens from > BigLumber. This is partly due to the fact that it is more difficult to mine addresses from BigLumber. But you are only a factor of 4 or 5 away from what I measured due to keyserver SPAM five years ago. >> The status quo is, "it is generally a good idea to send your key to the >> keyserver network." > > That is a very different statement to the one you made a few lines up; > changing "keys" to "your key" resolves the privacy problem of exposing other > people's contact details. The original statement I made that started this entire discussion was, "> It is also a good idea to send your key to the keyservers." >> If you want to change that, the burden is on you to present persuasive >> evidence supporting a change. So far I've not seen it, which means the >> status quo stands. > > I think that rather than just bald exhortation to use the keyservers, people > could usefully be pointed to a discussion of the pros and cons so that they > can make an informed choice. I would also welcome an end to the presumption > that people will want to include their email address in their UID. IIRC, we do this in the Enigmail Handbook[5]. But I've been distracted with family issues as of late. "Bald exhortation"? Honestly? You paint it as much more vociferous language than it was. The pros and cons have been discussed, on this list, on the Enigmail list, on PGP-Basics, probably on PGPNet but I don't subscribe. (I guess I could ask a friend who's a member if I was curious enough.) -John [0] http://keyserver.gingerbear.net:11371/pks/lookup?op=stats [1] http://gaudior.net/alma/johnny.pdf [2] http://www.chariotsfire.com/pub/sheng-poster_abstract.pdf [3] http://groups.csail.mit.edu/uid/projects/secure-email/chi_smime.pdf [4] http://www.soe.ucsc.edu/classes/cmps223/Spring09/Gaw%2006.pdf [5] http://enigmail.mozdev.org/documentation/handbook.php -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at 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" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: From free10pro at gmail.com Sun Feb 28 00:19:43 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sat, 27 Feb 2010 15:19:43 -0800 Subject: key question In-Reply-To: <753752138.20100227192106@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> Message-ID: <1267312783.3824.21.camel@localhost> On Sat, 2010-02-27 at 19:21 +0000, MFPA wrote: > There is a widespread perception (rightly or wrongly) that exposing > your email address publicly on the internet will lead to that email > address being spammed into oblivion. The new openPGP user is exhorted > to create a key pair using their name and email address as the UID, > and to upload this key to a server. That advice, coupled with the > default configuration's enforcement of including an email address (or > something that appears to be one) clearly has the potential to scare > potential users from experimenting with openPGP in the first place. GnuPG doesn't, at least as of 1.4.10, force you to include an e-mail address in your user ID. It merely requests an e-mail address, and you can just press enter and ignore the request. From JPClizbe at tx.rr.com Sat Feb 27 23:21:20 2010 From: JPClizbe at tx.rr.com (John Clizbe) Date: Sat, 27 Feb 2010 16:21:20 -0600 Subject: key question In-Reply-To: <753752138.20100227192106@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> Message-ID: <4B899AE0.3050801@tx.rr.com> MFPA wrote: > Hi > On Saturday 27 February 2010 at 6:11:29 AM, in > , Robert J. Hansen wrote: >>> In any case, I've never seen a convincing argument *for* including email >>> addresses in the UID of a PGP key. Nor have we seen compelling arguments for their omission as a general rule >> First, the status quo doesn't need arguments in its favor. The status quo >> exists. *Changing* the status quo is what requires arguments in its >> favor. > > I have always been taught to challenge the status quo. "Because that's the > way we do it" is *never* a good reason to continue doing something in a > particular way. It is never a good reason when it is the sole justification. It's a perfectly valid reason when it has evolved from the ideas of a lot of Very Smart People?. > I understand that showing your email address in the UID makes it easier for > people to find your key, the perceived advantage being that this makes it > more likely you will receive encrypted mail. My contention is that the de > facto standard of revealing email addresses in key UIDs could actually be > mitigating *against* the use of encrypted mail, by discouraging people from > publishing keys or even from using openPGP in the first place. An /interesting/ thesis, However, to be taken seriously you need to back it up with more than conjecture. There are plenty of obstacles to the widespread use of encryption in the computing literature without grasping at straws to create more. > There is a widespread perception (rightly or wrongly) that exposing your > email address publicly on the internet will lead to that email address being > spammed into oblivion. The new openPGP user is exhorted to create a key pair > using their name and email address as the UID, and to upload this key to a > server. That advice, coupled with the default configuration's enforcement of > including an email address (or something that appears to be one) clearly has > the potential to scare potential users from experimenting with openPGP in the > first place. Widespread perception? Indeed? Please quantify. There are over 2.8 million keys on the SKS keyservers with an average of just under 350 new keys added every day.[0] The "keyserver SPAM" discussion surfaces maybe three to four times per year across three lists. Odds on users will get more SPAM from asking a question on a public mailing list such as this one than they will from that attributable to keyservers. "(rightly or wrongly)" Or imaginary? Rather than trying to convince us of new "obstacles" without providing any evidence, you may wish to review what the HCI folks say are the obstacles: "Why Johnny Can't Encrypt"[1], "Why Johnny Still Can't Encrypt"[2], "How to Make Secure Email Easier to Use"[3], and a personal favorite, "Secrecy, Flagging, and Paranoia: Adoption Criteria in Encrypted E-Mail"[4]. >>> If their key lived at their own website or on an email responder, for >>> example, you could still do this - except the note of the fingerprint and >>> key-id would also need to contain a URL. > >> In which case you're still hosting it publicly, so why not use the >> keyservers? > > Because by hosting it yourself, you have control over what signatures and > UIDs appear on the published key. Or is that just an illusion? Mostly Illusion. You only control the copy you publish or make available. You have control over what signatures appear /until/ someone else has a copy of the key. After that, you rely on their manners and ability to not make mistakes. >>> OK OK, the post I was replying to when I started this stated "It is also >>> a good idea to send your key to the keyservers." I do not see this >>> statement as any kind of self-evident truth, yet I have been thoroughly >>> taken to task for questioning it. > >> This is not "taking you to task." This is listening to your claims, and >> giving strong arguments against them. > > Many of the replies I've read in this thread have that character. Others have > tended more towards criticising me for holding a different opinion and/or > dismissing anything I said. Maybe I'm just being over-sensitive, but I got > the impression I had touched some raw nerves somewhere along the way. Many of the points you argue in this thread have been exhaustively discussed on the list. You could compare this to a novel reading of law taking on a mountain of precedent. It takes more than just the presentation of a case to convince this body. I've seen errant ideas criticized, not any person. The only irritant for me was a breach of email etiquette. >> That said, it is broadly true that it's a good idea to send keys to the >> keyserver network. The reasons why have already been well-explained. Your >> reasons why not are either unfounded or debunked. > > The collective response on this thread has indeed debunked a few myths for > me. The main issue I'll never be converted on is the potential privacy > problem of publishing somebody else's key to the servers. I think most of us agree that the publishing of another person's key(s) is mostly attributable to a) accident, or b) ignorance. I don't think malice normally is a factor. >> You've talked about spam > > Spam was one of my initial concerns, so I created a key containing my name > and a real email address that I actually do use. That key has sat at > BigLumber for over 5 years and on the keyservers for about three years. That > address generally attracts 2-3 spam messages a month. The only messages > encrypted to that key have been when I requested Login tokens from > BigLumber. This is partly due to the fact that it is more difficult to mine addresses from BigLumber. But you are only a factor of 4 or 5 away from what I measured due to keyserver SPAM five years ago. >> The status quo is, "it is generally a good idea to send your key to the >> keyserver network." > > That is a very different statement to the one you made a few lines up; > changing "keys" to "your key" resolves the privacy problem of exposing other > people's contact details. The original statement I made that started this entire discussion was, "> It is also a good idea to send your key to the keyservers." >> If you want to change that, the burden is on you to present persuasive >> evidence supporting a change. So far I've not seen it, which means the >> status quo stands. > > I think that rather than just bald exhortation to use the keyservers, people > could usefully be pointed to a discussion of the pros and cons so that they > can make an informed choice. I would also welcome an end to the presumption > that people will want to include their email address in their UID. IIRC, we do this in the Enigmail Handbook[5]. But I've been distracted with family issues as of late. "Bald exhortation"? Honestly? You paint it as much more vociferous language than it was. The pros and cons have been discussed, on this list, on the Enigmail list, on PGP-Basics, probably on PGPNet but I don't subscribe. (I guess I could ask a friend who's a member if I was curious enough.) -John [0] http://keyserver.gingerbear.net:11371/pks/lookup?op=stats [1] http://gaudior.net/alma/johnny.pdf [2] http://www.chariotsfire.com/pub/sheng-poster_abstract.pdf [3] http://groups.csail.mit.edu/uid/projects/secure-email/chi_smime.pdf [4] http://www.soe.ucsc.edu/classes/cmps223/Spring09/Gaw%2006.pdf [5] http://enigmail.mozdev.org/documentation/handbook.php -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at 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" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: From dougb at dougbarton.us Sun Feb 28 02:19:19 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 27 Feb 2010 17:19:19 -0800 Subject: key question In-Reply-To: <4B899AE0.3050801@tx.rr.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <4B899AE0.3050801@tx.rr.com> Message-ID: <4B89C497.3020602@dougbarton.us> On 02/27/10 14:21, John Clizbe wrote: > Nor have we seen compelling arguments for their omission as a general rule I think it would be more accurate to say that we haven't seen any arguments that will sway those with strongly held beliefs on either side. Since we're not likely to see them any time in the future, I guess the question at this point is, has everyone had their say yet? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From mariocastelancastro at gmail.com Sun Feb 28 04:10:35 2010 From: mariocastelancastro at gmail.com (Mario =?utf-8?Q?Castel=C3=A1n?= Castro) Date: Sat, 27 Feb 2010 21:10:35 -0600 Subject: How to give the keywork from command line. Message-ID: <877hpyvyvo.fsf@Q6600-0.ver.megared.net.mx> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 February 27th 2010 in gnupg-users at gnupg.org thread "Hot to give the keyword from the command line". Hi, I'm doing a bash script for pack (Tar), compress (lzip or bzip2) and encrypt (GPG with Rijndael 128) very important files, but is supposed to be non interactive, shouldn't ask the user for password when executed, please can you tellme how I can give it from the command line arguments?. Thanks in advance. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkuJ3qcACgkQZ4DA0TLic4jAFwCdF4dw5dH3JstLYfPV5I0HHjDM NogAoI2n3PJZ6b2h67Y7T1UTaEEQrd/v =CxjD -----END PGP SIGNATURE----- From expires2010 at ymail.com Sun Feb 28 05:33:42 2010 From: expires2010 at ymail.com (MFPA) Date: Sun, 28 Feb 2010 04:33:42 +0000 Subject: key question In-Reply-To: <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> Message-ID: <472371020.20100228043342@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Robert On Saturday 27 February 2010 at 8:03:15 PM, you wrote: > On Feb 27, 2010, at 2:21 PM, MFPA wrote: >> I have always been taught to challenge the status quo. "Because that's >> the way we do it" is *never* a good reason to continue doing something >> in a particular way. > The status quo has something going for it: it works. Otherwise stated (with a deal of wisdom) as "if it ain't broke, don't fix it. > 95% of all new ideas are awful and should be discarded. New ideas > are how the status quo changes for the better, but that doesn't mean > we should throw out the status quo just because an idea comes along > which happens to be new. Firstly, it seems unlikely I have presented any new ideas. Secondly, that does not look like a reason to resist reanalysing the status quo. >> My >> contention is that the de facto standard of revealing email addresses >> in key UIDs could actually be mitigating *against* the use of >> encrypted mail, by discouraging people from publishing keys or even >> from using openPGP in the first place. > It's an interesting idea, But not new to you. After I wrote on here, I found http://marc.info/?t=125471254900001&r=1&w=2 which hypothesised essentially the same issue and proposed one possible solution. > but I don't see any facts to back it up. > How many users are dissuaded? I have no idea how I could conduct a survey to answer that question. If you know, please advise me. A change to *not* telling new users they should publish their email addresses would be expected to give some clues as to the validity of this theory. > Is this a major concern, or not a concern? Personal privacy is a major concern, in this age where governments and companies constantly seek to undermine it. Else, governments would not have been forced to make concessions such as introducing privacy and data protection laws. > What does the published literature say about it? And so on, and so on. Specifically on the subject of concern over email addresses on PGP keyservers, I have been able to find the thread I linked to above and nothing else. You could hypothesise that there is no such concern, that I have consistently used inadequate search terms over several years, that people who are concerned about this do not adopt openPGP, that people who adopt openPGP quickly realise this is not a concern, or probably a dozen other things. More broadly, there are any number of sources discussing concern about exposing your email address publicly on the internet. > Speculation is great, but speculation isn't fact -- and we need to > change the way we do things based on facts, not on speculations. We > can agree on facts, but our speculations will likely not overlap very much at all. I'm sure anybody reading this can find multiple examples where speculation has informed progress. >> That advice, coupled with the >> default configuration's enforcement of including an email address (or >> something that appears to be one) clearly has the potential to scare >> potential users from experimenting with openPGP in the first place. > The same way the shotgun in my closet clearly has the potential to be used as a murder weapon. Would making it clear that including an email address was not compulsory (but encouraged for anybody who felt comfortable including one) increase the take-up of openPGP? Would removing your shotgun prevent a would-be murderer from killing you? > Potential != actuality. All manner of potential things do not come > to pass. Before we change the way we do business, I'd like to know > that we're changing to address a real problem, not merely a > potential problem where no one really knows if it's a real problem or not. Usually, the only way to establish if something *really* was an impediment to people adopting a particular course of action is to remove that could-be impediment, and make sure everybody knows you have. > The world has enough interesting problems to solve without us having to go off chasing ghosts. Our opinions differ, but I do not see addressing legitimate concerns about email security as "chasing ghosts." >> Because you suggested in an earlier post in this thread that it was >> somehow acceptable to publish somebody's key to a server without their >> consent. > I don't think I said it was "acceptable." I would find it to be in > poor taste, myself, if it were done deliberately. However, I don't > think it would amount to a moral or ethical failing. Six quotes below, unless I've made a mistake, all are from yourself. Whilst none includes the word "acceptable," each indicates that opinion. 'If someone asks me nicely, "please do not upload this key," I will probably say yes. But it is a *huge* leap to go from there to "do not upload keys without the owners' permission."' 'The key says "public" right at the very top, and I think it's unreasonable to expect people to infer that it means "no, don't share it." This is why the burden is on the key provider: if you don't want the key shared, you have to explicitly tell someone about it. If you don't tell someone about it, they are allowed to think the phrase "public" means just that.' 'You've denied that the person who created the key owns the information on the key. In that case, the person who created the key has no legal or moral right to control how that information is used.' 'However, he also seems to be advocating the advice of "generally speaking, it's a good idea to put keys on the keyservers" be changed to "generally speaking, it's not a good idea to share public keys without the key owner's explicit permission." This is a pretty big change in the conventional wisdom. Before I'll sign on to that I'll have to see some strong reasoning, and I haven't.' 'For myself, I do not send keys up to servers without first checking it with the recipient. This seems like good manners to me. However, I don't view it as mandatory and I don't think we should view it as the appalling breach of morality that MFPA seems to.' 'I'm going to follow the community practice of sharing keys widely, unless there are compelling reasons to do otherwise.' >> Because by hosting it yourself, you have control over what signatures >> and UIDs appear on the published key. Or is that just an illusion? > Illusion. OK... >> The collective response on this thread has indeed debunked a few myths >> for me. The main issue I'll never be converted on is the potential >> privacy problem of publishing somebody else's key to the servers. > This is an argument from emotional conviction. That doesn't mean > it's invalid or inappropriate or that you shouldn't have this > response -- don't get me wrong. I like emotions; emotions are > pretty cool things. I just don't like arguing from emotional > conviction, because I either share in the response or I don't. If I > do, then you don't need to say anything because I'm already on your > side. If I don't, then you don't need to say anything because you > can't persuade me into having that particular emotional response. I either have it or I don't. > But just like there's nothing you can say to *me*, there's nothing > I can say to *you*. The instant you say "I will never be > converted!", well, okay: thanks for letting me know. I won't try to > persuade you, because you've made it clear you won't be persuaded. Kind of "let's agree to disagree?" Or "we seem to be running out of arguments?" >> If I was able to show that, those who need/want such privacy would be >> making a poor job of trying to enforce it. > So the lack of evidence is, itself, evidence? That sounds more like a conspiracy theory. I don't think that says the lack of evidence constitutes evidence. Rather, I think it indicates a legitimate reason why evidence cannot be brought to bear. >> I don't care how many users >> this affects. For me, what matters is that any key I encounter *could* >> relate to one of them. > This is an idealistic view of the world. I like idealism. I > admire idealism. I just think it's impractical and destructive. How is it impractical or destructive to treat everybody's privacy seriously on the grounds that, just occasionally, it might *really* matter? > What you're saying here is, "even if the advice were sound for one > million users, and destructive to the privacy of just one, I still > would not change because any key I encounter could be that one." That is exactly what I am saying. Neutral for a million but destructive for one, so let's all protect the one. > The perfect is the enemy of the good. Perfection is usually unattainable. That is no reason to resist aspiring to the best that can be achieved. - -- Best regards MFPA mailto:expires2010 at ymail.com Virtual workspace, Virtual Office, Virtual Job -----BEGIN PGP SIGNATURE----- iQCVAwUBS4nyUKipC46tDG5pAQpi/wP/QqNmNpbrQlXCeoPKbcQsbsdU3HOGTvv/ V1igcq00vQNC4iKgwoc+rDeJNINTSovfrNXEev6S3sShKXgt87+TZPn0oIf2FTZ4 tu1krSUf9Esn8FZ8g9HWZ/iexEz7CDCRB0QtYp5JZkpYHfrfCK4II8xddG7NeyJw UV5NAkc1VXI= =YoZ3 -----END PGP SIGNATURE----- From expires2010 at ymail.com Sun Feb 28 06:50:03 2010 From: expires2010 at ymail.com (MFPA) Date: Sun, 28 Feb 2010 05:50:03 +0000 Subject: Fwd: Re: key question In-Reply-To: <4B8994B0.8010009@grant-olson.net> References: <4B8994B0.8010009@grant-olson.net> Message-ID: <5410253140.20100228055003@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Grant On Saturday 27 February 2010 at 9:54:56 PM, you wrote: > It sounds like you're using the software to do the opposite thing that > many people do. I think digital signatures are utilized much more than > encrypted communication. I don't know; I have not seen any purported volumes ofeither > And digital signatures are about authenticating to a real person, > and not anonymity. Even with a "persona" on a forum, the digital signature provides a measure of reassurance that those posts bearing the same moniker actually do come from the same person. > If you don't want to publish your email for the anonymity/privacy > reasons you've outlined, then you probably don't want to use your legal > name either. And it looks like you don't. Which is fine for encrypting > documents. But it renders two key features of digital signatures > meaningless. Authentication and Non-repudiation go out the window. I'm not convinced that non-repudiation does go out of the window much more than for a key claiming to represent a person with a name backed up by government-issued ID, unless you know more about the person. Say an individual has a key saying he's John Smith. He's found a few people he doesn't know, who have checked his passport or driving licence and signed his key to attest to his identity. He stops using his key, stops communicating with you and closes the email account. A very common name; which John Smith was it? Is it much easier to track a random John Smith than a random MFPA? > How > do I authenticate that an anonymous entity is really an anonymous > entity? I'm not anonymous: I'm MFPA. Various people who know me personally could attest to that. For all anybody reading this knows, I could have renounced my previous identity and now have official ID declaring that I am MFPA. > That doesn't make any sense. How do I get into a dispute with > an anonymous entity about whether he really agreed to do X? I wasn't planning to get into a dispute. *If* I said I'll do it, I will. OK (-; > And > although it does prove message integrity, that, in and of itself, > doesn't mean much for an anonymous entity. A message to a mailing list from somebody you do not know who calls himself MFPA. A message to the same mailing list from somebody I do not know who calls himself Grant Olsen. Both are signed and the signature checks both indicate no tampering. In what way does one digital signature mean less than the other? > So a few examples to elaborate. I'm going to use MFPA as the anonymous > user who doesn't have a real ID for clarity sake. It's better than > "anonymous entity". Just to be clear, I'm not really talking about you > or making any personal attacks in the examples. You're just the generic > guy with the non-identifiable key. Thanks, I think (-: > Farfetched example. An email from MFPA pops up on the list. "My house > burnt down. Lost my key. Lost my rev certificate. Here's my new > info." Five minutes later, another email from MFPA. "That dude > generated a fake key. Keep using the old one. The new one is bad!" A > third email from MFPA. "That last dude is lying. Turns out he stole my > laptop before burning my house down." Who do we trust? Which key do we > use? We have no way of knowing who the real MFPA is, because he was > anonymous to begin with. My posting style, turn of phrase, and opinions suddenly taking a step-change could be a clue. Although, depending on how I suffered in the fire, that could happen. If I used the name John Smith, how would this example be different? (BTW I'm NOT John Smith) > How could I sign your key? It sounds like you don't want anyone to sign > it anyway, plenty of other people want to sign keys and build the web of > trust. I can't verify your key in any way. You're anonymous. There's > no way to prove you're MFPA. So I can't sign your key. If you knew me personally, you could. And as I already said, do you know MFPA's not my legal identity? There used to be somebody in my town who had officially changed his name to FREFF. (Never did understand why.) > Lets assume among your circle of friends, who know each other personally > in real life, you sign off on each others keys. And I somehow know one > of your friends, and we sign each others keys. To me, it's a > meaningless assertion for someone to claim that they've verified that > you're the real MFPA. That doesn't mean anything to me because you're > anonymous to me. It also doesn't mean anything if you've signed off on > someone's key. What does it mean to me that MFPA vouched for someone > else's identity? Another meaningless assertion. If you replace each instance of "MFPA" in the above paragraph with "John Smith," how does it alter the sense of your point? If your friend, who you have known for decades, asked you to sign their key, would you check their documents just in case their legal identity differed from the name you had always known them by? Would you attest only to their legal name, or to the name they are known by, or both? > I'm not really using OpenPGP encryption at all. I may never need to > send an encrypted email. None of my real-life friends, family, > co-workers use it. Not Cuban, Iranian, or in the Falun Gong. I use it > for two things, (1) to post on computer geek mailing lists, and (2) to > verify software packages. For (1), I guess I'm not too concerned about > digital signatures. The PGP Global Directory is good enough > authentication for me. For (2), I actually am. It'd be nice to have > the software packages signed by a validated key. If people don't use > personally identifying information, the web of trust breaks. The only > way for me to actually validate a key is to meet with the software > packager personally. Assume the path between your key and the software developer's included your signature on my hypothetical friend's key, followed by their signature on my key (MFPA), followed by my signature on somebody else's key. That's a problem for you? - -- Best regards MFPA mailto:expires2010 at ymail.com A bird in the hand makes it awfully hard to blow your nose -----BEGIN PGP SIGNATURE----- iQCVAwUBS4oEFKipC46tDG5pAQruxwP9GhcIQ82heOad+Z7lcaWi+jO88hnhXxav vIqUO2+jI1FHMbUXsSklzvVCi2g1iXof55/Cxw1/9BeLFoqtN1/9EZtN/wtq+R6U /o0Q1Gz88Wiup8XPKlIjrOEkV9nIywahLW99ZLHR4lBpkF+XJyy0GRLjBEW/rpRA WQst7szsEfg= =CVbx -----END PGP SIGNATURE----- From expires2010 at ymail.com Sun Feb 28 06:54:35 2010 From: expires2010 at ymail.com (MFPA) Date: Sun, 28 Feb 2010 05:54:35 +0000 Subject: key question In-Reply-To: <1267312783.3824.21.camel@localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <1267312783.3824.21.camel@localhost> Message-ID: <246679804.20100228055435@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Paul On Saturday 27 February 2010 at 11:19:43 PM, you wrote: > GnuPG doesn't, at least as of 1.4.10, force you to include an e-mail > address in your user ID. It merely requests an e-mail address, and you > can just press enter and ignore the request. In my opinion that's a step forward. I'm convinced 1.4.9 would only do that in "expert" mode. - -- Best regards MFPA mailto:expires2010 at ymail.com Two wrongs don't make a right. But three lefts do. -----BEGIN PGP SIGNATURE----- iQCVAwUBS4oFJ6ipC46tDG5pAQoUHwP9EPBFa/ALcfsUFR/p7+cFkuwdtcj0E2Hj ZSckxY6TCyE0zQsjghXWsVL/IcFHb5jv7/NNrhPKva12MPgxxtSCCOMvnCm167J2 aHyr/0gXBiclANe1Z6yvkUFOF+zND9zujjceG5QUJA1HVG1IIXHUWdZdPKp28Rbr 71SgEk9Xm3A= =ZyWM -----END PGP SIGNATURE----- From free10pro at gmail.com Sun Feb 28 07:01:41 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sat, 27 Feb 2010 22:01:41 -0800 Subject: key question In-Reply-To: <472371020.20100228043342@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> <472371020.20100228043342@my_localhost> Message-ID: <1267336901.3824.62.camel@localhost> On Sun, 2010-02-28 at 04:33 +0000, MFPA wrote: > > Speculation is great, but speculation isn't fact -- and we need to > > change the way we do things based on facts, not on speculations. We > > can agree on facts, but our speculations will likely not overlap very much at all. > > I'm sure anybody reading this can find multiple examples where speculation > has informed progress. Speculation isn't any more progress than an idea is action. Speculation buttressed with facts leads, in time, to progress. But speculation, like an idea, is only the germ of what it is intended to create. -Paul -- New Windows 7: Double the DRM, Double the fun! Learn more: +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ From free10pro at gmail.com Sun Feb 28 06:50:10 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sat, 27 Feb 2010 21:50:10 -0800 Subject: key question In-Reply-To: <472371020.20100228043342@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> <472371020.20100228043342@my_localhost> Message-ID: <1267336210.3824.52.camel@localhost> I think that MFPA has succinctly summed up his point of view in these two quotes. On Sun, 2010-02-28 at 04:33 +0000, MFPA wrote: > > What you're saying here is, "even if the advice were sound for one > > million users, and destructive to the privacy of just one, I still > > would not change because any key I encounter could be that one." > > That is exactly what I am saying. Neutral for a million but > destructive for one, so let's all protect the one. On Sat, 2010-02-27 at 20:39:57 +0000, MFPA wrote: > >> It seems (and I could be utterly wrong), that MFPA is > >> saying "Not everyone wants their key on the > >> keyservers, so please don't automatically send other > >> people's keys there. If the key owner wants the key > >> on the keyservers, he'll send it himself." > > That is exactly what I am saying. Most peoples keys contain personal > contact details and the decision to place that information in the > public domain rests solely with the person whose details they are. -Paul -- Got PGP? +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ From rjh at sixdemonbag.org Sun Feb 28 07:20:46 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 28 Feb 2010 01:20:46 -0500 Subject: key question In-Reply-To: <472371020.20100228043342@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> <472371020.20100228043342@my_localhost> Message-ID: <61558ABB-BF4C-4D24-B232-880FC6FC1B2D@sixdemonbag.org> > Kind of "let's agree to disagree?" More like, "since you are reacting emotionally and refuse to even entertain the possibility of being persuaded, there is no point in continuing this conversation." I wish you a pleasant day. From laurent.jumet at skynet.be Sun Feb 28 08:44:02 2010 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Sun, 28 Feb 2010 08:44:02 +0100 Subject: How to give the keywork from command line. In-Reply-To: <877hpyvyvo.fsf@Q6600-0.ver.megared.net.mx> Message-ID: Hello Mario ! "Mario Castel?n Castro" wrote: > Hi, I'm doing a bash script for pack (Tar), compress (lzip or bzip2) > and encrypt (GPG with Rijndael 128) very important files, but is > supposed to be non interactive, shouldn't ask the user for password > when executed, please can you tellme how I can give it from the > command line arguments?. Using --passphrase-file FILE means that the first line of FILE will be used as passphrase. --passphrase STRING uses STRING as the passphrase. Additionnaly, you'll probably need all or some of the switches: --batch --no-tty --yes to suppress console interaction. -- Laurent Jumet KeyID: 0xCFAF704C From kloecker at kde.org Sun Feb 28 11:22:21 2010 From: kloecker at kde.org (Ingo =?iso-8859-1?q?Kl=F6cker?=) Date: Sun, 28 Feb 2010 11:22:21 +0100 Subject: key generation: email-address necessary? In-Reply-To: <4B8970CB.2000805@dougbarton.us> References: <201002261934.28476.mailing-lists-mmvi@bretschneidernet.de> <4B8970CB.2000805@dougbarton.us> Message-ID: <201002281122.31696@thufir.ingo-kloecker.de> On Saturday 27 February 2010, Doug Barton wrote: > On 02/26/10 10:34, Martin Bretschneider wrote: > > Hi, > > > > I want to recreate my GnuPG keys. My question is if I can omit the > > email address? Since I do not want my email addresses to appear on > > the keyservers because of spammers and so on. > [snip] > > 5. And finally something germane to the list, the amount of trouble > you will cause for yourself and others by omitting your e-mail > address will far exceed any benefit you may get from "hiding" your > address from the spammers. Leaving the spam-argument aside (which I agree with Doug is a bogus one) I can think of a good (?) reason for creating an OpenPGP key without email address: Usage of a master key that is used exclusively for the certification of other OpenPGP keys. All signing and encryption keys will be subkeys of this master key. Now the question is whether user ids can be tied to subkeys? (I haven't studied the spec, but from what I know the answer is most likely no. Anyway...) If the answer is yes, then one could tie certain user ids to certain signing/encryption subkeys and this way have one master key certifying a whole bunch of signing/encryption subkeys used for different purposes. (Not sure whether this does actually make sense.) If the answer is no, then the master key would be a standalone certify- only key that would not be used by mail clients for signing/encryption and thus it does not do any harm that the key lacks an email address. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mariocastelancastro at gmail.com Sun Feb 28 16:41:13 2010 From: mariocastelancastro at gmail.com (=?ISO-8859-1?Q?Mario_Castel=E1n_Castro?=) Date: Sun, 28 Feb 2010 09:41:13 -0600 Subject: How to give the keywork from command line. In-Reply-To: References: <877hpyvyvo.fsf@Q6600-0.ver.megared.net.mx> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 February 27th 2010 in gnupg-users at gnupg.org thread "Hot to give the keyword from the command line" Thanks Laurent, it works :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkuKjnwACgkQZ4DA0TLic4gvbACeI6iz3fXlywEgkFDFsCelyCT5 IVwAn2l44dnfM0URtyYmP+dpVSWFN4Ad =o3X7 -----END PGP SIGNATURE----- 2010/2/28 Laurent Jumet : > Hello Mario ! > > "Mario Castel?n Castro" wrote: > >> Hi, I'm doing a bash script for pack (Tar), compress (lzip or bzip2) >> and encrypt (GPG with Rijndael 128) very important files, but is >> supposed to be non interactive, shouldn't ask the user for password >> when executed, please can you tellme how I can give it from the >> command line arguments?. > > ? ?Using > --passphrase-file FILE > ? ?means that the first line of FILE will be used as passphrase. > > --passphrase STRING > ? ?uses STRING as the passphrase. > > ? ?Additionnaly, you'll probably need all or some of the switches: > --batch > --no-tty > --yes > ? ?to suppress console interaction. > > -- > Laurent Jumet > ? ? ?KeyID: 0xCFAF704C > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From expires2010 at ymail.com Sun Feb 28 17:19:57 2010 From: expires2010 at ymail.com (MFPA) Date: Sun, 28 Feb 2010 16:19:57 +0000 Subject: key question In-Reply-To: <4B899AE0.3050801@tx.rr.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <4B899AE0.3050801@tx.rr.com> Message-ID: <180766034.20100228161957@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi John On Saturday 27 February 2010 at 10:21:20 PM, you wrote: > MFPA wrote: >> My contention is that the de >> facto standard of revealing email addresses in key UIDs could actually be >> mitigating *against* the use of encrypted mail, by discouraging people from >> publishing keys or even from using openPGP in the first place. > An /interesting/ thesis, However, to be taken seriously you need to back it up > with more than conjecture. There are plenty of obstacles to the widespread use > of encryption in the computing literature without grasping at straws to create more. I'm not creating an extra obstacle. I'm highlighting an existing obstacle about which I have consistently found almost no discussion. I refer you to a thread at http://marc.info/?l=gnupg-devel&m=125471247807096&w=2 where the OP proposes removing this obstacle by (optionally) hashing the email address in the UID and particularly the final post at http://www.imc.org/ietf-openpgp/mail-archive/msg36986.html which covers issues other than the OP's perceived spam threat. >> There is a widespread perception (rightly or wrongly) that exposing your >> email address publicly on the internet will lead to that email address being >> spammed into oblivion. The new openPGP user is exhorted to create a key pair >> using their name and email address as the UID, and to upload this key to a >> server. That advice, coupled with the default configuration's enforcement of >> including an email address (or something that appears to be one) clearly has >> the potential to scare potential users from experimenting with openPGP in the >> first place. > Widespread perception? Indeed? Please quantify. Before you even look at real privacy concerns, a Google search for "avoid spam" (without quotes) says there are over 38 million matches. That's pretty widespread, even if some of those 38 million are promoting spam filters and other such measures. > Odds on users will get more SPAM from asking a question > on a public mailing list such as this one than they will from that attributable > to keyservers. Assuming that SPAM (rather than privacy) worries are the obstacle in their mind, postings saying that keyserver spam is not an issue will not be all that a potential user researching the matter will find. They could go to a keyserver, search on a fairly common name, and in a matter of seconds, display a page containing hundreds of email addresses. Then, finding http://www.mail-archive.com/cypherpunks at cyberpass.net/msg01815.html would likely concern them, especially when they read the line "It used to be possible to extract keys from the PGP keyservers, which meant that a low-tech spammer could nab 5-20000 email addresses" They might also find http://marc.info/?l=gnupg-users&m=110369132905296&w=2 where somebody describes creating and uploading a key with a freshhly-crafted spamgourmet address, which started receiving spam the following day. > "(rightly or wrongly)" Or imaginary? Do I imagine that I can do a search and find seemingly endless advice about munging, temporary/disposible addresses, care over giving out your address or posting it to a website or newsgroup? I'm sure I do not. Whether right or wrong, the perception definitely exists and has given rise to writings in many quarters.. > Rather than trying to convince us of new > "obstacles" without providing any evidence, you may wish to review what the HCI > folks say are the obstacles: "Why Johnny Can't Encrypt"[1], "Why Johnny Still > Can't Encrypt"[2], "How to Make Secure Email Easier to Use"[3], and a personal > favorite, "Secrecy, Flagging, and Paranoia: Adoption Criteria in Encrypted > E-Mail"[4]. Interesting. I had already read [1] and [2]. My would-be user reads up about openPGP. He finds that it's the de facto standard for his key UID to show his email address. The software user guides and the community recommend the key be published to the keyservers. That sets his alarm-bells ringing; he gives up before even reaching any of the documented obstacles. > [...] > I've seen errant ideas criticized, not any person. Skimming back over some posts in the thread, I still see it. But, hey, no harm done. > I think most of us agree that the publishing of another person's key(s) is > mostly attributable to a) accident, or b) ignorance. I don't think malice > normally is a factor. I suspect that's true, although the only time it has so far happened to me was an act of malice. - -- Best regards MFPA mailto:expires2010 at ymail.com When you're caffeinated, all is right with the world -----BEGIN PGP SIGNATURE----- iQCVAwUBS4qX1qipC46tDG5pAQoeFAP/RtIbq55tJmxoqrtF2v4SOnMmhYTPxJcq GwMzZDWntwNxkbp7MklvlBNT4Ll0OYYdp/emG4f04aMSNPXcCIXu3RWRo1U3nuzV 5MKq5djXkZSkYSKqkrsVFtWsiUrqRdEY97jiDDe+Ja+7IL/786yGtNdUfjnlthQz WhESJPdwFO8= =bWtL -----END PGP SIGNATURE----- From faramir.cl at gmail.com Sun Feb 28 19:56:12 2010 From: faramir.cl at gmail.com (Faramir) Date: Sun, 28 Feb 2010 15:56:12 -0300 Subject: OFF LIST In-Reply-To: <4B891E32.7010504@mac.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20100227062517.6c5ac5d8@scorpio.seibercom.net> <4B891E32.7010504@mac.com> Message-ID: <4B8ABC4C.8030003@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Charly Avital escribi?: > Hi, > > news of the 8.8, or 8.3 earthquake that has stricken Chile have been > posted in many on-line dailies. ... > I have also e-mailed Faramir directly, trying to have news. Yes, we already exchanged an email yesterday. > It is probable that the Telecom infrastructure that has not been > affected by the earthquake is swamped with access attempts. In fact, while I have all the services working, Telecom are still not working 100%, so it is very likely people in good health is not being able to communicate. > I apologize for this intrusion, and thank in advance any information > that subscribers to this list may have on the situation in the capital > (Santiago), and in coastal resorts like Vi?a del Mar, Cachagua, > Algarrobo (it's summer time in Chile now). I suppose most people on those places should be OK, a cousin of me, who was on vacations 17 km away of Algarrobo, reported he is fine, so Algarrobo should be fine too, after all, it was not the most heavily affected zone. So I wouldn't worry too much about those zones. Still, there may be incidents with a few old buildings, but chances are most people is ok. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLirxMAAoJEMV4f6PvczxAFlwIAKh0jSv8yhWGdAuyku4mdpv0 RnHFGNCanCYosqImo0Dtlzf45QVLCMEOzvTf8KjBzTofNBBLSSfvU+lNWNXN5mMd KGTXSJW5v7WOdiLq31zDY/jB3Y3GtBQsrBPrMnnQ8e6dfahnEeKf/kt2Ww/nWOXW QV5evAwm6a5zDlTRVg+YzevWRoLyjtNrXwREsItB5+rSj5ngUyfSiwTdwfEDBni7 rrYdEhFsy8BeM/X45WGLij8y4vqUX/M+l6zYDCeCbqmNRt54GinO9S4oPj8RxkZD IIX1wfBtEVQXuI88RvzoCxA0KCdPibewmsdNvN8IT94FG/Ix/V17Qx1gAlV6Ok0= =q41E -----END PGP SIGNATURE----- From kgo at grant-olson.net Sun Feb 28 20:58:05 2010 From: kgo at grant-olson.net (Grant Olson) Date: Sun, 28 Feb 2010 14:58:05 -0500 Subject: How to give the keywork from command line. In-Reply-To: References: <877hpyvyvo.fsf@Q6600-0.ver.megared.net.mx> Message-ID: <4B8ACACD.2000703@grant-olson.net> On 2/28/2010 10:41 AM, Mario Castel?n Castro wrote: > February 27th 2010 in gnupg-users at gnupg.org thread "Hot to give the > keyword from the command line" > > Thanks Laurent, it works :). Also, if you encrypt to a key, you shouldn't need to provide a passphrase at all, unless you need to sign the file too. I get nervous about passphrases in batch files... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Sun Feb 28 21:09:14 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 28 Feb 2010 15:09:14 -0500 Subject: key question In-Reply-To: <246679804.20100228055435@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <1267312783.3824.21.camel@localhost> <246679804.20100228055435@my_localhost> Message-ID: <12B1AE6C-12CD-44E1-982E-8A5D021640B4@jabberwocky.com> On Feb 28, 2010, at 12:54 AM, MFPA wrote: > On Saturday 27 February 2010 at 11:19:43 PM, you wrote: > > > >> GnuPG doesn't, at least as of 1.4.10, force you to include an e-mail >> address in your user ID. It merely requests an e-mail address, and you >> can just press enter and ignore the request. > > In my opinion that's a step forward. > > I'm convinced 1.4.9 would only do that in "expert" mode. No, email addresses have been optional in GnuPG for as long back as I can recall. It's certainly been true since version 1.0.6, back in 2001. I don't recall the exact details for PGP on this point, but certainly the latest version allows you to skip the email address. It'll ask you if you really want to make a key without an email address, but once you click "yes", you're free to do what you want. David From dshaw at jabberwocky.com Sun Feb 28 21:29:32 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 28 Feb 2010 15:29:32 -0500 Subject: key question In-Reply-To: <4B8994B0.8010009@grant-olson.net> References: <4B8994B0.8010009@grant-olson.net> Message-ID: <3EA91BCB-0E5B-45C2-A3A5-2310C102E267@jabberwocky.com> On Feb 27, 2010, at 4:54 PM, Grant Olson wrote: > Doh! Originally sent off list... Maybe Robert got a psychic vibe... > > On 2/27/2010 2:21 PM, MFPA wrote: >> >> I don't want such a vote. Whether somebody chooses to include an email >> address in their UID is up to the individual. I have not seen anything >> that convinces me it is better for me to include one. >> >> > > It sounds like you're using the software to do the opposite thing that > many people do. I think digital signatures are utilized much more than > encrypted communication. Yes. > And digital signatures are about > authenticating to a real person, and not anonymity. No. Many (most?) digital signatures are used to authenticate a system, rather than a real person. For an OpenPGP-specific example, it is widely used to authenticate software packages, both when distributed as source, and also built-in to things like RPM for distributing binaries. Outside of OpenPGP, there is SSL, etc. > If you don't want to publish your email for the anonymity/privacy > reasons you've outlined, then you probably don't want to use your legal > name either. And it looks like you don't. Which is fine for encrypting > documents. But it renders two key features of digital signatures > meaningless. Authentication and Non-repudiation go out the window. How > do I authenticate that an anonymous entity is really an anonymous > entity? It's not used in the same way, but it is far from meaningless. You may not know who MFPA is, but if MFPA signs his messages (as he does), you can verify that the pseudonymous entity MFPA that you were speaking with yesterday is still the same pseudonymous entity MFPA you are speaking with today. > Lets assume among your circle of friends, who know each other personally > in real life, you sign off on each others keys. And I somehow know one > of your friends, and we sign each others keys. To me, it's a > meaningless assertion for someone to claim that they've verified that > you're the real MFPA. That doesn't mean anything to me because you're > anonymous to me. It also doesn't mean anything if you've signed off on > someone's key. What does it mean to me that MFPA vouched for someone > else's identity? Another meaningless assertion. That isn't how the web of trust works. Well, it *can* work that way for you, since you can choose who to trust and who not to, but that's not the information encoded in there. I "know" dozens of people on the net. I've exchanged encrypted mail with them, I've worked with them, in some case for years... and I've never met them in person. For all I know, they're actually a group of people sharing the same email address and using a name that looks like a real one, and not obviously pseudonymous like MFPA. Think about what it really means in the web of trust when you see a signature. The signature only maps back to a real person indirectly. David From reynt0 at cs.albany.edu Sun Feb 28 22:06:11 2010 From: reynt0 at cs.albany.edu (reynt0) Date: Sun, 28 Feb 2010 16:06:11 -0500 (EST) Subject: key question In-Reply-To: <1267336901.3824.62.camel@localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> <472371020.20100228043342@my_localhost> <1267336901.3824.62.camel@localhost> Message-ID: On Sat, 27 Feb 2010, Paul Richard Ramer wrote: . . . > Speculation isn't any more progress than an idea is action. Speculation > buttressed with facts leads, in time, to progress. But speculation, . . . And speculation often has the very useful effect of stimulating search for new facts where previously none had been believed necessary. From reynt0 at cs.albany.edu Sun Feb 28 22:18:55 2010 From: reynt0 at cs.albany.edu (reynt0) Date: Sun, 28 Feb 2010 16:18:55 -0500 (EST) Subject: Fwd: Re: key question In-Reply-To: <5410253140.20100228055003@my_localhost> References: <4B8994B0.8010009@grant-olson.net> <5410253140.20100228055003@my_localhost> Message-ID: On Sun, 28 Feb 2010, MFPA wrote: . . . >> no way to prove you're MFPA. So I can't sign your key. > > If you knew me personally, you could. > > And as I already said, do you know MFPA's not my legal identity? > There used to be somebody in my town who had officially changed his > name to FREFF. (Never did understand why.) . . . Interesting to see, among some apt comments about identity and presumptions about identity, a little information being leaked. Now all the serious ones, or maybe the merely curious, have to do is to search "FREFF"--or maybe buy from Google the info Google has about FREFF if nothing can be found easily by a free, ordinary user search--and find out a beginning of how to track down MFPA so they can verify his key in person. :-) Also, IIRC MFPA never made any assertion about his "name", though others seem to have assumed it is a pseudonym or etc, which has been interesting to observe as examples of presumption at work. Maybe he just has some four-long-word name so he uses his initials, etc? From kgo at grant-olson.net Sun Feb 28 22:19:28 2010 From: kgo at grant-olson.net (Grant Olson) Date: Sun, 28 Feb 2010 16:19:28 -0500 Subject: key question In-Reply-To: <3EA91BCB-0E5B-45C2-A3A5-2310C102E267@jabberwocky.com> References: <4B8994B0.8010009@grant-olson.net> <3EA91BCB-0E5B-45C2-A3A5-2310C102E267@jabberwocky.com> Message-ID: <4B8ADDE0.2020206@grant-olson.net> > > > > That isn't how the web of trust works. Well, it *can* work that way for you, since you can choose who to trust and who not to, but that's not the information encoded in there. I "know" dozens of people on the net. I've exchanged encrypted mail with them, I've worked with them, in some case for years... and I've never met them in person. For all I know, they're actually a group of people sharing the same email address and using a name that looks like a real one, and not obviously pseudonymous like MFPA. > > > > Think about what it really means in the web of trust when you see a signature. The signature only maps back to a real person indirectly. > > > > David > > Good points all. Here's what I'm thinking. Imagine I trace path on the web of trust, like with those pgp pathfinders out there. Example one: me -> user1 at example.org -> user2 at example.org -> user3 at example.org -> you Now not that it's practical, but I could trace through that. user1 - he's an old college buddy. I ask him how he knows user2. He's been sitting in the next cube over from user1 for twenty years. I ask user2 how he knows user3. Key-signing party. A passport and a driver's license. I ask user3 how he knows you. We've been working on some open source project for years. I could, not that it's practical to do, perform additional verification all of these claims. Example 2: me -> user1 at example.org -> user2 at example.org -> a at b.c -> you User1 same story. College buddies. User2. Same story. They work together. I ask user2 how he knows a at b.c. He responds that he's not allowed to disclose the info for privacy concerns. I ask you how you know a at b.c. You give the same response. Can't contact a at b.c to ask who he is because it's not a real email. I would argue that those two examples have much different levels of indirectness, since I can't conceivably verify the chain in example 2. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From reynt0 at cs.albany.edu Sun Feb 28 22:20:15 2010 From: reynt0 at cs.albany.edu (reynt0) Date: Sun, 28 Feb 2010 16:20:15 -0500 (EST) Subject: key question In-Reply-To: <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> Message-ID: On Sat, 27 Feb 2010, Robert J. Hansen wrote: . . . > The perfect is the enemy of the good. Just to note, did RJH actually intend to write "...the enemy of the good enough.", which I believe is the usual quote? The two are rather different ideas, even more so if morality has been included as an aspect of the discussion. From rjh at sixdemonbag.org Sun Feb 28 22:59:17 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 28 Feb 2010 16:59:17 -0500 Subject: key question In-Reply-To: References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> Message-ID: <00F36146-CD2D-4805-AD14-7DEBA07A16E9@sixdemonbag.org> >> The perfect is the enemy of the good. It's a pretty common engineering maxim. It's not a statement about morality -- or, at least, it wasn't my intent for it to be taken as such. For an excellent engineering example of the difference between perfect and good, compare Project Xanadu to the World Wide Web. Project Xanadu's obsession with getting everything right has massively impaired its adoption. The Web's willingness to say, "this is a problem and we don't know how to fix it but we're going to go ahead regardless" has been instrumental in its widespread adoption. From jcruff at gmail.com Sun Feb 28 23:05:53 2010 From: jcruff at gmail.com (Chris Ruff) Date: Sun, 28 Feb 2010 17:05:53 -0500 Subject: OmniKey 6121 & OpenPGP Smartcard v2.0 Message-ID: <4B8AE8C1.5010808@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just wanted to share that while the OmniKey 6121 USB Reader for ID-000 cards is stated to work on the Fellowship HOW-TO page, when using the OpenPGP v2.0 card it requires the actual OmniKey drivers to be fully supported. I've confirmed this on both Mac OS X and Linux. The one thing that doesn't work without their drivers is the ability to sign anything but your own keys during creation. The following error would be seen: gpg: signing failed: General error gpg: signing failed: General error Hope this helps someone trying to use the same card. - -- __________________________________ Chris Ruff email: jcruff at gmail.com gpg key: 0x052A4FAD gpg fgpr: 6530 8DA8 805C 707F 3611 9851 D057 FC41 052A 4FAD -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: OpenPGP SmartCard v2.0 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLiui4AAoJENBX/EEFKk+tUIoH/iAn6l/Hh/pbqNqmHBdGhM4o Y8PMY/k3kbQWWJYXQBb0F6AW5BYxVC5QirW0IqnWlPhDGHftpydOQnyLjNDYMyMc eJg7se3dnXh0rJxQI913z+1eFXIueDFyQG/1LyB5jD3WjpTxt4cq1XB43DVO1Zr6 Mm/H4pBNiqJ99tKDL7Lqm/igQQmfQAXTepsRrYXtfLnMlS+uzMdIXP2PtARrZtvJ lcWdPs67rnj+BeM2Vc5oY6dCz0J4mGxRi+9illQ3V8e6Va+tdFv7nFtox2D8aeG3 UtQyaxa4aVCvt+jTJagknxNCJF86jVqOlAjdKRQ7QfjV3arRq4LamHkHmVwfYCY= =gHXe -----END PGP SIGNATURE-----