From bernhard at intevation.de Tue Apr 1 12:12:49 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 1 Apr 2014 12:12:49 +0200 Subject: x.509 and gpg In-Reply-To: <04b61caf82019df04cf65bee7ee792eb.squirrel@webmail.harte-lyne.ca> References: <04b61caf82019df04cf65bee7ee792eb.squirrel@webmail.harte-lyne.ca> Message-ID: <201404011212.53350.bernhard@intevation.de> Hi James, On Thursday 27 March 2014 at 21:50:16, James B. Byrne wrote: > However, gpgsm does not seem to want to deal with our certificates and I > lack the experience or knowledge to determine exactly why. So, I am here > asking for your assistance to resolve this problem. > > I started with a single certificate and key issued to myself and signed by > our CA: > > openssl pkcs12 -export -in 3F.pem -inkey 3F.key -out 3F.p12 > > I then attempted to import this into my gpg keyring via the command line > using gpgsm: > > gpgsm --import 3F.p12 > gpgsm[5321]: can't connect to `/home/byrnejb/.gnupg/S.gpg-agent': No such > file or directory > I gather from the first line of error that I should be running gpg-agent. Yes, you should run gpg-agent. It is also recommendable when using OpenPGP. Gpg-agent is the component dealing with the private certificates (that includes access to the (private) key material). It can also cache parts of this. Under some circumstances gpg-agent is started automatically, but because you may access gnupg/gpgsm functions from several applications/terminals, it makes a lot of sense to start it early. > I have read how to start this for command line sessions but I am hesitant > to do so before getting some expert help. The session manager I am using > for this is gnome-terminal running from a non-privileged gnome desktop > manager (gnome-desktop.x86_64-2.28.2). Should I start this from > .bash_profile, which would imply that a new gpg-agent would be started for > each new session window? or as some have suggested, start it from > .Xsession? or perhaps gpg-agent should not be started at all and I should > use some option on gpgsm to avoid the need for gpg-agent. info gnupg2 section Invoking GPG-AGENT is your friend. :) > In any case, I am also trying to determine how to load our CA root and CA > issuer certificates or at least make them known to gpg/gpgsm as this seems > necessary given what I have read in the man pages. See http://wiki.gnupg.org/X.509, I've linked by root certificate guide from there. Let me know how it works out for you! Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3696 bytes Desc: not available URL: From byrnejb at harte-lyne.ca Tue Apr 1 17:03:56 2014 From: byrnejb at harte-lyne.ca (James B. Byrne) Date: Tue, 1 Apr 2014 11:03:56 -0400 Subject: x.509 and gpg In-Reply-To: <201404011212.53350.bernhard@intevation.de> References: <04b61caf82019df04cf65bee7ee792eb.squirrel@webmail.harte-lyne.ca> <201404011212.53350.bernhard@intevation.de> Message-ID: <4b9da5d7e60c40b337f117c927e50646.squirrel@webmail.harte-lyne.ca> On Tue, April 1, 2014 06:12, Bernhard Reiter wrote: > Hi James, > . . . > > See http://wiki.gnupg.org/X.509, I've linked by root certificate guide > from there. > > Let me know how it works out for you! > Bernhard Thank you. I have put the issue aside for now as yours is the first response I have received and I was unable to make much progress on my own. I will review the material you refer to and will indeed report on any progress or difficulties I encounter. Regards, -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 From postpics123 at gmail.com Tue Apr 1 11:20:53 2014 From: postpics123 at gmail.com (------ ------) Date: Tue, 1 Apr 2014 11:20:53 +0200 Subject: post-quantum computing in GnuPG Message-ID: Hi, is there any plan to include post-quantum cryptography ciphers such as McEliece and NTRU in GnuPG? I know that NTRU is patented until 2020, but I found some C implementations. It says that modifying the code it is possibile to have it patent-free in 2017. http://goo.gl/cQGavW This is there officiale implementation by Security Innovation. http://goo.gl/J6Adjw In any case there is McEliece. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Wed Apr 2 01:43:09 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 01 Apr 2014 19:43:09 -0400 Subject: post-quantum computing in GnuPG In-Reply-To: References: Message-ID: <533B4F0D.90901@sixdemonbag.org> > Hi, is there any plan to include post-quantum cryptography ciphers such > as McEliece and NTRU in GnuPG? I am not a GnuPG developer: they will have the official word. Unofficially, no. GnuPG tracks the RFCs published by the IETF Working Group. If you want to see this, make a case for it to the WG and get algorithm numbers, etc., assigned. Then implement it as a patch to a GnuPG tree and let people beat on it for a while. If it survives, you've got an excellent chance of getting it adopted into GnuPG. I know, I know -- "I didn't mean 'how do *I* implement it,' I meant 'are *you* going to implement it.'" And the answer there is probably not, not unless someone like you gets the ball rolling in the above fashion. From gnupg at tim.thechases.com Wed Apr 2 03:01:28 2014 From: gnupg at tim.thechases.com (Tim Chase) Date: Tue, 1 Apr 2014 20:01:28 -0500 Subject: Encrypted file-size approximation with multiple recipients Message-ID: <20140401200128.46b62b28@bigbox.christie.dr> I've been trying to find a good explanation on how something like gpg -r DEADBEEF -r CAFEBABE -r 8BADFOOD -o output.gpg -e input.txt works. The best I've been able to find is this: http://lists.gnupg.org/pipermail/gnupg-users/2007-October/031938.html I'm mostly interested in the overhead, so I set up 4 distinct homedirs for testing. It looks like each additional recipient adds about 271 bytes (though one of them only has an extra 270 bytes), and there's a per-file overhead of about 66 or 67 bytes. So from my experimentation, the final file-size ends up being something like input_file_size + 67 + (271 * recipient_count) but I'm not sure how much that might change based on conditions I'm not taking into consideration (all my test GPG users were just gpg1 at example.com, gpg2 at example.com, etc), all with 2048-bit keys. Is there a more formal formula that can be used to approximate the overhead of multi-recipient encryption? Thanks, -tkc From sam.mxracer at gmail.com Wed Apr 2 04:45:17 2014 From: sam.mxracer at gmail.com (Sam Gleske) Date: Tue, 01 Apr 2014 22:45:17 -0400 Subject: Encrypted file-size approximation with multiple recipients In-Reply-To: <20140401200128.46b62b28@bigbox.christie.dr> References: <20140401200128.46b62b28@bigbox.christie.dr> Message-ID: <184888cc-0718-46f9-8425-33a30d108a3a@email.android.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On April 1, 2014 9:01:28 PM EDT, Tim Chase wrote: >I've been trying to find a good explanation on how something like > > gpg -r DEADBEEF -r CAFEBABE -r 8BADFOOD -o output.gpg -e input.txt > >works. The best I've been able to find is this: > >http://lists.gnupg.org/pipermail/gnupg-users/2007-October/031938.html > >I'm mostly interested in the overhead, so I set up 4 distinct >homedirs for testing. It looks like each additional recipient adds >about 271 bytes (though one of them only has an extra 270 bytes), and >there's a per-file overhead of about 66 or 67 bytes. > >So from my experimentation, the final file-size ends up being >something like > > input_file_size + 67 + (271 * recipient_count) > >but I'm not sure how much that might change based on conditions I'm >not taking into consideration (all my test GPG users were just >gpg1 at example.com, gpg2 at example.com, etc), all with 2048-bit keys. > >Is there a more formal formula that can be used to approximate the >overhead of multi-recipient encryption? > >Thanks, > >-tkc After reading in the gpg man page different recipients can have different key sizes. Additionally gpg will look at the supported cipher algorthms of all recipients and attempt to choose an algorithm common between them. That means your calculations aren't accounting for the different key sizes nor is it accounting for the size of the session key (session key is for the symmetric algo). You can go about this one of two ways. You can try write a program smart enough to account for that or you can keep it simple. KISS: assume worst case for every recipient and then do the math. e.g. 4096 bit rsa keys with AES256 cipher algo for the session key (assuming AES256 has the largest session key). At least that's how I would tackle it. SAM - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQJABAEBCgAqBQJTO3m9IxxTYW0gR2xlc2tlIDxzYW0ubXhyYWNlckBnbWFpbC5j b20+AAoJEOj3MjRyV+ZfwtgP/2USc47Fsf6zk6qEq/ZbImdIhjZubhx8CDomkTz7 GKXzOGwHpWVC+WtUNI9Dm8L1LKe4vT/WBTbjLIMqF963ds4MAR5abQk/aRsf8COV pkjuY+FYEkcyQC0+1RWVQBakxm7Vp3WVLOOO5rlaj/5DULYhYiM7tEYPNR+Zk3ew dxf/27we6OTzWClVwGEYQ0R4uIyo5f7OyRpzLrRgvWZhds8zQW1ha2oNMQLupHll ZCibhNQ7W0rROqqk755c8lvlCSHz61g3IDvGQlpFWqo3iRVLJcW1/qa2Nz0Q0W3G M/CK7kW1R51Wp0/esN0qNo5+lFyt60c3BQSFBBm1RS7T72bo34KIjY0G9ytccaIp WhyTkVKZMx+kgpuFWsE5Ege+q42Wii3cNf1si0O2Iz72w9ckLBcNHj5ax1ndIm5o Ir1jx759+yPd2Jg+ctOeY+XKXOMgHxOygYRX6IPUYqm5+4aO4pUijIs5s6wge1+7 okseitw7/qvX0i7jr0DKLXUDYVYuuBvaBWiJs5gtJeKMFTl/tR5qLV4A0hTdKdPw 2p4Eb9Nm/w5FYUbQq/yAFpD2HHEN3MmCE40zpAGaDAGWCTN7FrJFo9tWhenyenhi bL0YPZ/OCeoFlg9QodaXiNLy5DwBp5DKx0dgJmxrAPU7LE7I5h/cGe3ShXelqxRq auFu =ku2m -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Wed Apr 2 06:37:22 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 2 Apr 2014 00:37:22 -0400 Subject: Encrypted file-size approximation with multiple recipients In-Reply-To: <20140401200128.46b62b28@bigbox.christie.dr> References: <20140401200128.46b62b28@bigbox.christie.dr> Message-ID: <015D1F30-1587-470E-860B-DDFC899BECF3@jabberwocky.com> On Apr 1, 2014, at 9:01 PM, Tim Chase wrote: > I've been trying to find a good explanation on how something like > > gpg -r DEADBEEF -r CAFEBABE -r 8BADFOOD -o output.gpg -e input.txt > > works. The best I've been able to find is this: > > http://lists.gnupg.org/pipermail/gnupg-users/2007-October/031938.html > > I'm mostly interested in the overhead, so I set up 4 distinct > homedirs for testing. It looks like each additional recipient adds > about 271 bytes (though one of them only has an extra 270 bytes), and > there's a per-file overhead of about 66 or 67 bytes. > > So from my experimentation, the final file-size ends up being > something like > > input_file_size + 67 + (271 * recipient_count) > > but I'm not sure how much that might change based on conditions I'm > not taking into consideration (all my test GPG users were just > gpg1 at example.com, gpg2 at example.com, etc), all with 2048-bit keys. This can change pretty significantly given different key lengths, different algorithms, and perhaps most significantly, how compressible the original document is (by default GPG compresses data before encryption). An input file of text will compress very differently than an input file that's a jpeg (as jpegs are already compressed, and so do not benefit much from a second layer of compression). > Is there a more formal formula that can be used to approximate the > overhead of multi-recipient encryption? Not really. If you constrain the problem as you have (everyone gets 2048 bit keys, etc), and constrain the input to a particular type of data, you can get a better approximation, but as soon as you open the problem up, the file sizes vary. David From johanw at vulcan.xs4all.nl Wed Apr 2 07:33:32 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 02 Apr 2014 07:33:32 +0200 Subject: post-quantum computing in GnuPG In-Reply-To: <533B4F0D.90901@sixdemonbag.org> References: <533B4F0D.90901@sixdemonbag.org> Message-ID: <533BA12C.8020507@vulcan.xs4all.nl> On 02-04-2014 1:43, Robert J. Hansen wrote: > I know, I know -- "I didn't mean 'how do *I* implement it,' I meant 'are > *you* going to implement it.'" And the answer there is probably not, > not unless someone like you gets the ball rolling in the above fashion. Or someone builds a working quantum computer with many bits and demonstrate a working decryption of RSA-2048 in a few seconds. :-) -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Wed Apr 2 08:50:19 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 02 Apr 2014 02:50:19 -0400 Subject: post-quantum computing in GnuPG In-Reply-To: <533BA12C.8020507@vulcan.xs4all.nl> References: <533B4F0D.90901@sixdemonbag.org> <533BA12C.8020507@vulcan.xs4all.nl> Message-ID: <533BB32B.2030605@sixdemonbag.org> > Or someone builds a working quantum computer with many bits and > demonstrate a working decryption of RSA-2048 in a few seconds. :-) Well, you'd need 4096 qubits in the ensemble, representing a state space of something like 10^1233 (not a typo). At that point I'm going to just give up and offer my services to our new Space Overlords from Zarbnulax Prime. Maybe if I help round up pesky humans they'll give me a ride in their FTL spaceships! :) From bw at norbl.com Wed Apr 2 10:02:24 2014 From: bw at norbl.com (Barnet Wagman) Date: Wed, 02 Apr 2014 01:02:24 -0700 Subject: How does gnupng create keys? Message-ID: <533BC410.9090609@norbl.com> I'd like to know something about how gnupng create keys (for symmetric encryption). I'm not looking for details, just an overview of how it's done. Does anyone know of any documentation on this? I haven't found any yet. thanks From cwal989 at comcast.net Wed Apr 2 10:54:51 2014 From: cwal989 at comcast.net (Christopher J. Walters) Date: Wed, 02 Apr 2014 04:54:51 -0400 Subject: post-quantum computing in GnuPG In-Reply-To: <533BB32B.2030605@sixdemonbag.org> References: <533B4F0D.90901@sixdemonbag.org> <533BA12C.8020507@vulcan.xs4all.nl> <533BB32B.2030605@sixdemonbag.org> Message-ID: <533BD05B.6080205@comcast.net> On 4/2/2014 2:50 AM, Robert J. Hansen wrote: >> Or someone builds a working quantum computer with many bits and >> demonstrate a working decryption of RSA-2048 in a few seconds. :-) Not likely in the near term... Maybe in 5000 years or so, but by then I suspect computing as we know it will be ancient history (actually it *would* be)... > Well, you'd need 4096 qubits in the ensemble, representing a state space > of something like 10^1233 (not a typo). That's a LOT of zeroes. Maybe my initial estimate was off by several dozen orders of magnitude... > At that point I'm going to just give up and offer my services to our new > Space Overlords from Zarbnulax Prime. Maybe if I help round up pesky > humans they'll give me a ride in their FTL spaceships! LMAO! I got a good laugh out of this one. Thanks, I needed that... > > :) Chris From konrad.vrba at gmail.com Wed Apr 2 15:27:59 2014 From: konrad.vrba at gmail.com (Konrad Vrba) Date: Wed, 2 Apr 2014 15:27:59 +0200 Subject: gpg: NOTE: trustdb not writable Message-ID: Hello, I am using gpg on a system, which is mounted read-only. When I do the following: echo "hello" | gpg --lock-never --no-verbose -e -s -a -r user at example.com I get an error: gpg: NOTE: trustdb not writable I don't understand why gpg should need write access inside user home, for normal operation. Is thre a way to stop this error message? thanks, Konrad -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg at tim.thechases.com Wed Apr 2 19:07:20 2014 From: gnupg at tim.thechases.com (Tim Chase) Date: Wed, 2 Apr 2014 12:07:20 -0500 Subject: Encrypted file-size approximation with multiple recipients In-Reply-To: <015D1F30-1587-470E-860B-DDFC899BECF3@jabberwocky.com> References: <20140401200128.46b62b28@bigbox.christie.dr> <015D1F30-1587-470E-860B-DDFC899BECF3@jabberwocky.com> Message-ID: <20140402120720.3ac7dcf2@bigbox.christie.dr> On 2014-04-02 00:37, David Shaw wrote: > This can change pretty significantly given different key lengths, > different algorithms, and perhaps most significantly, how > compressible the original document is (by default GPG compresses > data before encryption). An input file of text will compress very > differently than an input file that's a jpeg (as jpegs are already > compressed, and so do not benefit much from a second layer of > compression). Thanks both to David & Sam for their replies. While not exact answers/formulas, they were both quite helpful: 1) I'd missed that GPG conveniently compresses the data before encrypting which would explain some of the differences I saw. 2) getting a rough worst-case bound (larger RSA keys and algorithm choice can impact) for per-recipient overhead. It also helps come to terms with the fact that, in more than half of my use cases (small plain-text/JSON messages), the multi-recipient overhead will swamp the size of the actual compressed+encrypted content. A fact that I can live with, but is nice to know up front. Given that the recipients are in pre-defined groups would it make more sense to multi-recipient-encrypt a single unique group-key, and then encrypt all messages for that group with the given key? I do see the possibility of a trust-leak where a group member could decrypt the group key and then provide it to other non-group members, but if that's the case, the untrustworthy group member could just decrypt the messages and provide those directly. That's a risk I'm willing to accept. Since it's wrapped in my program/code, I can automate the group-key fetching from a UI perspective. I'm mostly interested in things like regenerating the group key when group members are removed, or adding additional group members to an existing key, as well as any "good golly, man, that's idiotic because of XYZ" warnings it might entail. Thanks, -Tim From vedaal at nym.hush.com Wed Apr 2 19:55:21 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Wed, 02 Apr 2014 13:55:21 -0400 Subject: Using an RSA GnuPG key for RSA ? Message-ID: <20140402175521.53CD8C0455@smtp.hushmail.com> Is it possible to generate an RSA key in GnuPG, and then use it (not in GnuPG, but in other systems using RSA keys), to encrypt and decrypt RSA messages? If so, what portion of the GnuPG generated RSA key functions as a 'pure' RSA key? (Is it isolatable by using --list-packets on the key?) TIA, vedaal From wk at gnupg.org Wed Apr 2 22:51:02 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Apr 2014 22:51:02 +0200 Subject: How does gnupng create keys? In-Reply-To: <533BC410.9090609@norbl.com> (Barnet Wagman's message of "Wed, 02 Apr 2014 01:02:24 -0700") References: <533BC410.9090609@norbl.com> Message-ID: <87r45fjw09.fsf@vigenere.g10code.de> On Wed, 2 Apr 2014 10:02, bw at norbl.com said: > I'd like to know something about how gnupng create keys (for symmetric > encryption). I'm not looking for details, just an overview of how > it's done. Does anyone know of any documentation on this? I haven't > found any yet. The Libgcrypt manual has a description of its architecture [1]. GnuPG uses Libgcrypt and thus that library is responsible for creating RSA keys. Libgcrypt is actually code stripped from an older version of GnuPG, but the basic operation is even the same in the old versions (i.e. GnuPG <= 1.4). Shalom-Salam, Werner [1] http://gnupg.org/documentation/manuals/gcrypt/Architecture.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ekleog at gmail.com Wed Apr 2 21:14:48 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Wed, 2 Apr 2014 21:14:48 +0200 Subject: Using an RSA GnuPG key for RSA ? In-Reply-To: <20140402175521.53CD8C0455@smtp.hushmail.com> References: <20140402175521.53CD8C0455@smtp.hushmail.com> Message-ID: <20140402191448.GC3793@leortable> On Wed, Apr 02, 2014 at 01:55:21PM -0400, vedaal at nym.hush.com wrote: > Is it possible to generate an RSA key in GnuPG, and then use it (not in GnuPG, but in other systems using RSA keys), to encrypt and decrypt RSA messages? > > If so, what portion of the GnuPG generated RSA key functions as a 'pure' RSA key? > (Is it isolatable by using --list-packets on the key?) > > TIA, > > vedaal If you are not to use the key in gnupg, why make gnupg generate it in the first place? Why not use the program with which you'll use the key to generate it? Or, if the program does not offer this functionality, why not use openssl, which provides this capability on purpose? Were you to use the key both for gnupg and other systems, I would understand, but doing things this way...? Cheers, Leo From florian at florian-wolters.de Thu Apr 3 14:42:05 2014 From: florian at florian-wolters.de (Florian Wolters) Date: Thu, 3 Apr 2014 14:42:05 +0200 Subject: Chipdrive SPR 532 and OpenPGP Card with 4096Bit RSA Keys Message-ID: <20140403124204.GB11096@miraculix.wolters.lan> Hello, I bought a Chipdrive SPR 532 (aka Pinpad Pro) to read and write my PGP RSA Keys on the OpenPGP smartcard V2. The reader is connected to a PC running Ubuntu Linux 13.10. I passed all that gpg-agent vs. gnome-keyring manager stuff successfully. The problem is that I cannot authenticate an SSH login using a smartcard that I previously wrote the key to (with another smartcard reader). It fails after I entered the PIN. The next try write my PGP key to the card also presented an "operation failed" error. Does this smartcard reader not work in combination with 4096Bit RSA keys? I already tried to update the firmware on the device (currently 4.51 or so) to 5.10 but the update program also fails with an error message saying nothing about the reason. Has anyone this combination up and running and could point me into the right direction to get this working? Any help is appreciated. Thanks for reading. Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From sam.mxracer at gmail.com Thu Apr 3 16:39:28 2014 From: sam.mxracer at gmail.com (Sam Gleske) Date: Thu, 3 Apr 2014 10:39:28 -0400 Subject: Using an RSA GnuPG key for RSA ? In-Reply-To: <20140402191448.GC3793@leortable> References: <20140402175521.53CD8C0455@smtp.hushmail.com> <20140402191448.GC3793@leortable> Message-ID: On Wed, Apr 2, 2014 at 3:14 PM, Leo Gaspard wrote: > Were you to use the key both for gnupg and other systems, I would > understand, > but doing things this way...? > I think generally it would be bad practice either way. A compromised server happens more often than a compromised gpg key. Therefore if a server gets compromised effectively your gpg private key has been compromised. It would be best to keep them separate entirely and not reuse the RSA key pair anywhere else. Treat your gpg private key like your identity (i.e. social security number) because it really is your identity... unless you want to go through the hassle of generating a new key and having your web of trust go through the hassle of resigning it when your RSA key gets compromised on a server. openssl tools are simple enough that generating throw away RSA keys is a no brainer. The same goes for most applications that support RSA keys. SAM -------------- next part -------------- An HTML attachment was scrubbed... URL: From timprepscius at gmail.com Thu Apr 3 21:06:57 2014 From: timprepscius at gmail.com (Tim Prepscius) Date: Thu, 3 Apr 2014 15:06:57 -0400 Subject: checking signature of pgp mime Message-ID: Greetings, So as I said before, I'm working on a pgp base web mail app: https://github.com/timprepscius/mv I am having problems validating the signature of a small percentage of test cases. However GPG with apple-mail says the signatures checkout, soo... I'm obviously doing something incorrectly. Is there developer of gpg-apple-mail who could let me know, given a specific example, what the actual block is which has been signed (including whitespace/line endings/etc). (I think if I could solve one problematic example, it would enable me to solve the others.) An example problematic email is this: http://pastebin.com/raw.php?i=1zm9sdcE This is the derived block: (I send this into openpgpjs) http://pastebin.com/raw.php?i=XThs22KR -tim From bw at norbl.com Thu Apr 3 23:21:08 2014 From: bw at norbl.com (Barnet Wagman) Date: Thu, 03 Apr 2014 14:21:08 -0700 Subject: Length for AES256 symmetric encryption passphrase? Message-ID: <533DD0C4.1080503@norbl.com> This a rather naive question, but I haven't found and answer to it. When doing symmetric encryption with AES256, is there any reason to have a passphrase that exceeds 32 characters (since that's the length of the AES key)? thanks From sam.mxracer at gmail.com Thu Apr 3 23:27:48 2014 From: sam.mxracer at gmail.com (Sam Gleske) Date: Thu, 3 Apr 2014 17:27:48 -0400 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: <533DD0C4.1080503@norbl.com> References: <533DD0C4.1080503@norbl.com> Message-ID: You're making the assumption that 32 ASCII characters can produce every possible binary combination in 256 bits. I don't know how AES handles password phrases longer than 32 bytes but the key can be stronger I'd imagine with more random data as the key. I'm simply presuming. On Thu, Apr 3, 2014 at 5:21 PM, Barnet Wagman wrote: > This a rather naive question, but I haven't found and answer to it. When > doing symmetric encryption with AES256, is there any reason to have a > passphrase that exceeds 32 characters (since that's the length of the AES > key)? > > thanks > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Apr 3 23:28:58 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 03 Apr 2014 23:28:58 +0200 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: References: <533DD0C4.1080503@norbl.com> Message-ID: <533DD29A.2090305@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/03/2014 11:27 PM, Sam Gleske wrote: > You're making the assumption that 32 ASCII characters can produce > every possible binary combination in 256 bits. I don't know how > AES handles password phrases longer than 32 bytes but the key can > be stronger I'd imagine with more random data as the key. I'm > simply presuming. > You'd want a key derivative function that produce an output of 32 bytes to use as the actual AES key. But you are indeed correct in the point that what matter is the amount of entropy provided by the passphrase. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Varitatio delectat Change pleases -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTPdKWAAoJEPw7F94F4TagiX0P/2FQ3P0tcmK8FxpBJXHXuWMN FzKl61Vmh8PJ+EGfRGMGPnvWgRgbKYARTlc8iLCxfxqv4TKoZD382e3KJmAyceWU 6MgGtGImmKsDprfxJA3re8xndv5gPQE6E34ar/qfQWcm68z64nA7n8+vfaVdLzQ4 iLdnVjk46OdYpHLupgdfT27949vPwhbcZem1m1PrXLDMyn8Ir5y8Kahg2MA7r8G6 /BpkdHvU4weIdGmNR9sg2PJu651RbOZGL7mqezhg+4Kj74U3tYG3QcPH+UKrNjq3 dRggxowMiX5rXAHyEH8UufnihjnlqMe2pzPr7WRpqp8zkrlsg/BRa1awyzIiheBu 3poiQ7Lo0dbLe0zoSUJAGKiW1E7Mjh4KGfT4AKBq/NACbqAYqDjd5Ex+fwPZMbFv Q0uhPFNkIV92ndXvYxnfLtL78qw8fzOt9/JwXJSQ+sfjxLdNz8JigDNiShfktLhI N9v9OehPRpUVILPrzgcSWB5o24Rcf1pLZL1w/hrioIJpVeMSUAmnMMcYvSAGFfJB bpCKE2BYAmx9TbcrJo/3oeBHwFql7h2ovpwTvbydjic5YvX/oe/xvzOJN6A2KjIQ fQSymNgQF0wboaAnpLXvvqy0aTZErf37JbtimEemqN7n1hbdgxUeFpn7Vgm8op1d j6zFfeqe1Y+uIRcboCXp =YzbE -----END PGP SIGNATURE----- From kloecker at kde.org Fri Apr 4 00:28:34 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 4 Apr 2014 00:28:34 +0200 Subject: checking signature of pgp mime In-Reply-To: References: Message-ID: <2648021.1WqSV7HOOE@thufir.ingo-kloecker.de> On Thursday 03 April 2014 15:06:57 Tim Prepscius wrote: > Greetings, > > So as I said before, I'm working on a pgp base web mail app: > https://github.com/timprepscius/mv > > I am having problems validating the signature of a small percentage of > test cases. However GPG with apple-mail says the signatures > checkout, soo... I'm obviously doing something incorrectly. KMail also says that the signature matches. Looking at the two pastbins, it seems that you are trying to convert OpenPGP/MIME-signed messages to RFC 4880-style cleartext signed messages in order to verify the signatures. This transformation is not always possible. In this particular case the signed data contains trailing whitespace. If the sender (resp. his mail client) would have followed the RFC 3156 then this trailing whitespace wouldn't be there. But it's there. And that's what causing the trouble because the signature of a cleartext signed message is computed with trailing whitespace removed. That's why the signature does not match. You have to verify the signature the way one verifies signed data with detached signature. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dougb at dougbarton.us Fri Apr 4 04:54:05 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 03 Apr 2014 19:54:05 -0700 Subject: checking signature of pgp mime In-Reply-To: References: Message-ID: <533E1ECD.1020208@dougbarton.us> On 04/03/2014 12:06 PM, Tim Prepscius wrote: > Greetings, > > So as I said before, I'm working on a pgp base web mail app: > https://github.com/timprepscius/mv > > I am having problems validating the signature of a small percentage of > test cases. However GPG with apple-mail says the signatures checkout, > soo... I'm obviously doing something incorrectly. > > Is there developer of gpg-apple-mail who could let me know, given a > specific example, what the actual block is which has been signed > (including whitespace/line endings/etc). (I think if I could solve > one problematic example, it would enable me to solve the others.) > > > > An example problematic email is this: > http://pastebin.com/raw.php?i=1zm9sdcE > > This is the derived block: (I send this into openpgpjs) > http://pastebin.com/raw.php?i=XThs22KR When dealing with Apple it's not you who is doing things incorrectly with PGP-MIME messages, it's them. And to make it more exciting, they do it wrong several different ways. :) Take a look at https://dougbarton.us/PGP/ppf/index.html, particularly the ppf_verify script. It has a bunch of exceptional cases on how to mangle (or un-mangle if you prefer) various formats of PGP-MIME in order for the signatures to verify. hope this helps, Doug From bw at norbl.com Fri Apr 4 07:45:26 2014 From: bw at norbl.com (Barnet Wagman) Date: Thu, 03 Apr 2014 22:45:26 -0700 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: <533DD29A.2090305@sumptuouscapital.com> References: <533DD0C4.1080503@norbl.com> <533DD29A.2090305@sumptuouscapital.com> Message-ID: <533E46F6.4000006@norbl.com> > You'd want a key derivative function that produce an output of 32 > bytes to use as the actual AES key. But you are indeed correct in the > point that what matter is the amount of entropy provided by the > passphrase. > > How long a passphrase is recommended for generating a 32 byte (AES) key? I'll probably generate the passkey programmatically, so typing an human memory are not issues. From rjh at sixdemonbag.org Fri Apr 4 08:04:14 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 04 Apr 2014 02:04:14 -0400 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: <533DD0C4.1080503@norbl.com> References: <533DD0C4.1080503@norbl.com> Message-ID: <533E4B5E.9060107@sixdemonbag.org> > This a rather naive question, but I haven't found and answer to it. When > doing symmetric encryption with AES256, is there any reason to have a > passphrase that exceeds 32 characters (since that's the length of the > AES key)? Yes. English has about 1.5 bits of entropy per symbol. A 32-character passphrase could thus be any of about a trillion different things. That's a 1 followed by 12 zeroes. A 256-bit keyspace is so huge English can't describe it. It's a 1 followed by 77 zeroes. The difference between the two is sort of like comparing a lit match to Supernova 1987A. The difference is on that level of mind-boggling vastness. Using plain English for the passphrase, a 170-character passphrase is necessary to provide a full 256 bits of entropy. From rjh at sixdemonbag.org Fri Apr 4 08:06:02 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 04 Apr 2014 02:06:02 -0400 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: <533E46F6.4000006@norbl.com> References: <533DD0C4.1080503@norbl.com> <533DD29A.2090305@sumptuouscapital.com> <533E46F6.4000006@norbl.com> Message-ID: <533E4BCA.1090704@sixdemonbag.org> > How long a passphrase is recommended for generating a 32 byte (AES) key? Depends on how you generate it and how much entropy you want. For my high-security passphrases I grab 16 bytes (128 bits) from /dev/urandom and base64-encode it. Works great for me and provides an excellent security margin. From sam.mxracer at gmail.com Fri Apr 4 16:46:52 2014 From: sam.mxracer at gmail.com (Sam Gleske) Date: Fri, 4 Apr 2014 10:46:52 -0400 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: <533E4B5E.9060107@sixdemonbag.org> References: <533DD0C4.1080503@norbl.com> <533E4B5E.9060107@sixdemonbag.org> Message-ID: On Fri, Apr 4, 2014 at 2:04 AM, Robert J. Hansen wrote: > Using plain English for the passphrase, a 170-character passphrase is > necessary to provide a full 256 bits of entropy. > Interesting math. However, I believe the OP mentioned they're generating the password and storing so human readable, i.e. English, isn't an issue. What would be the recommended length for completely random characters generated, for example, by a password manager such as keepassx? SAM -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.mxracer at gmail.com Fri Apr 4 16:48:26 2014 From: sam.mxracer at gmail.com (Sam Gleske) Date: Fri, 4 Apr 2014 10:48:26 -0400 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: References: <533DD0C4.1080503@norbl.com> <533E4B5E.9060107@sixdemonbag.org> Message-ID: On Fri, Apr 4, 2014 at 10:46 AM, Sam Gleske wrote: > > On Fri, Apr 4, 2014 at 2:04 AM, Robert J. Hansen wrote: > >> Using plain English for the passphrase, a 170-character passphrase is >> necessary to provide a full 256 bits of entropy. >> > > Interesting math. However, I believe the OP mentioned they're generating > the password and storing so human readable, i.e. English, isn't an issue. > What would be the recommended length for completely random characters > generated, for example, by a password manager such as keepassx? > To clarify and be more specific... if one were using the password as the symmetric key in the GPG software (libcrypt)? Or perhaps even just using openssl tools? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekleog at gmail.com Fri Apr 4 18:17:15 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Fri, 4 Apr 2014 18:17:15 +0200 Subject: Using an RSA GnuPG key for RSA ? In-Reply-To: <20140403135618.5F823206E7@smtp.hushmail.com> References: <20140402175521.53CD8C0455@smtp.hushmail.com> <20140402191448.GC3793@leortable> <20140403135618.5F823206E7@smtp.hushmail.com> Message-ID: <20140404161715.GD3793@leortable> On Thu, Apr 03, 2014 at 09:56:18AM -0400, vedaal at nym.hush.com wrote: > On Wednesday, April 02, 2014 at 5:41 PM, "Leo Gaspard" wrote: > > >If you are not to use the key in gnupg, why make gnupg generate it > >in the first > >place? Why not use the program with which you'll use the key to > >generate it? > > ===== > > Where in the post did you get the idea that I would not? > > I trust GnuPG's generation of keys, but prefer not to trust closed source programs generating RSA keys. > I would like to use my GnuPG RSA key, easily available on keyservers, for other RSA functions. > > > vedaal (As you didn't answer to list, I'm not cutting. Hope you didn't mean it to be a private message, but it clearly didn't seem like one.) Well... I inferred it from "use it (not in GnuPG, but in other systems using RSA keys)", from your first message. Anyway, as Sam puts it, you'd be better not putting your RSA key everywhere. And... You say you do not trust closed source programs for key generation, but does that mean you trust them for key usage? Otherwise, you could just as well throw your key to the dustbin. What I could propose would be to : * Make a gpg key, master key, airgapped, etc. * On each system on which you mean to use cryptography, generate a keypair using the program with which you are going to use it (or possible openssl, if the program does not generate keys). * Sign the public key of each keypair with your gpg key. As it is not a stricto sensu pgp key, sign the armored key as a plaintext message, if possible with a preceding comment explaining what it is to be used for. * Publish these signatures somewhere easily found. * If you want so, encrypt the private key with your mainkey and store it somewhere safe enough (it's encrypted, after all). This way, each keypair gets the maximum security it can have : the security of the application using the private keypart. (Actually, if you choose to keep an encrypted backup, you also need to keep the mainkey safe, but that's supposed as being the most protected part of the whole setup, so...) What do you think about it? Leo From rjh at sixdemonbag.org Fri Apr 4 19:10:55 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 04 Apr 2014 10:10:55 -0700 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: References: <533DD0C4.1080503@norbl.com> <533E4B5E.9060107@sixdemonbag.org> Message-ID: <20140404101055.Horde.bIXzyjMnYN6bFPb3VaAliQ1@mail.sixdemonbag.org> > Interesting math. However, I believe the OP mentioned they're generating > the password and storing so human readable, i.e. English, isn't an issue. > What would be the recommended length for completely random characters > generated, for example, by a password manager such as keepassx? Your questions are not clear enough to be answered. "What would the recommended length for completely random characters generated, for example, by a password manager such as keepassx? If one were using the password as the symmetric key in libgcrypt? Or perhaps even just using openssl tools?" 1. Well, which password managers? Just because a character is completely random tells me nothing about how much entropy is contained in each symbol. "TTHTHHTTH" is a completely random sequence (generated it just now by flipping a fair coin), but it only has one bit of entropy per symbol. "fBTvC" is a completely non-random sequence, but it has a lot more entropy per symbol. Without knowing how a random password is generated I can't answer this. 2. Recommended for what purpose? 256 bits of entropy is wild overkill for almost all purposes. 128 bits of entropy is generally speaking plenty. 3. Which toolkit? libgcrypt and openssl are two completely different toolkits that work in completely different ways, and an answer appropriate for one might not be appropriate for the other. 4. What is it you really want to know? You already know: AES depends on having a 32-bit key which can support up to 256 bits of entropy. You've been told two good metrics for estimating entropy in a passphrase: 1.5 bits per glyph of English text, 5 bits per glyph of base-64ed random data. From sam.mxracer at gmail.com Fri Apr 4 19:20:57 2014 From: sam.mxracer at gmail.com (Sam Gleske) Date: Fri, 4 Apr 2014 13:20:57 -0400 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: <20140404101055.Horde.bIXzyjMnYN6bFPb3VaAliQ1@mail.sixdemonbag.org> References: <533DD0C4.1080503@norbl.com> <533E4B5E.9060107@sixdemonbag.org> <20140404101055.Horde.bIXzyjMnYN6bFPb3VaAliQ1@mail.sixdemonbag.org> Message-ID: On Fri, Apr 4, 2014 at 1:10 PM, Robert J. Hansen wrote: > 4. What is it you really want to know? You already know: AES depends on > having a 32-bit key which can support up to 256 bits of entropy. You've > been told two good metrics for estimating entropy in a passphrase: 1.5 bits > per glyph of English text, 5 bits per glyph of base-64ed random data. > Just to be clear I'm not the OP so you don't accidentally confuse my question with theirs. My original doesn't serve a purpose because I use GPG for encrypting my files and leave it up to that and don't normally use AES directly. My question was merely a curiosity so you can take it for what it is. Specifically, I said the password manager was keepassx for password generation. I realize that GPG and openssl are entirely different. Perhaps my question was too broad with too many variables to be properly answered by a single person and should have been broken up into different parts to appropriate audiences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vedaal at nym.hush.com Fri Apr 4 19:32:47 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Fri, 04 Apr 2014 13:32:47 -0400 Subject: Using an RSA GnuPG key for RSA ? In-Reply-To: <20140404161715.GD3793@leortable> References: <20140402175521.53CD8C0455@smtp.hushmail.com> <20140402191448.GC3793@leortable> <20140403135618.5F823206E7@smtp.hushmail.com> <20140404161715.GD3793@leortable> Message-ID: <20140404173248.43DA2C0455@smtp.hushmail.com> On Friday, April 04, 2014 at 12:49 PM, "Leo Gaspard" wrote:On Thu, Apr 03, 2014 at 09:56:18AM -0400, vedaal at nym.hush.com wrote: > On Wednesday, April 02, 2014 at 5:41 PM, "Leo Gaspard" wrote: > > >If you are not to use the key in gnupg, why make gnupg generate it > >in the first > >place? Why not use the program with which you'll use the key to > >generate it? > > ===== > > Where in the post did you get the idea that I would not? > > I trust GnuPG's generation of keys, but prefer not to trust closed source programs generating RSA keys. > I would like to use my GnuPG RSA key, easily available on keyservers, for other RSA functions. > > > vedaal >And... You say you do not trust closed source programs for key generation, but does that mean you trust them for key usage? ===== I trust them to encrypt to my public key, and was planning to work out a system where I could decrypt on my own without it going through them. (they could have my public key, and verify my RSA signature). [All this is in the theoretical planning stage ;-) first I would need to be able to isolate my RSA part of my GnuPG key and see if it can be used with an open source simple RSA program offline. That was my original question.] vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpuls at kcore.de Fri Apr 4 18:57:08 2014 From: rpuls at kcore.de (=?UTF-8?B?UmVuw6k=?= Puls) Date: Fri, 4 Apr 2014 18:57:08 +0200 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: References: <533DD0C4.1080503@norbl.com> <533E4B5E.9060107@sixdemonbag.org> Message-ID: <20140404185708.7785f02b@kcore.de> On Fri, 4 Apr 2014 10:48:26 -0400 Sam Gleske wrote: > > What would be the recommended length for > > completely random characters generated, for example, by a password > > manager such as keepassx? > > > > To clarify and be more specific... if one were using the password as > the symmetric key in the GPG software (libcrypt)? Or perhaps even > just using openssl tools? I use this formula for my own random passwords: L = Log(2^N) / Log(E) L is the suggested length of the password N is the key size in bits E is the number of possible characters For a mixed-case alphanumeric password, E is 62 (2*26 letters plus 10 digits). To create a random password equivalent in strength to a 128-bit key, you need Log(2^128) / Log(62) or about 22 characters. For a 256-bit key, you need about 43 characters. If you use a passphrase system like Diceware, take the number of different words in the word list (7776 for standard Diceware) as E, and the resulting L as the number of words in your passphrase. So using the formula above, you need Log(2^128) / Log(7776) or about 10 words for a 128-bit key and about 20 words for a 256-bit key. Of course, the way you generate, distribute, store, enter and verify your passwords is probably far more important, so consider this formula more like an upper bound on useful password lengths. :-) Ren? (not a mathematician or cryptographer) From bw at norbl.com Fri Apr 4 20:35:20 2014 From: bw at norbl.com (Barnet Wagman) Date: Fri, 04 Apr 2014 11:35:20 -0700 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: <20140404101055.Horde.bIXzyjMnYN6bFPb3VaAliQ1@mail.sixdemonbag.org> References: <533DD0C4.1080503@norbl.com> <533E4B5E.9060107@sixdemonbag.org> <20140404101055.Horde.bIXzyjMnYN6bFPb3VaAliQ1@mail.sixdemonbag.org> Message-ID: <533EFB68.8060805@norbl.com> To be clear, I want to use gnupgp to do symmetric encryption using AES256. As I understand it, the 'gpg -symmetric ...' command converts a pass phrase into a key, a 32 byte key in the case of AES256. I /assume/ that this conversion is 'deterministic' since as far as I can tell, the 'gpg -symmetric ...' does not store the key it generates. Correct me if I'm wrong. I am trying to decide how long a pass phrase to use. I have not decided how to generate the pass phrase. Assume that it is pseudo-randomly chosen from the an english language character set. On 4/4/14, 10:10 AM, Robert J. Hansen wrote: >> Interesting math. However, I believe the OP mentioned they're >> generating >> the password and storing so human readable, i.e. English, isn't an >> issue. >> What would be the recommended length for completely random characters >> generated, for example, by a password manager such as keepassx? > > Your questions are not clear enough to be answered. > > "What would the recommended length for completely random characters > generated, for example, by a password manager such as keepassx? If > one were using the password as the symmetric key in libgcrypt? Or > perhaps even just using openssl tools?" > > 1. Well, which password managers? Just because a character is > completely random tells me nothing about how much entropy is contained > in each symbol. "TTHTHHTTH" is a completely random sequence > (generated it just now by flipping a fair coin), but it only has one > bit of entropy per symbol. "fBTvC" is a completely non-random > sequence, but it has a lot more entropy per symbol. Without knowing > how a random password is generated I can't answer this. > > 2. Recommended for what purpose? 256 bits of entropy is wild > overkill for almost all purposes. 128 bits of entropy is generally > speaking plenty. > > 3. Which toolkit? libgcrypt and openssl are two completely different > toolkits that work in completely different ways, and an answer > appropriate for one might not be appropriate for the other. > > 4. What is it you really want to know? You already know: AES depends > on having a 32-bit key which can support up to 256 bits of entropy. > You've been told two good metrics for estimating entropy in a > passphrase: 1.5 bits per glyph of English text, 5 bits per glyph of > base-64ed random data. > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekleog at gmail.com Fri Apr 4 21:13:23 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Fri, 4 Apr 2014 21:13:23 +0200 Subject: Using an RSA GnuPG key for RSA ? In-Reply-To: <20140404173248.43DA2C0455@smtp.hushmail.com> References: <20140402175521.53CD8C0455@smtp.hushmail.com> <20140402191448.GC3793@leortable> <20140403135618.5F823206E7@smtp.hushmail.com> <20140404161715.GD3793@leortable> <20140404173248.43DA2C0455@smtp.hushmail.com> Message-ID: <20140404191323.GE3793@leortable> On Fri, Apr 04, 2014 at 01:32:47PM -0400, vedaal at nym.hush.com wrote: > I trust them to encrypt to my public key, and was planning to work out > a system where I could decrypt on my own without it going through > them. > (they could have my public key, and verify my RSA signature). > > [All this is in the theoretical planning stage ;-) > first I would need to be able to isolate my RSA part of my GnuPG key > and see if it can be used with an open source simple RSA program > offline. > > That was my original question.] > vedaal Well... As this seems not documented (otherwise I guess someone else would have answered you), I'm going to assume there is no such function available in gnupg. So, this (and the reasons explained by Sam) explains the reason why I'm trying to figure out what you actually want to do, in order to perhaps propose you another solution, instead of merely answering you to write your own extractor. So, if you forgive my bluntness... With what closed program are you trying to interface? Why would you want to use your pgp keypair for this program, and not a key generated for this use? From rjh at sixdemonbag.org Fri Apr 4 22:04:26 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 04 Apr 2014 13:04:26 -0700 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: <20140404185708.7785f02b@kcore.de> References: <533DD0C4.1080503@norbl.com> <533E4B5E.9060107@sixdemonbag.org> <20140404185708.7785f02b@kcore.de> Message-ID: <20140404130426.Horde.n32M2jOSmrQd-xrq3B3Ing1@mail.sixdemonbag.org> > Ren? (not a mathematician or cryptographer) Looks good to me. My only correction is a notational one. Keyspaces are normally expressed in bits of entropy, not in 2^N bits of entropy. I'd suggest: L = (3N) / (10 * log S) ... where 'L' is the length of the string in terms of its base component, N is the desired entropy in bits, and S is the keyspace of the string's base component. This avoids having to compute logarithms base-2, since 3/10 is an astonishingly good approximation of two in log-10. Plugging in the numbers for Diceware and a 256-bit key: L = (3 * 256) / (10 * log 7776) L = 768 / (10 * 3.89) L = 768 / 38.9 L = 19.74 Round it up to 20 words and call it done. This is simple enough that you can turn it into a snippet of Javascript, a Python applet, or anything. It's not much work at all. If anyone wants, I'd be happy to put up a passphrase length calculator. And let me repeat, Ren?, you got the math absolutely right. All I did was clean it up a little bit to remove an obnoxious 2^godawful calculation. :) From rjh at sixdemonbag.org Fri Apr 4 22:14:09 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 04 Apr 2014 13:14:09 -0700 Subject: Length for AES256 symmetric encryption passphrase? In-Reply-To: <533EFB68.8060805@norbl.com> References: <533DD0C4.1080503@norbl.com> <533E4B5E.9060107@sixdemonbag.org> <20140404101055.Horde.bIXzyjMnYN6bFPb3VaAliQ1@mail.sixdemonbag.org> <533EFB68.8060805@norbl.com> Message-ID: <20140404131409.Horde.RS2SjhYAWCYrUtRev_oTIg1@mail.sixdemonbag.org> > To be clear, I want to use gnupgp to do symmetric encryption using > AES256. As I understand it, the 'gpg -symmetric ...' command > converts a pass phrase into a key, a 32 byte key in the case of > AES256. Correct! > I /assume/ that this conversion is 'deterministic' since as far as > I can tell, the 'gpg -symmetric ...' does not store the key it > generates. Correct me if I'm wrong. Again, correct! > I am trying to decide how long a pass phrase to use. I have not > decided how to generate the pass phrase. Assume that it is > pseudo-randomly chosen from the an english language character set. Then this becomes pretty straightforward. :) Let's say you use the upper- and lower-case letters, the digits 0 through 9, as well as the '+' and '/' marks. This character set is commonly called 'base64', since there are 64 symbols in the set. Using the equation Ren? provided and I polished a bit, you have: 3 * 256 <-- 256: size of the key in bits L = ----------- 10 * log 64 <-- 64: how many letters are in your set ... 43 characters. A quick back-of-the-envelope calculation confirms this to be the case. base64 is known to have six bits of entropy per character. 6 * 43 = 258 bits. At 43 characters you're providing GnuPG with 258 bits of entropy to use in creating a 256-bit symmetric key. From timprepscius at gmail.com Sat Apr 5 01:57:17 2014 From: timprepscius at gmail.com (Tim Prepscius) Date: Fri, 4 Apr 2014 19:57:17 -0400 Subject: checking signature of pgp mime Message-ID: > On Thursday 03 April 2014 15:06:57 Tim Prepscius wrote: > > Greetings, > > > > So as I said before, I'm working on a pgp base web mail app: > > https://github.com/timprepscius/mv > > > > I am having problems validating the signature of a small percentage of > > test cases. However GPG with apple-mail says the signatures > > checkout, soo... I'm obviously doing something incorrectly. > KMail also says that the signature matches. Does KMail (or any other mail application) allow the user to get a dump of the signed portion of the message? (apple mail doesn't and the gpg debugging doesn't include it). I need to get a hex dump of what was successfully verified. I've spent many an hour now removing a little white space here, a little white space there with no verified signature. (using a signature block in a detached file) -tim From peter at digitalbrains.com Sat Apr 5 13:08:15 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 05 Apr 2014 13:08:15 +0200 Subject: Chipdrive SPR 532 and OpenPGP Card with 4096Bit RSA Keys In-Reply-To: <20140403124204.GB11096@miraculix.wolters.lan> References: <20140403124204.GB11096@miraculix.wolters.lan> Message-ID: <533FE41F.4030009@digitalbrains.com> On 03/04/14 14:42, Florian Wolters wrote: > Has anyone this combination up and running and could point me into the > right direction to get this working? It works for me. I have an SPR 532 with firmware v5.10, and I'm running Debian testing x86_64. I'm using GnuPG's internal CCID driver. I couldn't generate a 4096-bit key on the card, but I could transfer one with "keytocard". At that point, the key length mentioned in --card-status was already set to 4096 bit by the failed generation attempt; that might have made a difference. It went along these lines: ------------------8<-------------->8------------------ peter at tweek:~$ gpg2 --expert --gen-key gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) Your selection? 8 Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify Encrypt [...] Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? q RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 42048 [...] peter at tweek:~$ gpg2 --expert --edit-key 40AF7983 [...] gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) Your selection? 8 [...] Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Authenticate (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? q RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096 [...] [...irrelevant part skipped...] peter at tweek:~$ gpg2 --expert --edit-key 40AF7983 gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. pub 2048R/40AF7983 created: 2014-04-05 expires: 2014-04-12 usage: SC trust: never validity: unknown sub 4096R/80369970 created: 2014-04-05 expires: 2014-04-12 usage: A [ unknown] (1). Test 4k gpg> toggle sec 2048R/40AF7983 created: 2014-04-05 expires: 2014-04-12 ssb 4096R/80369970 created: 2014-04-05 expires: never (1) Test 4k gpg> key 1 sec 2048R/40AF7983 created: 2014-04-05 expires: 2014-04-12 ssb* 4096R/80369970 created: 2014-04-05 expires: never (1) Test 4k gpg> keytocard Signature key ....: [none] Encryption key....: [none] Authentication key: [none] Please select where to store the key: (3) Authentication key Your selection? 3 sec 2048R/40AF7983 created: 2014-04-05 expires: 2014-04-12 ssb* 4096R/80369970 created: 2014-04-05 expires: never card-no: 0005 0000106E (1) Test 4k gpg> Save changes? (y/N) y peter at tweek:~$ gpg2 --card-status [...] Key attributes ...: 4096R 4096R 4096R [...] Signature key ....: [none] Encryption key....: [none] Authentication key: D39E 61C2 8678 7B4B A1CD 84A2 4529 4317 8036 9970 created ....: 2014-04-05 09:35:02 General key info..: pub 4096R/80369970 2014-04-05 Test 4k sec 2048R/40AF7983 created: 2014-04-05 expires: 2014-04-12 ssb> 4096R/80369970 created: 2014-04-05 expires: 2014-04-12 card-no: 0005 0000106E peter at tweek:~$ ssh-add -l 4096 88:a5:ad:f8:a9:33:75:2f:08:7d:c0:ad:7e:97:cd:c3 cardno:00050000106E (RSA) 2048 bc:8d:69:cf:45:aa:ea:c3:df:8d:e4:f4:a4:9e:c6:08 /home/peter/.ssh/id_rsa (RSA) peter at tweek:~$ ssh-add -L ssh-rsa AAAAB3NzaC1yc2[...]ao3lYk5DHJk0EkW6Q== cardno:00050000106E ssh-rsa AAAAB3NzaC1yc[...]PRw/seKuoX2PANuDWQ== /home/peter/.ssh/id_rsa ------------------8<-------------->8------------------ I added the card public key to an authorized_keys file and could log in with that key without any problems. I have updated the firmware to v5.10 a long time ago. I think I used Windows XP for that. So it can work. I hope that bit of information helps in your quest for 4k authentication :). Or you could create a shorter key. Auth keys can be changed relatively easily, though not as easily as signature keys. More importantly, they don't protect any secret data (just a random challenge), so I don't think there's any reason to go beyond, say, 2048 bits. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From florian at florian-wolters.de Sat Apr 5 15:57:57 2014 From: florian at florian-wolters.de (Florian Wolters) Date: Sat, 5 Apr 2014 15:57:57 +0200 Subject: Chipdrive SPR 532 and OpenPGP Card with 4096Bit RSA Keys In-Reply-To: <533FE41F.4030009@digitalbrains.com> References: <20140403124204.GB11096@miraculix.wolters.lan> <533FE41F.4030009@digitalbrains.com> Message-ID: <20140405135757.GA6302@miraculix.wolters.lan> Hi all, > It works for me. I have an SPR 532 with firmware v5.10, and I'm running Debian > testing x86_64. I'm using GnuPG's internal CCID driver. I got this working as well. The problem oviously indeed lies with the firware version of the smartcard reader. I managed to update the firwamre to 5.10 using a physical serial RS-232 port to connect the reader. The former tries with the USB interface on a VirtualBox machine did not work. But concerning the keys I got another question: How can I tell gnupg to use keys that are already stored on the card? I do have my private key on the card already and want to use this card on another computer? Do I have to import my keypair again and then "keytocard"? Or can I tell gnupg somehow to use the key already existing on the card? Regards Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From timprepscius at gmail.com Sat Apr 5 19:05:50 2014 From: timprepscius at gmail.com (Tim Prepscius) Date: Sat, 5 Apr 2014 13:05:50 -0400 Subject: checking signature of pgp mime In-Reply-To: References: Message-ID: It turns out Doug Barton's ppf_mime was able to generate the block + sig. So, I have a working example. Thanks for your time, -tim On 4/4/14, Tim Prepscius wrote: >> On Thursday 03 April 2014 15:06:57 Tim Prepscius wrote: >> > Greetings, >> > >> > So as I said before, I'm working on a pgp base web mail app: >> > https://github.com/timprepscius/mv >> > >> > I am having problems validating the signature of a small percentage of >> > test cases. However GPG with apple-mail says the signatures >> > checkout, soo... I'm obviously doing something incorrectly. > >> KMail also says that the signature matches. > > Does KMail (or any other mail application) allow the user to get a > dump of the signed portion of the message? > > (apple mail doesn't and the gpg debugging doesn't include it). > > I need to get a hex dump of what was successfully verified. > I've spent many an hour now removing a little white space here, a > little white space there with no verified signature. (using a > signature block in a detached file) > > -tim > From dougb at dougbarton.us Sat Apr 5 21:34:33 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 05 Apr 2014 12:34:33 -0700 Subject: checking signature of pgp mime In-Reply-To: References: Message-ID: <53405AC9.7090503@dougbarton.us> On 04/05/2014 10:05 AM, Tim Prepscius wrote: > It turns out Doug Barton's ppf_mime was able to generate the block + sig. > So, I have a working example. Awesome! If you come up with any suggestions for improvements feel free to send them along. I haven't touched that code in years because I haven't _seen_ any new pathological cases, but that doesn't mean none exist. :) > Thanks for your time, Glad to help. Doug From pete at heypete.com Sat Apr 5 22:09:58 2014 From: pete at heypete.com (Pete Stephenson) Date: Sat, 5 Apr 2014 22:09:58 +0200 Subject: Chipdrive SPR 532 and OpenPGP Card with 4096Bit RSA Keys In-Reply-To: <20140405135757.GA6302@miraculix.wolters.lan> References: <20140403124204.GB11096@miraculix.wolters.lan> <533FE41F.4030009@digitalbrains.com> <20140405135757.GA6302@miraculix.wolters.lan> Message-ID: On Sat, Apr 5, 2014 at 3:57 PM, Florian Wolters wrote: > But concerning the keys I got another question: How can I tell gnupg to > use keys that are already stored on the card? I do have my private key > on the card already and want to use this card on another computer? Do I > have to import my keypair again and then "keytocard"? > > Or can I tell gnupg somehow to use the key already existing on the card? When you run "keytocard" the private key is moved to the card and then the private key on the computer is then replaced with a "stub" that says "The private key is located on the smartcard with a serial number of $SERIAL_NUMBER" so GnuPG knows where to look and, if the card is not present, prompt you for the right card. (Be sure you have a backup of your actual private key before running "keytocard", if that's something you'd like to do.) As far as I know, there are two options for setting up a second system to have the stub without actually needing to import your actual private key: 1. You can export the stub "private" key (I use quotes because unlike a real private key, the stub is not sensitive information) from your first computer and then import it into the second just as you would do if you were importing any other private key. 2. Import only the your public key to the second computer, then insert the smartcard and run "gpg --card-status". This will detect the card and generate the appropriate stub. This is the method I usually do. Cheers! -Pete -- Pete Stephenson From vedaal at nym.hush.com Sun Apr 6 16:29:25 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Sun, 06 Apr 2014 10:29:25 -0400 Subject: Using an RSA GnuPG key for RSA ? In-Reply-To: <20140404191323.GE3793@leortable> References: <20140402175521.53CD8C0455@smtp.hushmail.com> <20140402191448.GC3793@leortable> <20140403135618.5F823206E7@smtp.hushmail.com> <20140404161715.GD3793@leortable> <20140404173248.43DA2C0455@smtp.hushmail.com> <20140404191323.GE3793@leortable> Message-ID: <20140406142925.8E4C7C0455@smtp.hushmail.com> On 04/04/2014 at 4:05 PM, "Leo Gaspard" wrote: >Well... As this seems not documented (otherwise I guess someone else would have >answered you), I'm going to assume there is no such function available in gnupg. ===== I think it should be quite doable, by those fluent in rfc 2440, 4880, but I cannot impose upon them if they do not have time to do so. I will try it myself and see how it goes. This Is how I thought about doing it. If anyone has advice about it, I am thankful in advance, but please do not use up your time in asking me for what, and telling me why it can absolutely never work.. I have access to a Professor who is an authority on RSA, and once I have everything done and ready, I can ask him if it would be secure/advisable to proceed, but cannot take advantage of him by asking more than once. For simplicity, I would start with a V3 RSA key, .(V4 keys have ability to add subkeys, and the ability to have a master key do either signing only, or both signing or encrypting. I'm not sure, but think that because of this, it may add other material that obscures extracting only the RSA part of the key. Once I can get it to work with a v3 key, will try to extract part by part from the V4 key). So, here's the tentative plan: [1] Generate a v3 test key in pgp 2.x [2] Import it to GnuPG [3] Remove the passphrase [4] Export it as a .asc file [5] Examine it in PGPdump, and extract the RSA components [6] Try it out in an RSA program offline. (Obviously, for a real secret key, would not use the online PGPdump) Any help or criticism about how to extract a functional RSA key would be appreciated. TIA, vedaal From peter at digitalbrains.com Sun Apr 6 21:50:06 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 06 Apr 2014 21:50:06 +0200 Subject: Using an RSA GnuPG key for RSA ? In-Reply-To: <20140406142925.8E4C7C0455@smtp.hushmail.com> References: <20140402175521.53CD8C0455@smtp.hushmail.com> <20140402191448.GC3793@leortable> <20140403135618.5F823206E7@smtp.hushmail.com> <20140404161715.GD3793@leortable> <20140404173248.43DA2C0455@smtp.hushmail.com> <20140404191323.GE3793@leortable> <20140406142925.8E4C7C0455@smtp.hushmail.com> Message-ID: <5341AFEE.1010308@digitalbrains.com> On 06/04/14 16:29, vedaal at nym.hush.com wrote: > [5] Examine it in PGPdump, and extract the RSA components On Debian, there is the pgpdump package which, I just tested, outputs the private key components in hex (or hex escaped string with -g). Also, when I did apt-cache search pgpdump, I noticed there is a Python library: [1]. That might be even better for your purpose. HTH, Peter. [1] https://pypi.python.org/pypi/pgpdump/ -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From vedaal at nym.hush.com Sun Apr 6 21:54:27 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Sun, 06 Apr 2014 15:54:27 -0400 Subject: Using an RSA GnuPG key for RSA ? In-Reply-To: <5341AFEE.1010308@digitalbrains.com> References: <20140402175521.53CD8C0455@smtp.hushmail.com> <20140402191448.GC3793@leortable> <20140403135618.5F823206E7@smtp.hushmail.com> <20140404161715.GD3793@leortable> <20140404173248.43DA2C0455@smtp.hushmail.com> <20140404191323.GE3793@leortable> <20140406142925.8E4C7C0455@smtp.hushmail.com> <5341AFEE.1010308@digitalbrains.com> Message-ID: <20140406195427.45091C0455@smtp.hushmail.com> On 04/06/2014 at 3:50 PM, "Peter Lebbing" wrote: > >On 06/04/14 16:29, vedaal at nym.hush.com wrote: >> [5] Examine it in PGPdump, and extract the RSA components > >On Debian, there is the pgpdump package which, I just tested, >outputs the >private key components in hex (or hex escaped string with -g). > >Also, when I did apt-cache search pgpdump, I noticed there is a >Python library: >[1]. That might be even better for your purpose. > >HTH, > >Peter. > >[1] https://pypi.python.org/pypi/pgpdump/ ===== Yes, Python should be simpler to use in ubuntu THANKS !!! vedaal From dkg at fifthhorseman.net Mon Apr 7 06:05:43 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 07 Apr 2014 00:05:43 -0400 Subject: Encrypted file-size approximation with multiple recipients In-Reply-To: <20140402120720.3ac7dcf2@bigbox.christie.dr> References: <20140401200128.46b62b28@bigbox.christie.dr> <015D1F30-1587-470E-860B-DDFC899BECF3@jabberwocky.com> <20140402120720.3ac7dcf2@bigbox.christie.dr> Message-ID: <53422417.7080206@fifthhorseman.net> On 04/02/2014 01:07 PM, Tim Chase wrote: > 1) I'd missed that GPG conveniently compresses the data before > encrypting which would explain some of the differences I saw. [...] > in more than half of my use cases (small plain-text/JSON messages) It sounds to me like you might be setting up some sort of automated encrypted JSON message-passing scheme. If so, you should be aware that if any of the encrypted JSON could be controlled by an attacker, that attacker could possibly learn information about the other parts of the message that are not controlled by them when using compression, just by inspecting the size of the traffic. This is essentially how the CRIME attack against TLS works, but the theoretical framework of the attack itself isn't necessarily limited to TLS. Please make sure you understand the CRIME attack against TLS and your mechanism's use cases well enough to be certain that a comparable attack isn't applicable, or just explicitly turn off compression for your OpenPGP-encrypted data if you can afford the extra bandwidth and are unsure about the use cases to which other people might put your protocol. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon Apr 7 07:39:16 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 07 Apr 2014 01:39:16 -0400 Subject: Using an RSA GnuPG key for RSA ? In-Reply-To: <20140402175521.53CD8C0455@smtp.hushmail.com> References: <20140402175521.53CD8C0455@smtp.hushmail.com> Message-ID: <53423A04.6010603@fifthhorseman.net> On 04/02/2014 01:55 PM, vedaal at nym.hush.com wrote: > Is it possible to generate an RSA key in GnuPG, and then use it (not in GnuPG, but in other systems using RSA keys), to encrypt and decrypt RSA messages? i think you might be interested in openpgp2pem from the monkeysphere package. > If so, what portion of the GnuPG generated RSA key functions as a 'pure' RSA key? I don't think this question is actually the question you want to ask. "pure" RSA is extremely limited, and a secret RSA key is usually only used for either signing or decrypting symmetric session keys, whether that's in TLS or OpenPGP or CMS or any other place where RSA is used. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Mon Apr 7 08:06:18 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Mon, 07 Apr 2014 08:06:18 +0200 Subject: Removing old preferences from exported key Message-ID: <5342405A.8000601@vulcan.xs4all.nl> Hallo, I changed the preferences for my gpg key to add the new Camelia ciphers and move IDEA more backward as I got problems with people with old pgp keys using old gnupg versions claiming they supported it but actually didn't support it. However, when I export the key it now contains both preference signatures. I did export it with export-options export-clean-sigs export-clean-uids in gpg.conf. How do I export it removing the first preference signature? -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From dshaw at jabberwocky.com Mon Apr 7 15:16:36 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 7 Apr 2014 09:16:36 -0400 Subject: Removing old preferences from exported key In-Reply-To: <5342405A.8000601@vulcan.xs4all.nl> References: <5342405A.8000601@vulcan.xs4all.nl> Message-ID: <3447A39B-BEC6-4569-8B39-627E1747FB7B@jabberwocky.com> On Apr 7, 2014, at 2:06 AM, Johan Wevers wrote: > Hallo, > > I changed the preferences for my gpg key to add the new Camelia ciphers > and move IDEA more backward as I got problems with people with old pgp > keys using old gnupg versions claiming they supported it but actually > didn't support it. > > However, when I export the key it now contains both preference > signatures. I did export it with > > export-options export-clean-sigs export-clean-uids > > in gpg.conf. > > How do I export it removing the first preference signature? When you change preferences you add another selfsig for your user ID that contains the new preferences. If you want to make the old preferences go away completely, you can simply delete the old selfsig via delsig (you only need one selfsig, and the newer one is already present). However, this won't necessarily do what you want - since keyservers are strictly additive, even if you delete the old selfsig, when you upload to a keyserver, any keyserver that has seen the key with the old selfsig will put it back. Similarly, if someone had your key with the old selfsig, sending them the new preference will cause them to have both. Luckily in practice, this isn't a problem - most implementations will ignore the old selfsig/preference in favor of the newer one. David From vedaal at nym.hush.com Mon Apr 7 16:19:12 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Mon, 07 Apr 2014 10:19:12 -0400 Subject: Using an RSA GnuPG key for RSA ? In-Reply-To: <53423A04.6010603@fifthhorseman.net> References: <20140402175521.53CD8C0455@smtp.hushmail.com> <53423A04.6010603@fifthhorseman.net> Message-ID: <20140407141917.C7F8F205CF@smtp.hushmail.com> On Monday, April 07, 2014 at 1:39 AM, "Daniel Kahn Gillmor" wrote: > >On 04/02/2014 01:55 PM, vedaal at nym.hush.com wrote: >> Is it possible to generate an RSA key in GnuPG, and then use it >(not in GnuPG, but in other systems using RSA keys), to encrypt >and decrypt RSA messages? > >i think you might be interested in openpgp2pem from the >monkeysphere >package. > >> If so, what portion of the GnuPG generated RSA key functions as >a 'pure' RSA key? > >I don't think this question is actually the question you want to >ask. >"pure" RSA is extremely limited, and a secret RSA key is usually >only >used for either signing or decrypting symmetric session keys, >whether >that's in TLS or OpenPGP or CMS or any other place where RSA is >used. > > --dkg ===== OK, Thanks. vedaal From adrelanos at riseup.net Tue Apr 8 01:03:22 2014 From: adrelanos at riseup.net (Patrick Schleizer) Date: Mon, 07 Apr 2014 23:03:22 +0000 Subject: key signing in Leipzig, Germany Message-ID: <53432EBA.7080001@riseup.net> Hi, anyone interested to meet up for key signing in Leipzig, Germany? Please contact me off list. Cheers, Patrick From petermichaux at gmail.com Tue Apr 8 06:45:20 2014 From: petermichaux at gmail.com (Peter Michaux) Date: Mon, 7 Apr 2014 21:45:20 -0700 Subject: Use GnuPG in an automated environment? Message-ID: Hi, I am creating a Debian APT repository of system packages. I need to sign the repository's Release file, creating detached signature file Release.gpg, so that packages can be installed on another Debian system with `apt-get install` without the complaint "WARNING: The following packages cannot be authenticated!". I can manually create the Release.gpg file which requires typing my GnuPG key's passphrase. I want to automate/script the creation of all the repository's generated files so that a cron job can generate them when the repository's package list changes. This means that creating the Release.gpg file cannot require my GnuPG key's passphrase. I have actually succeeded at creating the Release.gpg file without needing my GnuPG key's passphrase following a combination of the instructions from the following. * http://www.gnupg.org/faq/gnupg-faq.html#automated_use * http://www.slpicare.org/unix/automating_signing_with_GPG.html The process is complex enough that I have little confidence that I'm doing everything correctly and/or securely. I'm experimenting and trying to understand all the related commands better. I noticed something that seems incorrect or at least suspicious and worth asking about. I can list all of the keys that I've created. peter at alpha.com:~$ gpg --homedir ~/.gnupg.insec --list-keys /home/peter/.gnupg.insec/pubring.gpg ------------------------------------ pub 2048D/13FC9B38 2014-04-07 uid Peter Michaux (My Comment) sub 2048g/A2D0ED65 2014-04-07 sub 2048D/215D17CD 2014-04-07 The first two keys, 13FC9B38 and A2D0ED65, were the ones created when I originally used `gpg --gen-key`. I followed the tutorials about using GnuGP in an automated environment to create the third key, 215D17CD, with no password. To understand things better, I want to ensure that I can properly select/control the key I want to use during signing with the `--default-key` option to the `gpg` command line tool. This is where things look suspicous to me. peter at alpha.com:~/drepo$ gpg --homedir ~/.gnupg.insec \ --verbose \ --detach-sign \ --default-key 13FC9B38 \ --output dists/stable/Release.gpg \ dists/stable/Release gpg: using subkey 215D17CD instead of primary key 13FC9B38 gpg: writing to `dists/stable/Release.gpg' gpg: using subkey 215D17CD instead of primary key 13FC9B38 gpg: DSA/SHA256 signature from: "215D17CD Peter Michaux (Black Iron Beast) " Why does gpg use the third key in the list when I've specifically requested it use the first key in the list? (Yes, ultimately I want to use the third key in the list but I want to know why gpg is defing my wishes in the above command.) Thanks. Peter From johanw at vulcan.xs4all.nl Tue Apr 8 07:48:38 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 08 Apr 2014 07:48:38 +0200 Subject: Removing old preferences from exported key In-Reply-To: <3447A39B-BEC6-4569-8B39-627E1747FB7B@jabberwocky.com> References: <5342405A.8000601@vulcan.xs4all.nl> <3447A39B-BEC6-4569-8B39-627E1747FB7B@jabberwocky.com> Message-ID: <53438DB6.3040900@vulcan.xs4all.nl> On 07-04-2014 15:16, David Shaw wrote: > When you change preferences you add another selfsig for your > user ID that contains the new preferences. > If you want to make the old preferences go away completely, > you can simply delete the old selfsig via delsig Yers, that removes it completely from my keyring. That's not necessary and will be undone after the first sync with the keyservers anyway. However, is there a way to remove it from the exported key only - to keep the size of the exported key as small as possible? The export options didn't do that as list-packets showed. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From dkg at fifthhorseman.net Tue Apr 8 07:57:05 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 08 Apr 2014 01:57:05 -0400 Subject: Use GnuPG in an automated environment? In-Reply-To: References: Message-ID: <53438FB1.9020006@fifthhorseman.net> On 04/08/2014 12:45 AM, Peter Michaux wrote: > I am creating a Debian APT repository of system packages. I need to > sign the repository's Release file, creating detached signature file > Release.gpg, so that packages can be installed on another Debian > system with `apt-get install` without the complaint "WARNING: The > following packages cannot be authenticated!". I can manually create > the Release.gpg file which requires typing my GnuPG key's passphrase. sorry to not get into the GnuPG specifics, but how are you managing the apt repository? the reprepro APT repository management tool includes mechanisms for specifying which key to use for signing and automatically triggers signing when something has changed in the repo (or you can ask it to re-sign if you need that). http://mirrorer.alioth.debian.org/ (the debian reprepro package is just fine for this) i recommend using reprepro to manage the APT respository unless you have a compelling reason to manage all the rest of this stuff yourself. You can use reprepro locally to build the repository someplace where you have access to the signing key and then use rsync or the equivalent to push out the updates to any network-accessible mirrors. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From petermichaux at gmail.com Tue Apr 8 08:16:22 2014 From: petermichaux at gmail.com (Peter Michaux) Date: Mon, 7 Apr 2014 23:16:22 -0700 Subject: Use GnuPG in an automated environment? In-Reply-To: <53438FB1.9020006@fifthhorseman.net> References: <53438FB1.9020006@fifthhorseman.net> Message-ID: Well, this went off-topic quickly. ;-) On Mon, Apr 7, 2014 at 10:57 PM, Daniel Kahn Gillmor wrote: > i recommend using reprepro to manage the APT respository unless you have > a compelling reason to manage all the rest of this stuff yourself. I'm concerned about the inability of reprepro to include in a single distribution two files which are only different versions of the same package. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570623 Also, I'd like to understand gpg better which is why I asked about the --default-key issue I noticed and didn't understand. Thanks. Peter From santhosh5619 at gmail.com Tue Apr 8 06:04:38 2014 From: santhosh5619 at gmail.com (Santhosh Kumar) Date: Tue, 8 Apr 2014 14:04:38 +1000 Subject: Query on PGP Keygen using GNUPG Message-ID: Hi Team, I'm trying to execute the PGP Key generation using "SUNWgnupg" available on Solaris 11 with CLI option mentioned below. /usr/bin/gpg2 --secret-keyring /home2/d1/owner/.gnupg/secring.gpg --keyring /home2/d1/owner/.gnupg/pubring.gpg --gen-key --local-user [lindex $argv 0]* * May I know the attributes to be used for giving Key Size as 2048 , Key algorithm as RSA etc. in single CLI instead of routine way of generating Key. Appreciate if you can help me with quick reply to proceed with my work. PFA for server details and version present on Solaris 11 server Thanks, Santhosh Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # uname -a SunOS 5.11 11.1 sun4v sparc sun4v # uname -X System = SunOS Node = Release = 5.11 KernelID = 11.1 Machine = sun4v BusType = Serial = Users = OEM# = 0 Origin# = 1 NumCPU = 32 # cat /etc/release Oracle Solaris 11.1 SPARC Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved. Assembled 06 November 2013 =========================================================================================== $ /usr/bin/gpg2 --version gpg (GnuPG) 2.0.17 libgcrypt 1.4.5 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 ======================================================================================== Syntax: gpg [options] [files] sign, check, encrypt or decrypt default operation depends on the input data Commands: -s, --sign make a signature --clearsign make a clear text signature -b, --detach-sign make a detached signature -e, --encrypt encrypt data -c, --symmetric encryption only with symmetric cipher -d, --decrypt decrypt data (default) --verify verify a signature -k, --list-keys list keys --list-sigs list keys and signatures --check-sigs list and check key signatures --fingerprint list keys and fingerprints -K, --list-secret-keys list secret keys --gen-key generate a new key pair --gen-revoke generate a revocation certificate --delete-keys remove keys from the public keyring --delete-secret-keys remove keys from the secret keyring --sign-key sign a key --lsign-key sign a key locally --edit-key sign or edit a key --passwd change a passphrase --export export keys --send-keys export keys to a key server --recv-keys import keys from a key server --search-keys search for keys on a key server --refresh-keys update all keys from a keyserver --import import/merge keys --card-status print the card status --card-edit change data on a card --change-pin change a card's PIN --update-trustdb update the trust database --print-md print message digests --server run in server mode Options: -a, --armor create ascii armored output -r, --recipient USER-ID encrypt for USER-ID -u, --local-user USER-ID use USER-ID to sign or decrypt -z N set compress level to N (0 disables) --textmode use canonical text mode -o, --output FILE write output to FILE -v, --verbose verbose -n, --dry-run do not make any changes -i, --interactive prompt before overwriting --openpgp use strict OpenPGP behavior (See the man page for a complete listing of all commands and options) Examples: -se -r Bob [file] sign and encrypt for user Bob --clearsign [file] make a clear text signature --detach-sign [file] make a detached signature --list-keys [names] show keys --fingerprint [names] show fingerprints Please report bugs to . =========================================================================================== From dkg at fifthhorseman.net Tue Apr 8 13:47:46 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 08 Apr 2014 07:47:46 -0400 Subject: Use GnuPG in an automated environment? In-Reply-To: References: <53438FB1.9020006@fifthhorseman.net> Message-ID: <5343E1E2.1050709@fifthhorseman.net> On 04/08/2014 02:16 AM, Peter Michaux wrote: > I'm concerned about the inability of reprepro to include in a single > distribution two files which are only different versions of the same > package. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570623 sorry for the off-topic aside, i'm glad to see that you've considered reprepro. I don't know what the use case is for multiple versions of the same package in the same repo, but it does sound like if you need that it's a compelling reason to manage to repo by hand for now. > Also, I'd like to understand gpg better which is why I asked about the > --default-key issue I noticed and didn't understand. The key selection you're asking about is done by gpg in its best-effort way. Here's my understanding of its approach: if you specify a key or a user ID, it first tries to find the primary key associated with that specification (see "HOW TO SPECIFY A USER ID" in gpg(1) ). Then, when making a regular data signature (which is what Release.gpg is), given that selected primary key, it checks to see if there is a signing-capable subkey that has a newer creation time than then primary key, and it uses that one. If you want to specify a particular subkey or primary key as the signing key, you should be able to do so by appending a "!" to the end of the key ID: When using gpg an exclamation mark (!) may be appended to force using the specified primary or secondary key and not to try and calculate which primary or secondary key to use. (note that the ! may need to be escaped to avoid your shell interpreting it) If you can stand one more off-topic aside: I also recommend that for important use cases like a software repository, you take care to identify the signing key using a full fingerprint instead of a short keyid. short keyids are trivially spoofable, and if you ever update your gnupg keyring from a public keyserver, it's possible for that keyserver (or anyone in control of the network path between you and the keyserver) to push an update into your keyring that matches the short Key ID in question (even a secret key can be pushed in, i think). Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From sam.mxracer at gmail.com Tue Apr 8 19:58:08 2014 From: sam.mxracer at gmail.com (Sam Gleske) Date: Tue, 8 Apr 2014 13:58:08 -0400 Subject: Removing old preferences from exported key In-Reply-To: <53438DB6.3040900@vulcan.xs4all.nl> References: <5342405A.8000601@vulcan.xs4all.nl> <3447A39B-BEC6-4569-8B39-627E1747FB7B@jabberwocky.com> <53438DB6.3040900@vulcan.xs4all.nl> Message-ID: There is also the clean command which cleans up old self sigs (among other things like unusable sigs, e.g. expired signatures). On Tue, Apr 8, 2014 at 1:48 AM, Johan Wevers wrote: > On 07-04-2014 15:16, David Shaw wrote: > > > When you change preferences you add another selfsig for your > > user ID that contains the new preferences. > > > If you want to make the old preferences go away completely, > > you can simply delete the old selfsig via delsig > > Yers, that removes it completely from my keyring. That's not necessary > and will be undone after the first sync with the keyservers anyway. > > However, is there a way to remove it from the exported key only - to > keep the size of the exported key as small as possible? The export > options didn't do that as list-packets showed. > > -- > ir. J.C.A. Wevers > PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Tue Apr 8 20:21:52 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 8 Apr 2014 14:21:52 -0400 Subject: Removing old preferences from exported key In-Reply-To: <53438DB6.3040900@vulcan.xs4all.nl> References: <5342405A.8000601@vulcan.xs4all.nl> <3447A39B-BEC6-4569-8B39-627E1747FB7B@jabberwocky.com> <53438DB6.3040900@vulcan.xs4all.nl> Message-ID: <9BC1164C-91E0-493B-A7BB-A04BCBD23EDE@jabberwocky.com> On Apr 8, 2014, at 1:48 AM, Johan Wevers wrote: > On 07-04-2014 15:16, David Shaw wrote: > >> When you change preferences you add another selfsig for your >> user ID that contains the new preferences. > >> If you want to make the old preferences go away completely, >> you can simply delete the old selfsig via delsig > > Yers, that removes it completely from my keyring. That's not necessary > and will be undone after the first sync with the keyservers anyway. > > However, is there a way to remove it from the exported key only - to > keep the size of the exported key as small as possible? The export > options didn't do that as list-packets showed. Sure: --export-options export-clean David From johanw at vulcan.xs4all.nl Tue Apr 8 22:51:24 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 08 Apr 2014 22:51:24 +0200 Subject: Removing old preferences from exported key In-Reply-To: <9BC1164C-91E0-493B-A7BB-A04BCBD23EDE@jabberwocky.com> References: <5342405A.8000601@vulcan.xs4all.nl> <3447A39B-BEC6-4569-8B39-627E1747FB7B@jabberwocky.com> <53438DB6.3040900@vulcan.xs4all.nl> <9BC1164C-91E0-493B-A7BB-A04BCBD23EDE@jabberwocky.com> Message-ID: <5344614C.4030807@vulcan.xs4all.nl> On 08-04-2014 20:21, David Shaw wrote: >> However, is there a way to remove it from the exported key only - to >> keep the size of the exported key as small as possible? The export >> options didn't do that as list-packets showed. > > Sure: > > --export-options export-clean Thanks, that worked. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From fmv1992 at gmail.com Wed Apr 9 05:01:29 2014 From: fmv1992 at gmail.com (Felipe Vieira) Date: Wed, 9 Apr 2014 00:01:29 -0300 Subject: Heartbleed attack on Openssl Message-ID: Dear GNUPG community, I think a lot of unexperienced users would like to know more about the Heartbleed problem found on some of the openssl versions. I have two broad questions and two specific questions: 1) Which type of clients have been compromised (consider an ordinary user)? 2) Which common applications use openssl and are a potential target? 2) Are firefox users compromised? 3) Are RetroShare users compromised? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbhukta at gmail.com Wed Apr 9 06:39:01 2014 From: dbhukta at gmail.com (dbhukta .) Date: Wed, 9 Apr 2014 10:09:01 +0530 Subject: GPG tool for Windows Embeddd Compact 7 In-Reply-To: References: <201402201801.39298.aheinecke@intevation.de> Message-ID: Hi, Can you give the solution for GPGtool which will run for Windows Embedded Compact 7. Or any Binary file which will be compatible for windows embedded compact 7. looking forward to hear from you. Regards D Bhukta +918600096629 On Fri, Feb 21, 2014 at 1:29 AM, Alan Meekins wrote: > Not all Windows Embedded OSes are built on top of CE! Look here for a > listing of the products. > It sounds like you are likely using Windows Embedded Standard 7(aka WES7, > yuck what a mouthful!) which is just a rebranded version of normal old > Windows 7. If this is the case it means anything that can run on windows > 7(big windows) will run on WES7 with no modification. The caveat about > Windows Embedded is that you have the flexibility to strip out just about > any componenet of Windows so the most likely issues you will hit are around > what you have removed from the image causing breaks in 3rd party software > such as GnuPG. So in short we need to know the exact version if Windows you > are running to really give accurate advice. CE is a different world which > may require you to recompile the programs you wish to run depending on your > exact scenario. > > Cheers, > -Alan > > > On Thu, Feb 20, 2014 at 9:01 AM, Andre Heinecke wrote: > >> Hi, >> >> On Wednesday 19 February 2014 08:13:36 dbhukta . wrote: >> > Let me know any version which is compatible for Windows embedded >> Compact 7 >> > to encrypt/decrypt a text file at least. >> >> GnuPG has been ported to Windows CE 5.0 so it should / could work on >> Windows >> embedded 7 (I guess its untested) as this work was done 2010 as part of a >> Project and there has been little interest in Windows CE since. >> >> We still have some binaries lying around: >> >> http://files.kolab.org/local/windows-ce/gpg-snapshots/gpg_wince-dev-190111.zip >> >> Sources for that version: >> >> http://files.kolab.org/local/windows-ce/gpg-snapshots/gpg-ce-dev-190111-src.zip >> >> And a signed sha1sums file in: >> http://files.kolab.org/local/windows-ce/gpg-snapshots/ >> >> Maybe it works, maybe not. >> Have fun >> >> -- >> Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ >> Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B >> 18998 >> Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> >> > -- Regards, Dinabandhu Bhukta 8600096629 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.mxracer at gmail.com Wed Apr 9 15:17:49 2014 From: sam.mxracer at gmail.com (Sam Gleske) Date: Wed, 9 Apr 2014 09:17:49 -0400 Subject: Heartbleed attack on Openssl In-Reply-To: References: Message-ID: On Tue, Apr 8, 2014 at 11:01 PM, Felipe Vieira wrote: > Dear GNUPG community, > I think a lot of unexperienced users would like to know more about the > Heartbleed problem found on some of the openssl versions. I have two broad > questions and two specific questions: > 1) Which type of clients have been compromised (consider an ordinary user)? > 2) Which common applications use openssl and are a potential target? > > 2) Are firefox users compromised? > 3) Are RetroShare users compromised? > Thanks in advance. > For the most part it is service providers who are affected by the bug. There's a handy website to verbosely explain heartbleed. http://heartbleed.com/ Affected services include HTTP, email servers (SMTP, POP and IMAP protocols), chat servers (XMPP protocol), virtual private networks (SSL VPNs), databases (e.g. mysql), and pretty much any service that uses openssl TSL/SSL to secure transport of services if they're recently patched. Security notices for popular server distros... RHEL - https://access.redhat.com/site/solutions/781793 Ubuntu - http://www.ubuntu.com/usn/usn-2165-1/ CLIENT There's not much you can do at this point. Update your system packages and that's about it. SERVICE PROVIDER Essentially you want to take the following steps if you're service provider. 1. Test for the vulnerability - http://pastebin.com/WmxzjkXJ it is also prudent to search for the affected package versions across all services. 2. If vulnerable patch the OpenSSL version of public front end services first. Patch backend services after the front end is secure. 3. Reissue SSL private keys and certificates. Since the leak exposes the private key it is no longer pristine. For the remaining more thorough steps of what to do see the heartbleed.orgwebsite which has a nice set of instructions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.santore at internexusconnect.net Wed Apr 9 15:59:27 2014 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Wed, 09 Apr 2014 14:59:27 +0100 Subject: Heartbleed attack on Openssl In-Reply-To: References: Message-ID: <5345523F.4070404@internexusconnect.net> On 09/04/14 14:17, Sam Gleske wrote: > On Tue, Apr 8, 2014 at 11:01 PM, Felipe Vieira > wrote: > > Dear GNUPG community, > I think a lot of unexperienced users would like to know more about > the Heartbleed problem found on some of the openssl versions. I > have two broad questions and two specific questions: > 1) Which type of clients have been compromised (consider an > ordinary user)? > 2) Which common applications use openssl and are a potential target? > > 2) Are firefox users compromised? > 3) Are RetroShare users compromised? > Thanks in advance. > > > For the most part it is service providers who are affected by the > bug. There's a handy website to verbosely explain heartbleed. > > http://heartbleed.com/ > > Affected services include HTTP, email servers (SMTP, POP and IMAP > protocols), chat servers (XMPP protocol), virtual private networks > (SSL VPNs), databases (e.g. mysql), and pretty much any service that > uses openssl TSL/SSL to secure transport of services if they're > recently patched. > > Security notices for popular server distros... > RHEL - https://access.redhat.com/site/solutions/781793 > Ubuntu - http://www.ubuntu.com/usn/usn-2165-1/ > > CLIENT > > There's not much you can do at this point. Update your system > packages and that's about it. > > SERVICE PROVIDER > Essentially you want to take the following steps if you're service > provider. > > 1. Test for the vulnerability - http://pastebin.com/WmxzjkXJ it is > also prudent to search for the affected package versions across all > services. > 2. If vulnerable patch the OpenSSL version of public front end > services first. Patch backend services after the front end is secure. > 3. Reissue SSL private keys and certificates. Since the leak exposes > the private key it is no longer pristine. > > For the remaining more thorough steps of what to do see the > heartbleed.org website which has a nice set of > instructions. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users It is imperative you revoke old keys! Not just reissue! Regards, Tristan -- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore at internexusconnect.net Former Thawte Notary (Please note: Thawte has closed its WoT programme down, and I am therefore no longer able to accredit trust) For Fedora related issues, please email me at: TSantore at fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Wed Apr 9 18:51:20 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 09 Apr 2014 12:51:20 -0400 Subject: Heartbleed attack on Openssl In-Reply-To: References: Message-ID: <53457A88.6050804@sixdemonbag.org> > Dear GNUPG community, That right there should be your first hint. :) This is a great email list to get informed opinions on GnuPG and the OpenPGP RFCs, but this may not be a great place to get informed commentary on OpenSSL. It's a completely different software package run by a completely different outfit. You may get better answers if you ask on the OpenSSL mailing lists. :) From kappu at hotmail.com Wed Apr 9 19:20:58 2014 From: kappu at hotmail.com (Kapil Aggarwal) Date: Wed, 9 Apr 2014 13:20:58 -0400 Subject: It's 2014. Are we there yet? Message-ID: Folks, I?m an ardent reader of this (and a few other) mailing lists, but usually stay quiet and in the background. However, in light of global events and paradigm shifts in the last few months, I?m tempted to speak up. While I do use PGP/GPG, I have to admit that the usage has been minimal and sporadic over the last few years, with the usual suspects as reasons. But the biggest reason of course is ?adoption? i.e. very few in my social/professional circle use it. Now, we all (probably, subconsciously?) know/acknowledge why that is, we are in 2014 after all. My personal belief is that the awareness for secure communications is starting to rise, not just for the niche users who are already using it/know how to use it, but for the ?average Joe user? as well. My definition of the ?average Joe user? btw is someone who: - Has at least one computing device, if not more - Is familiar with email - Is already using various online mediums - Has usually never thought about ?secure communications? or maybe in an abstract fashion Now, the barrier to entry of secured communications is high. I realize that. I?m sure a lot of you do as well. It?s not easy, it takes time, patience, a certain level of expertise and a tacit acknowledgement that they need to use it in the first place (probably the most important). The ?secure communications? paradigm of course spans a whole spectrum from ?I don?t give a ****? to ?I?ll do anything to protect my communications, including giving away my first born?. I suspect the ?average Joe user? in 2014 is slightly above the former, but way below the latter. Without going to the other end of the spectrum, what will make adoption of secure communications a bit more palatable to the ?average Joe user?? Let?s list a few arguments: - I don?t even know what I need. ? Well, assuming they are starting to recognize the need, I suspect they will find out relatively easily as to what they need. With a few caveats of course. There?s way more FUD/noise/BS out there than the average person can decipher, so it?ll probably end as being word-of-mouth recommendations or such. - Even if I know what I need, getting it/installing it is hard. ? It is. The setup/install needs to be simpler, i.e. as simple as installing an ?app?. That is what the average Joe user is capable of. - WTF is a key pair/public key/private key/? - ? This IS a big problem. I may get it, you may get it, how does the average Joe user gain that understanding? The nomenclature needs to be, well, something that the average Joe user can understand as well. They understood SSL (well, for the most part). - ? several more similar arguments. Now, what will help drive this adoption more? - A better install experience? - A ?dumbed down? (if you will) taxonomy that they can understand? - Simpler UIs? (without sacrificing secure functionality) - Better integration with existing systems? - Education? i.e. ongoing information dissemination that educates people on these things. Newsletters? How tos? Youtube videos (shudder)? And others. - Start hitting them on the head with a baseball bat? ? All thoughts are very much welcome and appreciated. Kapil Aggarwal. From kappu at hotmail.com Wed Apr 9 18:39:44 2014 From: kappu at hotmail.com (Kapil Aggarwal) Date: Wed, 9 Apr 2014 12:39:44 -0400 Subject: It's 2014. Are we there yet? Message-ID: Folks, I'm an ardent reader of this (and a few other) mailing lists, but usually stay quiet and in the background. However, in light of global events and paradigm shifts in the last few months, I'm tempted to speak up. While I do use PGP/GPG, I have to admit that the usage has been minimal and sporadic over the last few years, with the usual suspects as reasons. But the biggest reason of course is "adoption" i.e. very few in my social/professional circle use it. Now, we all (probably, subconsciously?) know/acknowledge why that is, we are in 2014 after all. My personal belief is that the awareness for secure communications is starting to rise, not just for the niche users who are already using it/know how to use it, but for the "average Joe user" as well. My definition of the "average Joe user" btw is someone who: - Has at least one computing device, if not more - Is familiar with email - Is already using various online mediums - Has usually never thought about "secure communications" or maybe in an abstract fashion Now, the barrier to entry of secured communications is high. I realize that. I'm sure a lot of you do as well. It's not easy, it takes time, patience, a certain level of expertise and a tacit acknowledgement that they need to use it in the first place (probably the most important). The "secure communications" paradigm of course spans a whole spectrum from "I don't give a ****" to "I'll do anything to protect my communications, including giving away my first born". I suspect the "average Joe user" in 2014 is slightly above the former, but way below the latter. Without going to the other end of the spectrum, what will make adoption of secure communications a bit more palatable to the "average Joe user"? Let's list a few arguments: - I don't even know what I need. - Well, assuming they are starting to recognize the need, I suspect they will find out relatively easily as to what they need. With a few caveats of course. There's way more FUD/noise/BS out there than the average person can decipher, so it'll probably end as being word-of-mouth recommendations or such. - Even if I know what I need, getting it/installing it is hard. - It is. The setup/install needs to be simpler, i.e. as simple as installing an "app". That is what the average Joe user is capable of. - WTF is a key pair/public key/private key/. - J This IS a big problem. I may get it, you may get it, how does the average Joe user gain that understanding? The nomenclature needs to be, well, something that the average Joe user can understand as well. They understood SSL (well, for the most part). - . several more similar arguments. Now, what will help drive this adoption more? - A better install experience? - A "dumbed down" (if you will) taxonomy that they can understand? - Simpler UIs? (without sacrificing secure functionality) - Better integration with existing systems? - Education? i.e. ongoing information dissemination that educates people on these things. Newsletters? How tos? Youtube videos (shudder)? And others. - Start hitting them on the head with a baseball bat? J All thoughts are very much welcome and appreciated. Kapil Aggarwal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.mxracer at gmail.com Wed Apr 9 19:29:05 2014 From: sam.mxracer at gmail.com (Sam Gleske) Date: Wed, 9 Apr 2014 13:29:05 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: References: Message-ID: On Wed, Apr 9, 2014 at 1:20 PM, Kapil Aggarwal wrote: > - I don?t even know what I need. ? Well, assuming they are starting > to recognize the need, I suspect they will find out relatively easily as to > what they need. With a few caveats of course. There?s way more FUD/noise/BS > out there than the average person can decipher, so it?ll probably end as > being word-of-mouth recommendations or such. > - Even if I know what I need, getting it/installing it is hard. ? It > is. The setup/install needs to be simpler, i.e. as simple as installing an > ?app?. That is what the average Joe user is capable of. > - WTF is a key pair/public key/private key/ terminology>? - ? This IS a big problem. I may get it, you may get it, how > does the average Joe user gain that understanding? The nomenclature needs > to be, well, something that the average Joe user can understand as well. > They understood SSL (well, for the most part). > - ? several more similar arguments. > > Now, what will help drive this adoption more? > > - A better install experience? > - A ?dumbed down? (if you will) taxonomy that they can understand? > - Simpler UIs? (without sacrificing secure functionality) > - Better integration with existing systems? > - Education? i.e. ongoing information dissemination that educates > people on these things. Newsletters? How tos? Youtube videos (shudder)? And > others. > - Start hitting them on the head with a baseball bat? ? > I've actually started talking to my family a lot about using it and getting my parents to use GNUPG. I think the biggest problem is "too many paths" to accomplish what is needed. There's so much software and so many recommendations that you, as an expert explaining to your friends, need to show them a single path and say, "This is how it is done." I've written a document for my family and regularly link it on facebook encouraging friends and family to use it. Warning to PGP experts, the terminology is dumbed down and the concepts are filtered so not everything is technically correct but explained in a way that the user can understand. Also, it's a few pages of text and mostly screen shots. I tried making it fun somewhat so bear with the imagery. http://www.pages.drexel.edu/~sag47/privacy_for_everyone.pdf SAM -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Wed Apr 9 19:58:40 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 09 Apr 2014 13:58:40 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: References: Message-ID: <53458A50.2050906@sixdemonbag.org> > The ?secure communications? paradigm of course spans a whole spectrum > from ?I don?t give a ****? to ?I?ll do anything to protect my > communications, including giving away my first born?. I suspect the > ?average Joe user? in 2014 is slightly above the former, but way below > the latter. Without going to the other end of the spectrum, what will > make adoption of secure communications a bit more palatable to the > ?average Joe user?? Every year or so this subject comes up, and my answers are unchanged from last time: start by reading up on academic papers studying this exact problem. For a while John Clizbe and I kept a list of good papers, but I have to confess I haven't been keeping up on the latest literature. Still, our last list is pretty good reading. (These selections come from both John and me, but John is the one who assembled them into proper cite format -- thanks, John. For the original message, see "Re: what is killing PKI?" on this mailing list, posted on 24 Aug 2012.) ===== Gaw, S., Felten, E. W., and Fernandez-Kelly, P. 2006. Secrecy, flagging, and paranoia: adoption criteria in encrypted email. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Montreal, Quebec, Canada, April 22 - 27, 2006). R. Grinter, T. Rodden, P. Aoki, E. Cutrell, R. Jeffries, and G. Olson, Eds. CHI '06. ACM, New York, NY, 591-600. DOI= http://doi.acm.org/10.1145/1054972.1055069 Garfinkel, S. L., Margrave, D., Schiller, J. I., Nordlander, E., and Miller, R. C. 2005. How to make secure email easier to use. In _Proceedings of the SIGCHI Conference on Human Factors in Computing Systems_ (Portland, Oregon, USA, April 02 - 07, 2005). CHI '05. ACM, New York, NY, 701-710. DOI= http://doi.acm.org/10.1145/1054972.1055069 Alma Whitten and J.D. Tygar. Why Johnny Can?t Encrypt: A Usability Evaluation of PGP 5.0. In Proceedings of the 8th USENIX Security Symposium, Washington, DC, August 1999. http://bit.ly/OaEeTD Steve Sheng, Levi Broderick, Colleen Alison Koranda, and Jeremy J. Hyland. Why Johnny Still Can?t Encrypt: Evaluating the Usability of Email Encryption Software. Poster session, 2006 Symposium On Usable Privacy and Security, Pittsburgh, PA, July 2006. http://cups.cs.cmu.edu/soups/2006/posters/sheng-poster_abstract.pdf From kappu at hotmail.com Wed Apr 9 20:07:49 2014 From: kappu at hotmail.com (Kapil Aggarwal) Date: Wed, 9 Apr 2014 14:07:49 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: <53458A50.2050906@sixdemonbag.org> References: <53458A50.2050906@sixdemonbag.org> Message-ID: I have. I was hoping there has been atleast a small rise in user perception about secure communications and newer software platforms/delivery channels that are beneficial. -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Robert J. Hansen Sent: Wednesday, April 09, 2014 1:59 PM To: gnupg-users at gnupg.org Subject: Re: It's 2014. Are we there yet? > The "secure communications" paradigm of course spans a whole spectrum > from "I don't give a ****" to "I'll do anything to protect my > communications, including giving away my first born". I suspect the > "average Joe user" in 2014 is slightly above the former, but way below > the latter. Without going to the other end of the spectrum, what will > make adoption of secure communications a bit more palatable to the > "average Joe user"? Every year or so this subject comes up, and my answers are unchanged from last time: start by reading up on academic papers studying this exact problem. For a while John Clizbe and I kept a list of good papers, but I have to confess I haven't been keeping up on the latest literature. Still, our last list is pretty good reading. (These selections come from both John and me, but John is the one who assembled them into proper cite format -- thanks, John. For the original message, see "Re: what is killing PKI?" on this mailing list, posted on 24 Aug 2012.) ===== Gaw, S., Felten, E. W., and Fernandez-Kelly, P. 2006. Secrecy, flagging, and paranoia: adoption criteria in encrypted email. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Montreal, Quebec, Canada, April 22 - 27, 2006). R. Grinter, T. Rodden, P. Aoki, E. Cutrell, R. Jeffries, and G. Olson, Eds. CHI '06. ACM, New York, NY, 591-600. DOI= http://doi.acm.org/10.1145/1054972.1055069 Garfinkel, S. L., Margrave, D., Schiller, J. I., Nordlander, E., and Miller, R. C. 2005. How to make secure email easier to use. In _Proceedings of the SIGCHI Conference on Human Factors in Computing Systems_ (Portland, Oregon, USA, April 02 - 07, 2005). CHI '05. ACM, New York, NY, 701-710. DOI= http://doi.acm.org/10.1145/1054972.1055069 Alma Whitten and J.D. Tygar. Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0. In Proceedings of the 8th USENIX Security Symposium, Washington, DC, August 1999. http://bit.ly/OaEeTD Steve Sheng, Levi Broderick, Colleen Alison Koranda, and Jeremy J. Hyland. Why Johnny Still Can't Encrypt: Evaluating the Usability of Email Encryption Software. Poster session, 2006 Symposium On Usable Privacy and Security, Pittsburgh, PA, July 2006. http://cups.cs.cmu.edu/soups/2006/posters/sheng-poster_abstract.pdf _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From cwal989 at comcast.net Wed Apr 9 20:35:14 2014 From: cwal989 at comcast.net (Christopher J. Walters) Date: Wed, 09 Apr 2014 14:35:14 -0400 Subject: Heartbleed attack on Openssl / Pertinent? I say yes. In-Reply-To: <53458C9E.9000808@sixdemonbag.org> References: <53457A88.6050804@sixdemonbag.org> <53458B70.2060800@comcast.net> <53458C9E.9000808@sixdemonbag.org> Message-ID: <534592E2.9040600@comcast.net> On 4/9/2014 2:08 PM, Robert J. Hansen wrote: >> safe. How would you protect your home and valuables then? That is the >> type of problem that Heartbleed is, and it IMO needs to be posted >> EVERYWHERE, so that people can at least try to protect themselves. > > Please re-read my message. I never told him to post elsewhere or that > it was off-topic for this list. I simply told him where he might get > better answers. If I was still teaching at the university and a student > came by looking for help with calculus homework, my first response would > be, "Well, you're in the Computer Science department; the Math > department is at the other end of this hallway." > > And my second response would be, "But maybe I can help you: let's see." > > :) Believe it or not, I did read your message. I did not mean to accuse you of telling him to post elsewhere or that it was off-topic for the list. I am sorry if you got that impression. I just feel the the issue is very important, and needs to be "shouted from the roof tops", as the saying goes. Again, my message was nothing personal against you. I just thought I'd provide more information on the bug. My message has not shown up on the list, yet. Is the list moderated, or is it just an issue of a reply to a message showing up before the actual message does? From cwal989 at comcast.net Wed Apr 9 20:35:36 2014 From: cwal989 at comcast.net (Christopher J. Walters) Date: Wed, 09 Apr 2014 14:35:36 -0400 Subject: Heartbleed attack on Openssl / Pertinent? I say yes. In-Reply-To: <53457A88.6050804@sixdemonbag.org> References: <53457A88.6050804@sixdemonbag.org> Message-ID: <534592F8.3090206@comcast.net> On 4/9/2014 12:51 PM, Robert J. Hansen wrote: >> Dear GNUPG community, > > That right there should be your first hint. :) > > This is a great email list to get informed opinions on GnuPG and the > OpenPGP RFCs, but this may not be a great place to get informed > commentary on OpenSSL. It's a completely different software package run > by a completely different outfit. > > You may get better answers if you ask on the OpenSSL mailing lists. :) You're right in the respect that this list is only for GnuPG and OpenPGP RFC support. However, the Heartbleed vulnerability is such a pervasive Internet security issue that everyone needs to be made aware of it, so that they may become educated on it. In my experience, the majority of Internet users take for granted that their Internet banking, shopping, and all other "secure" uses of the Internet are, in fact, truly *secure*. This vulnerability affect the entire SSL of the Internet (since the majority of clients and servers use OpenSSL) - that makes every site vulnerable to spoofing, and everyone who uses the Internet for any secure transactions vulnerable to identity theft. This bug *should* have been reported across the whole Internet when it was discovered about 2 years ago, but even now, no one wants to talk or hear about it anywhere. Imagine if ALL companies that produce locks, safes, and provide home security had a security problem that would allow anyone who knew about the problem to anonymously get keys (or even master keys) to any lock, and to override any home security system, and get the combination to any safe. How would you protect your home and valuables then? That is the type of problem that Heartbleed is, and it IMO needs to be posted EVERYWHERE, so that people can at least try to protect themselves. Regards, Chris From sam.mxracer at gmail.com Wed Apr 9 21:37:05 2014 From: sam.mxracer at gmail.com (Sam Gleske) Date: Wed, 9 Apr 2014 15:37:05 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: <53459E1B.60002@fifthhorseman.net> References: <53459E1B.60002@fifthhorseman.net> Message-ID: On Wed, Apr 9, 2014 at 3:23 PM, Daniel Kahn Gillmor wrote: > Hi Sam-- > > [offlist for now, see why below] > > On 04/09/2014 01:29 PM, Sam Gleske wrote: > > I've written a document for my family and regularly link it on facebook > > encouraging friends and family to use it. Warning to PGP experts, the > > terminology is dumbed down and the concepts are filtered so not > everything > > is technically correct but explained in a way that the user can > > understand. Also, it's a few pages of text and mostly screen shots. I > > tried making it fun somewhat so bear with the imagery. > > > > http://www.pages.drexel.edu/~sag47/privacy_for_everyone.pdf > > I'm really glad to see popularization of these tools. thank you for > writing this up. i also really like your tinfoil hat photograph :) But... > > i read your disclaimer above, but the document (sha1sum > 6dac22e5fa1095638149a537d6a3b641ad2dd551) has dangerously misleading > directions. I strongly recommend you take it down for now while we > figure out what to do about it. > > I haven't reviewed the whole document yet, but page 15 is particularly > troubling. the problem is that you describe the concept of key > validity, but associate it with key ownertrust. > > key validity is "does this key belong to a person whose name and e-mail > are indicated in the User ID?" > > key ownertrust is "am i willing to rely on identity certifications made > by the holder of this key?" > > These are entirely separate questions. I may know for sure that my > boss's key belongs to my boss, but i don't want her to be able to create > a new key that appears to belong to my husband, certify it, and send me > mail that would then appear to come from my husband. Even worse, i > wouldn't want my mail to my husband to be encrypted to this bogus key, > because my boss could then read the contents of the mail. > > There are other problems with the text, including (from a quick skim, > not exhaustive, ordered from trivial to security-critical): > > * page 17 is far too much information about a useless-at-best feature > (see [0]) > > * the document recommends the use of pgp.mit.edu instead of the > standard pool.sks-keyservers.net > > * the document discourages the creation of revocation certificates > > * page 11 seems to assume that "asking their key ID" is sufficient to > verify identity, though this is distinctly not the case [1]. this is > seriously insecure. I can send you a new OpenPGP key show private half > i control, but with your user ID and your keyID later if you need > convincing. :/ > > I recommend you read the riseup/debian OpenPGP best practices document > [2] and the GnuPG DETAILS document and consider trying to align your > document with the information and recommendations in those materials. > > I've left this message offlist for now, because i'm hoping you'll follow > up on the message publicly and make it clear what your plan is with this > document; If you'd like, either you or i can post these concerns > publicly, and we can have the discussion on-list. But i think a quick > note from you asking people not to rely on the current draft of that > document while you revise it for clarity and correctness would be great. > > let me know what you think. sorry to send you a lengthy critique, and i > hope it doesn't discourage you from continuing to spread the word about > encryption. It's just important to avoid making recommendations that > give people a sense of security that turns out to leave them vulnerable > in hidden ways. > > All the best, > > --dkg > > [0] https://www.debian-administration.org/users/dkg/weblog/98 > [1] https://www.debian-administration.org/users/dkg/weblog/105 > [2] https://we.riseup.net/debian/openpgp-best-practices > > I agree with your concerns. In reality I only started using GPG a few weeks ago which would explain my amateurish approach I suppose. There is a source document written in openoffice... http://www.pages.drexel.edu/~sag47/privacy_for_everyone.odt Also, I have created sha1 files... just append *.sha1 to the file name e.g. http://www.pages.drexel.edu/~sag47/privacy_for_everyone.odt.sha1 For now I have removed the PDF since I have widely distributed the link to the PDF so that people don't download it and receive misinformation. The odt file remains. I'm open to editing the document for clarity and fact checking. Once, an acceptable revised copy is well received on the list then I'll recreate a PDF and upload it again. SAM -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmv1992 at gmail.com Wed Apr 9 23:48:57 2014 From: fmv1992 at gmail.com (Felipe Vieira) Date: Wed, 9 Apr 2014 18:48:57 -0300 Subject: Heartbleed attack on Openssl Message-ID: So going back to the original question as I can see there is no disagreement on its importance: *1) What are the consequences to the ordinary user? * All the news are lacking information on that. Can you point relevant examples? All I could gather is that the only major/well known server to be compromised was Yahoo. For example: Gmail and Dropbox and Hotmail seem to be imune to this. I also found out that Mozilla/Firefox browser were also imune. If I would persuade someone of this bug's importance, which other examples could I give? 2) (specific question) Does Firefox use openssl to connect to some servers while browsing? 3) How about Ubuntu and other OSs? Do they use openssl to update themselves? (as in "apt-get update && apt-get upgrade"). Be as clear and basic as possible. In the context of "It's 2014. Are we there yet?" thread, I would like more shocking/tangible examples to suggest friends to start thinking of cryptography (and then we are back to gnupg). Thanks again. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete at heypete.com Thu Apr 10 00:45:55 2014 From: pete at heypete.com (Pete Stephenson) Date: Thu, 10 Apr 2014 00:45:55 +0200 Subject: Heartbleed attack on Openssl In-Reply-To: References: Message-ID: On Apr 10, 2014 12:22 AM, "Felipe Vieira" wrote: > > So going back to the original question as I can see there is no disagreement on its importance: > 1) What are the consequences to the ordinary user? > All the news are lacking information on that. Can you point relevant examples? Any service using a vulnerable version of OpenSSL in the last two years could have been silently attacked, with the attackers being able to gain access to information stored in the servers memory. The attacker might get memory containing empty sections, boring system files, secret cryptographic keys (the compromise of which could, in some cases, lead to user data being decrypted or a MITM being possible with no warnings), user data, etc. Its not clear of any bad guys knew about the bug prior to the announcement. If they didn't and one patched any affected servers as soon as possible, then the effects would be quite minimal. If they did know and exploited things, or if one has not yet patched vulnerable systems, things could be very bad. In short: the consequences could be dire but there is no way of knowing for certain what, if any, things have been compromised. Its probably best to assume the worst. > All I could gather is that the only major/well known server to be compromised was Yahoo. Yahoo fixed the issue shortly after the public announcement of the bug. It is not clear of bad guys were able to compromise their systems before it was fixed, but researchers were able to successfully probe various systems at Yahoo prior to the fix, so one should assume bad guys could do the same. > For example: Gmail and Dropbox and Hotmail seem to be imune to this. I also found out that Mozilla/Firefox browser were also imune. If I would persuade someone of this bug's importance, which other examples could I give? No service using an affected version of OpenSSL is immune. Some (like Cloudflare) received advanced notice and patched their systems before the public announcement, while others may have used other SSL libraries or versions of OpenSSL that were not vulnerable. > 2) (specific question) Does Firefox use openssl to connect to some servers while browsing? No. Firefox is immune because it uses the NSS Crypto library. The issue typically exists on and affects servers. A server using an affected version of OpenSSL is vulnerable regardless of what browser clients use. > 3) How about Ubuntu and other OSs? Do they use openssl to update themselves? (as in "apt-get update && apt-get upgrade"). Ubuntu and Debian use GnuPG to sign packages but updates typically take place over unencrypted connections. The update mechanism is not affected by this bug. Cheers! -Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.mxracer at gmail.com Thu Apr 10 01:10:10 2014 From: sam.mxracer at gmail.com (Sam Gleske) Date: Wed, 9 Apr 2014 19:10:10 -0400 Subject: Heartbleed attack on Openssl In-Reply-To: References: Message-ID: On Wed, Apr 9, 2014 at 6:45 PM, Pete Stephenson wrote: > On Apr 10, 2014 12:22 AM, "Felipe Vieira" wrote: > > > > So going back to the original question as I can see there is no > disagreement on its importance: > > 1) What are the consequences to the ordinary user? > > All the news are lacking information on that. Can you point relevant > examples? > > In short: the consequences could be dire but there is no way of knowing > for certain what, if any, things have been compromised. Its probably best > to assume the worst. > ^ That. Assume the worst because the vulnerability was there for two years. Not sure who you're having a hard time convincing but send them to heartbleed.com. The first three paragraphs are for high flying executives whose "business critical documents" are at risk. > > For example: Gmail and Dropbox and Hotmail seem to be imune to this. I > also found out that Mozilla/Firefox browser were also imune. If I would > persuade someone of this bug's importance, which other examples could I > give? > What type of person are you trying to persuade? If you download any of the vulnerability test scripts in the wild you'll notice that the 64k output is truncated and the script simply states "you're vulnerable". Edit that script so that it dumps the full 64k. While you're at it put that script in an infinite while loop and dump the output to a file on disk. Then use Firefox or chrome or whatever browser you want and log in to the service. When you're done search the file for your credentials. It doesn't matter what browser you're using. > > 2) (specific question) Does Firefox use openssl to connect to some > servers while browsing? > > No. Firefox is immune because it uses the NSS Crypto library. > I have verified this claim. (Firefox Version: 28.0+build2-0ubuntu0.12.04.1) $ dpkg -L firefox | while read x;do [ -f "${x}" ] && (if ldd "${x}" 2>/dev/null | grep libssl &>/dev/null;then echo "${x}";fi);done | while read x;do echo "${x}";ldd "${x}" 2>/dev/null | grep libssl;done /usr/lib/firefox/components/libmozgnome.so libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so (0x00007ffd9d836000) /usr/lib/firefox/components/libdbusservice.so libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so (0x00007f778ceda000) /usr/lib/firefox/libxul.so libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so (0x00007f326e660000) /usr/lib/firefox/browser/components/libbrowsercomps.so libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so (0x00007fa4537f3000) /usr/lib/firefox/plugin-container libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so (0x00007f0807de7000) $ dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so libnss3: /usr/lib/x86_64-linux-gnu/libssl3.so If it was openssl then it would be linked to /lib/x86_64-linux-gnu/libssl.so.1.0.0 which is a part of the libssl1.0.0 package which is a dependency of the openssl package. > The issue typically exists on and affects servers. A server using an > affected version of OpenSSL is vulnerable regardless of what browser > clients use. > While it's true Firefox does not link openssl in binaries the vulnerability allows an attacker to easily hijack sessions, steal usernames and passwords, and steal the server private key during the SSL negotiation phase. See my comments above for how you can verify that. > > 3) How about Ubuntu and other OSs? Do they use openssl to update > themselves? (as in "apt-get update && apt-get upgrade"). > > Ubuntu and Debian use GnuPG to sign packages but updates typically take > place over unencrypted connections. The update mechanism is not affected by > this bug. > True. $ grep -rH 'http:' /etc/apt/sources.list* I'm not sure who you're trying to convince, Felipe, but HOPEFULLY you have already handled this bug by patching and added rules to your intrusion detection system for packets trying to attack SSL using this method (the attack packets look very different from normal SSL communication). Pete, forgive me breaking down your reply but I found it a good exercise in attempting to verify your claims. Environment KUbuntu 12.04.4 LTS Linux 3.8.0-37-generic x86_64 SAM -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Apr 10 01:20:09 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 09 Apr 2014 19:20:09 -0400 Subject: Heartbleed attack on Openssl In-Reply-To: References: Message-ID: <5345D5A9.6080007@sixdemonbag.org> > 1) What are the consequences to the ordinary user? None. The ordinary user is such an easy target that as bad as this attack is, I don't see it as making things any worse. > All the news are lacking information on that. Can you point relevant > examples? Not yet. Give it a few days: news reports will develop, Wikipedia will be updated, and so on. > 2) (specific question) Does Firefox use openssl to connect to some > servers while browsing? https://www.google.com/search?q=does+firefox+use+openssl No, it does not. Nor does Chrome. > 3) How about Ubuntu and other OSs? Do they use openssl to update > themselves? (as in "apt-get update && apt-get upgrade"). Usually not. Repositories are normally accessed via HTTP, not HTTPS. From sam.kuper at uclmail.net Thu Apr 10 00:36:25 2014 From: sam.kuper at uclmail.net (Sam Kuper) Date: Wed, 9 Apr 2014 23:36:25 +0100 Subject: It's 2014. Are we there yet? In-Reply-To: References: Message-ID: On 09/04/2014, Kapil Aggarwal wrote: > Now, what will help drive this adoption more? > > All thoughts are very much welcome and appreciated. One possible answer: https://www.mailpile.is/faq/ I haven't tried it myself, btw. From dkg at fifthhorseman.net Thu Apr 10 01:34:44 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 09 Apr 2014 19:34:44 -0400 Subject: Heartbleed attack on Openssl In-Reply-To: <5345D5A9.6080007@sixdemonbag.org> References: <5345D5A9.6080007@sixdemonbag.org> Message-ID: <5345D914.7020502@fifthhorseman.net> On 04/09/2014 07:20 PM, Robert J. Hansen wrote: > No, it does not. Nor does Chrome. Chromium (from which chrome is based) actually embeds a copy of openssl, but doesn't use it for its TLS implementation, which is where the bug would be triggered. (i'm not sure why they do this embedding actually, i haven't reviewed it). >> 3) How about Ubuntu and other OSs? Do they use openssl to update >> themselves? (as in "apt-get update && apt-get upgrade"). > > Usually not. Repositories are normally accessed via HTTP, not HTTPS. even if they were accessed via https, this bug wouldn't have caused any problem greater than a malicious attacker on the network being able to see what packages you were downloading, and/or making you fetch an older version of the repo you're looking at (or giving you "this repository can't be authenticated" warnings). This is the same situation you're in when you download via HTTP, though, so it's not a big deal in this context. Your software updates for apt and yum are secured by OpenPGP signatures over the archives themselves, which are made (for responsible repositories anyway) via secret keys that aren't exposed to the web servers that host the archives. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From one.jsim at gmail.com Thu Apr 10 00:37:52 2014 From: one.jsim at gmail.com (One Jsim) Date: Wed, 9 Apr 2014 23:37:52 +0100 Subject: PGP/GPG does not work easily with web-mail. Message-ID: PGP/GPG does not work easily with web-mail. Most email, today, is read and write using the browser POP ou IMAP mail is a rarity That is the problem Some text/link in this problem? Jos? Sim?es -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Apr 10 01:42:24 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 09 Apr 2014 19:42:24 -0400 Subject: Heartbleed attack on Openssl In-Reply-To: <5345D914.7020502@fifthhorseman.net> References: <5345D5A9.6080007@sixdemonbag.org> <5345D914.7020502@fifthhorseman.net> Message-ID: <5345DAE0.3050901@sixdemonbag.org> > Chromium (from which chrome is based) actually embeds a copy of openssl, > but doesn't use it for its TLS implementation, which is where the bug > would be triggered. (i'm not sure why they do this embedding actually, > i haven't reviewed it). I have heard that Chrome is migrating to OpenSSL instead of Mozilla's NSS libraries; it's possible Chromium is a testbed. Speculation on my part, though. From fmv1992 at gmail.com Thu Apr 10 01:53:28 2014 From: fmv1992 at gmail.com (Felipe Vieira) Date: Wed, 9 Apr 2014 20:53:28 -0300 Subject: Heartbleed attack on Openssl Message-ID: Thanks everyone for the quick and complete feedback. New questions arose: 1) Firefox uses NSS instead of OpenSSL. Still it can communicate with a OpenSSL based server (say X) and thus the browser's type is irrelevant. The communication between browser and X could be eavesdropped. Is that correct? 2) If the first answer is yes, only the X service credentials/data could be stolen or does that compromis the whole browser session (e.g.: communication browser - service Y and browser - service Z)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekleog at gmail.com Thu Apr 10 01:57:38 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Thu, 10 Apr 2014 01:57:38 +0200 Subject: PGP/GPG does not work easily with web-mail. In-Reply-To: References: Message-ID: <20140409235738.GA28111@leortable> On Wed, Apr 09, 2014 at 11:37:52PM +0100, One Jsim wrote: > PGP/GPG does not work easily with web-mail. > > Most email, today, is read and write using the browser > > POP ou IMAP mail is a rarity > > That is the problem > > Some text/link in this problem? > > Jos? Sim?es Well... I started to write a firefox addon, but never had enough time to finish it. Perhaps later. If anyone wishes to get what I've done (that is, a js-ctype binding of gpgme, along with tests AFAICR), I can try to locate the source code! However, a major issue remains the encryption of HTML documents, which is, AFAICT, not possible today (well, not automatically at least, as of course gpg can be used to sign html files); and besides not obviously secure: what about white-on-white text and such? I don't doubt there are fixes for such, and most isn't even an issue; I just remember enigmail forbids it, so I guess there are reasons. Sorry for not helping you more, Leo From timprepscius at gmail.com Thu Apr 10 04:40:01 2014 From: timprepscius at gmail.com (Tim Prepscius) Date: Wed, 9 Apr 2014 22:40:01 -0400 Subject: request for pgp encrypted messages for testing Message-ID: Hey there, As I've said before, I'm working on a PGP based web mail program. https://github.com/timprepscius/mv The whole thing is GPL-Affero. Copy, steal, add, reduce, as you wish. Demonstration is here (which is often killed/reset/etc/so...): http://pmx.mooo.com/ And some screenshots: http://tinypic.com/r/2ljmj9i/8 http://tinypic.com/r/4vp7hu/8 Also, if anyone is interested in what the db looks like (without actually setting it up for yourself) http://pmx.mooo.com/mv/util/Dump ----- At this point I'm at 100% for testing signatures of messages (both inline and pgp-mime). (Prob actually 95% but not enough test cases yet.) I need more messages testing encryption. I have found a few bugs in openpgpjs concerning mime signing, and am dubious that it will function perfectly with pgp-encryption. If anyone here would like to help, please send an encrypted message to: g at pmx.mooo.com g's public key is here: http://pastebin.com/raw.php?i=RAi8cfjC If you would like your message to be placed in a public repository of these messages, please include that in the encrypted block. Please send whatever you'd like, html/text/attachment/etc. My email address is timprepscius at gmail.com. You can let me know through the gmail if mooo does not go through (I'm using postfix default settings) Thank you to those who have already helped, and thank you all for your time previously (with regard to the mime signing issues) -tim From rjh at sixdemonbag.org Thu Apr 10 05:13:56 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 09 Apr 2014 23:13:56 -0400 Subject: Heartbleed attack on Openssl In-Reply-To: References: Message-ID: <53460C74.2000208@sixdemonbag.org> > Thanks everyone for the quick and complete feedback. New questions arose: Again, you will have better luck asking on an OpenSSL mailing list. There is no guarantee that anyone on this mailing list is an expert in OpenSSL. > The communication between browser and X could be eavesdropped. Is that > correct? Someone else could connect to X and use Heartbleed to scan the contents of X's memory. Anything sent to X could be considered compromisable for so long as it's stored in X's RAM. From akwala at gmail.com Thu Apr 10 04:16:44 2014 From: akwala at gmail.com (a k'wala) Date: Wed, 9 Apr 2014 22:16:44 -0400 Subject: PGP/GPG does not work easily with web-mail. Message-ID: You may want to look at these: - http://www.mailvelope.com/ - https://chrome.google.com/webstore/detail/mymail-crypt-for-gmail/jcaobjhdnlpmopmjhijplpjhlplfkhba/details - https://www.penango.com/products ??Some info about the above: http://www.makeuseof.com/tag/encrypt-your-gmail-hotmail-and-other-webmail-heres-how/ ? ?Also, this is a promising project: https://www.mailpile.is/? --aslamK http://gplus.to/akwala PGP key (id: FECF84FB) fingerprint: 736C D83E 32DB A2FD 0208 9113 0FC8 BA7D FECF 84FB On Wed, Apr 9, 2014 at 6:37 PM, One Jsim wrote: > PGP/GPG does not work easily with web-mail. > > Most email, today, is read and write using the browser > > POP ou IMAP mail is a rarity > > That is the problem > > Some text/link in this problem? > > Jos? Sim?es > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent.jumet at skynet.be Thu Apr 10 06:06:33 2014 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Thu, 10 Apr 2014 06:06:33 +0200 Subject: Heartbleed attack on Openssl In-Reply-To: <5345D5A9.6080007@sixdemonbag.org> Message-ID: Hello Robert ! "Robert J. Hansen" wrote: >> 1) What are the consequences to the ordinary user? > None. The ordinary user is such an easy target that as bad as this > attack is, I don't see it as making things any worse. Does it make sense to disable SSL in my browser for a couple of weeks? HTTPS is linked with TLS v1.2 128 bit ARC4 (2048 bit RSA/SHA) instead. -- Laurent Jumet KeyID: 0xCFAF704C From dougb at dougbarton.us Thu Apr 10 06:22:19 2014 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 09 Apr 2014 21:22:19 -0700 Subject: Heartbleed attack on Openssl In-Reply-To: References: Message-ID: <53461C7B.4070205@dougbarton.us> On 4/9/2014 9:06 PM, Laurent Jumet wrote: > Does it make sense to disable SSL in my browser for a couple of weeks? No, but for my own curiosity what is your thought process that leads you to ask that question? Doug From rjh at sixdemonbag.org Thu Apr 10 06:35:52 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 10 Apr 2014 00:35:52 -0400 Subject: Heartbleed attack on Openssl In-Reply-To: References: Message-ID: <53461FA8.3050808@sixdemonbag.org> On 4/10/2014 12:06 AM, Laurent Jumet wrote: > Does it make sense to disable SSL in my browser for a couple of weeks? > HTTPS is linked with TLS v1.2 128 bit ARC4 (2048 bit RSA/SHA) instead. I am flattered that you think I am a mind reader, but I assure you, I am not able to use the Heartbleed attack to pull important information out of your frontal cortex -- like what operating system you're using, what browser you're using, and so on and so on. At any rate, these are questions for your browser vendor. From timprepscius at gmail.com Thu Apr 10 07:40:56 2014 From: timprepscius at gmail.com (Tim Prepscius) Date: Thu, 10 Apr 2014 01:40:56 -0400 Subject: PGP/GPG does not work easily with web-mail Message-ID: PGP actually does work well with web mail. There are two libraries which do pgp encryption, there are 3 that I know which do AES-SHA256-CBC-PKCS7. There are at least two libraries which do pkdf2 sha 256. There is also one library which does AES-SHA256-GCM, but I'm not sure if it does pkcs7 or not. (or whether padding is incorporated into GCM, need to research). Looking up keys on a pgp key server is trivial, registering a key is also trivial. --- However there are some legitimate concerns. The most important to my mind are javascript injection attacks. For instance, let's say the NSA takes over your web-mail server. You think, "well my users' data is fine, because all of the encryption is happening client side, I never see any of the keys, etc." However the NSA could *force* you to place code inside your server which tells the client to send the keys to you randomly. This would be difficult (not impossible) to detect, and when executed *once* would completely destroy the privacy of the target machine forever. Generally these days, (at least the conversations I've been reading), people are talking about making "plugins" out of the client side code and protecting them through the app store. So, I download the app for the client, I check it's signature. It *NEVER* downloads code again. I think there are some other solutions to this problem, which I could babble about, but won't right here. However, there are still attacks. For instance, I'm the NSA, I've spent the hours necessary reading through your code to know that if I write you an email with SO-and-SO pattern, when you display that e-mail my script will be run. That script then would destroy the privacy. This is a very hard attack to guard against. --- In my webmail I'm developing (I wrote one previously using GWT which was too complicated, too difficult to maintain and enhance, this one is much simpler). My goals are three fold: 1. raise the cost of the NSA exponentially. I want them to have to spend considerable time for each target, instead of just "hey Google, give me these 20,000 peoples' email." 2. re-normalize the idea of privacy. Google has pretty much destroyed privacy. And they are trying to destroy anonymity as well. I believe it is important to have by this year's end at least 10 services running which re-normalize privacy in e-mail. Each service hopefully will castigate Google and call them for what they are. 3. give "good" security. Nothing will protect you if you are *actually* some terrorist or something, but it would be nice if we weren't being big-brothered *all* of the time. --- I encourage you to look at those others people referenced. Also, if you care to, take a look at mine as well. https://github.com/timprepscius/mv If you need any help setting up a server, let me know. If you are versed in sys-admin, it should take 5 minutes to get a VM running, or use something like DigitalOcean. The benefits of my server, (I think), is that you should be able to change how it looks and feels without changing any of the fundamental code. Meaning you can change the html templates and css and what not, and it will still function correctly. It uses Backbone, so the rendering is clearly separated from the code/models. Anyhowz, If you are looking for perfect security, web mail is not the way to go. Hopefully a plugin will be able to provide near-ish the same security that a standalone program with no javascript interpreter might. But that doesn't mean that PGP WebMail won't be a billion-million times better than gmail. (can't wait to leave it! so close, soon soon) Good night, -tim From gnupg at lists.grepular.com Thu Apr 10 10:42:35 2014 From: gnupg at lists.grepular.com (Mike Cardwell) Date: Thu, 10 Apr 2014 09:42:35 +0100 Subject: PGP/GPG does not work easily with web-mail. In-Reply-To: References: Message-ID: <20140410084235.GA24985@glue.grepular.com> * on the Wed, Apr 09, 2014 at 11:37:52PM +0100, One Jsim wrote: > PGP/GPG does not work easily with web-mail. Roundcube plus the PGP plugin: http://roundcube.net/ https://github.com/qnrq/rc_openpgpjs The way it works is pretty cool. You paste your private PGP key into a form, and it doesn't get submitted to the server, it just gets stored in the browsers localstorage using JavaScript. So all PGP operations are done locally in the browser, rather than sending the key off to the server to do it server side. It's based on openpgp.js, which is basically a free javascript library for doing OpenPGP: http://openpgpjs.org/ The only problem is (and it's a big one), you have to trust the JavaScript that the server sends. The server could always send some evil JavaScript to you which reads the key from the browser storage and then sends it back to the server or elsewhere. Also, if there are any XSS flaws, there's another potential way of losing the key. -- Mike Cardwell https://grepular.com https://emailprivacytester.com OpenPGP Key 35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 598 bytes Desc: Digital signature URL: From simoes.two at gmail.com Wed Apr 9 23:08:31 2014 From: simoes.two at gmail.com (Jose Simoes) Date: Wed, 9 Apr 2014 22:08:31 +0100 Subject: It's 2014. Are we there yet? In-Reply-To: References: <53459E1B.60002@fifthhorseman.net> Message-ID: PGP/GPG does not work easily with web-mail. Most email, today, in read and write using the browser POP ou IMAP mail is a rarity That is the problem From p.h.delgado at xoxy.net Thu Apr 10 05:04:48 2014 From: p.h.delgado at xoxy.net (p.h.delgado at xoxy.net) Date: Thu, 10 Apr 2014 03:04:48 +0000 Subject: It's 2014. Are we there yet? In-Reply-To: References: Message-ID: <53460A50.90605@mail.ru> On 04/09/2014 04:39 PM, Kapil Aggarwal wrote: ... > > All thoughts are very much welcome and appreciated. > This was put together some time ago for a group of individuals with a specific use-case. This might not be generally applicable: it requires a fair bit of understanding of the fundamentals and it is operated in "command-line-mode". However, IMHO, it points those intent on implementing Public-Key-Encryption-for-general-computer-user-population in the right direction: ditching the whole WebOfTrust and key co-signing infrastructure in favour of simple, out-of-channel public key ownership verification. Comments are welcome. https://dl.dropboxusercontent.com/u/21922366/gnupg_simple/index.html delgado From erik.josefsson at europarl.europa.eu Thu Apr 10 11:24:47 2014 From: erik.josefsson at europarl.europa.eu (JOSEFSSON Erik) Date: Thu, 10 Apr 2014 09:24:47 +0000 Subject: It's 2014. Are we there yet? In-Reply-To: References: <53459E1B.60002@fifthhorseman.net> , Message-ID: <4B654B63C9A4614EA1F088B2490E8F3A069AC388@UCEXBWP009.ep.parl.union.eu> We're trying: https://wiki.debian.org/DebianParl/GreensEFA Still no IMAP though :-( //Erik ________________________________________ From: Gnupg-users [gnupg-users-bounces at gnupg.org] on behalf of Jose Simoes [simoes.two at gmail.com] Sent: Wednesday 9 April 2014 23:08 To: Gnupg-users Subject: Re: It's 2014. Are we there yet? PGP/GPG does not work easily with web-mail. Most email, today, in read and write using the browser POP ou IMAP mail is a rarity That is the problem _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From nb.linux at xandea.de Thu Apr 10 12:10:04 2014 From: nb.linux at xandea.de (nb.linux) Date: Thu, 10 Apr 2014 10:10:04 +0000 Subject: It's 2014. Are we there yet? In-Reply-To: References: <53459E1B.60002@fifthhorseman.net> Message-ID: <53466DFC.9080409@xandea.de> Jose Simoes: > PGP/GPG does not work easily with web-mail. > > Most email, today, in read and write using the browser > > POP ou IMAP mail is a rarity > > That is the problem You (and others) might be interested in the Tails OpenPGP Applet: https://tails.boum.org/doc/encryption_and_privacy/gpgapplet/ Tails is The Amnesic Incognito Live System, a hardened Live System with Tor. I'm not sure, but I think that there are plans to include that into Debian. From mwood at IUPUI.Edu Thu Apr 10 16:50:06 2014 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Thu, 10 Apr 2014 10:50:06 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: References: Message-ID: <20140410145005.GB9865@IUPUI.Edu> On Wed, Apr 09, 2014 at 12:39:44PM -0400, Kapil Aggarwal wrote: > Let's list a few arguments: [snip] > - WTF is a key pair/public key/private key/ terminology>. - J This IS a big problem. I may get it, you may get it, how > does the average Joe user gain that understanding? The nomenclature needs to > be, well, something that the average Joe user can understand as well. They > understood SSL (well, for the most part). I think this one is easy. The key pair is a mathematical analog of the old spy trick (I'm sure it's in the movies somewhere) of tearing a playing card in two, giving one piece to each of two people who do not know each other but must be able to recognize one another. No two cards tear *exactly* the same way. And the math does this *much* better. I thought that the tradition of the mizpah coin would serve as well, but I haven't found a good explanation, just advertising and Biblical backgrounders. As I recall, someone thought to break a soft metal coin in two, so that the jagged edges would symbolize a unique relationship, and somehow related it back to the story of the cairn of stones that symbolized an agreement with God as witness. Nowadays they mint the things in two pieces, very stylized, and you buy them already separated. So maybe this is not so useful here. Anyway, the point is the same: a random process produces a unique boundary between two complementary pieces, which the holders can use to identify each other. A computer does it with mathematics that you don't have to fully understand, so long as you trust someone who does. If you need to see it in the physical world, just tear a piece of paper, or break a cookie in two, and contemplate the result. There are other things you can do with the jagged edges (so to speak) of these keys, to scramble and unscramble a message, because the two pieces are related, in a way too complex to easily guess if you don't have one of them. Go ahead: pick up a pencil and paper, and try to predict the EXACT shape of the torn edges of a card without seeing it. One thing you must understand is that the keys are related *mathematically*, not physically. *Unlike* the card, knowing one shape does not automatically give you the other. This is useful: it means that you have a secret which you don't have to share to prove that you know it. After that, it's all just multiplying impossibly huge numbers. That's dumbed down considerably, but I think it gets the basic idea across simply. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Machines should not be friendly. Machines should be obedient. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From kappu at hotmail.com Thu Apr 10 18:23:07 2014 From: kappu at hotmail.com (Kapil Aggarwal) Date: Thu, 10 Apr 2014 12:23:07 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: <20140410145005.GB9865@IUPUI.Edu> References: <20140410145005.GB9865@IUPUI.Edu> Message-ID: If you gave that explanation to my wife.... :) Her eyes would glaze over before you finished the first paragraph. Not that I disagree with you and it is actually a very sane/less complex explanation. My point is that the average Joe user equates SSL with "web security" for e.g. Whether this notion is right or wrong, doesn't matter, it's what he/she believes. They don't understand SSL any better than PGP/GPG etc. yet they "believe" in it. Somehow the message of "secure communications" needs to be at the same level of simplicity and pervasiveness. -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Mark H. Wood Sent: Thursday, April 10, 2014 10:50 AM To: gnupg-users at gnupg.org Subject: Re: It's 2014. Are we there yet? On Wed, Apr 09, 2014 at 12:39:44PM -0400, Kapil Aggarwal wrote: > Let's list a few arguments: [snip] > - WTF is a key pair/public key/private key/ terminology>. - J This IS a big problem. I may get it, you may get it, > terminology>how > does the average Joe user gain that understanding? The nomenclature > needs to be, well, something that the average Joe user can understand > as well. They understood SSL (well, for the most part). I think this one is easy. The key pair is a mathematical analog of the old spy trick (I'm sure it's in the movies somewhere) of tearing a playing card in two, giving one piece to each of two people who do not know each other but must be able to recognize one another. No two cards tear *exactly* the same way. And the math does this *much* better. I thought that the tradition of the mizpah coin would serve as well, but I haven't found a good explanation, just advertising and Biblical backgrounders. As I recall, someone thought to break a soft metal coin in two, so that the jagged edges would symbolize a unique relationship, and somehow related it back to the story of the cairn of stones that symbolized an agreement with God as witness. Nowadays they mint the things in two pieces, very stylized, and you buy them already separated. So maybe this is not so useful here. Anyway, the point is the same: a random process produces a unique boundary between two complementary pieces, which the holders can use to identify each other. A computer does it with mathematics that you don't have to fully understand, so long as you trust someone who does. If you need to see it in the physical world, just tear a piece of paper, or break a cookie in two, and contemplate the result. There are other things you can do with the jagged edges (so to speak) of these keys, to scramble and unscramble a message, because the two pieces are related, in a way too complex to easily guess if you don't have one of them. Go ahead: pick up a pencil and paper, and try to predict the EXACT shape of the torn edges of a card without seeing it. One thing you must understand is that the keys are related *mathematically*, not physically. *Unlike* the card, knowing one shape does not automatically give you the other. This is useful: it means that you have a secret which you don't have to share to prove that you know it. After that, it's all just multiplying impossibly huge numbers. That's dumbed down considerably, but I think it gets the basic idea across simply. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Machines should not be friendly. Machines should be obedient. From rjh at sixdemonbag.org Thu Apr 10 21:33:07 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 10 Apr 2014 12:33:07 -0700 Subject: It's 2014. Are we there yet? In-Reply-To: <20140410145005.GB9865@IUPUI.Edu> References: <20140410145005.GB9865@IUPUI.Edu> Message-ID: <20140410123307.Horde.w8Lq9cSQxZP_qbXnHihANA1@mail.sixdemonbag.org> > I think this one is easy. The key pair is a mathematical analog of > the old spy trick (I'm sure it's in the movies somewhere) of tearing a > playing card in two, giving one piece to each of two people who do not > know each other but must be able to recognize one another. No two > cards tear *exactly* the same way. And the math does this *much* > better. I prefer an analogy of a mailbox. Anyone can drop a letter in my mailbox. You walk up to it, slip the letter through the mail slot, and you're done. However, only I have the key to my mailbox: once you've dropped it in my mail slot, you can no longer read your own message. After all, you don't have the key to my mailbox. And my mailbox doesn't have to be secret: it's public knowledge where it is. Anyone can drop a letter through the mail slot, and it doesn't affect the secrecy of the messages. Knowing how to leave a message for me doesn't help you read messages that other people leave for me, but if I lose the keys to my mailbox then I'm in a lot of trouble. Most of the people I deal with have used mailboxes and mail slots before. The analogy seems to work well with them. YMMV, of course. :) From kappu at hotmail.com Fri Apr 11 02:01:17 2014 From: kappu at hotmail.com (Kapil Aggarwal) Date: Thu, 10 Apr 2014 20:01:17 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: <20140410123307.Horde.w8Lq9cSQxZP_qbXnHihANA1@mail.sixdemonbag.org> References: <20140410145005.GB9865@IUPUI.Edu> <20140410123307.Horde.w8Lq9cSQxZP_qbXnHihANA1@mail.sixdemonbag.org> Message-ID: Now, that is something that would go down well with the average Joe user. Mucho Gracias. -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Robert J. Hansen Sent: Thursday, April 10, 2014 3:33 PM To: gnupg-users at gnupg.org Subject: Re: It's 2014. Are we there yet? > I think this one is easy. The key pair is a mathematical analog of > the old spy trick (I'm sure it's in the movies somewhere) of tearing a > playing card in two, giving one piece to each of two people who do not > know each other but must be able to recognize one another. No two > cards tear *exactly* the same way. And the math does this *much* > better. I prefer an analogy of a mailbox. Anyone can drop a letter in my mailbox. You walk up to it, slip the letter through the mail slot, and you're done. However, only I have the key to my mailbox: once you've dropped it in my mail slot, you can no longer read your own message. After all, you don't have the key to my mailbox. And my mailbox doesn't have to be secret: it's public knowledge where it is. Anyone can drop a letter through the mail slot, and it doesn't affect the secrecy of the messages. Knowing how to leave a message for me doesn't help you read messages that other people leave for me, but if I lose the keys to my mailbox then I'm in a lot of trouble. Most of the people I deal with have used mailboxes and mail slots before. The analogy seems to work well with them. YMMV, of course. :) _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From gnupg at tim.thechases.com Thu Apr 10 23:18:21 2014 From: gnupg at tim.thechases.com (Tim Chase) Date: Thu, 10 Apr 2014 16:18:21 -0500 Subject: Encrypted file-size approximation with multiple recipients In-Reply-To: <53422417.7080206@fifthhorseman.net> References: <20140401200128.46b62b28@bigbox.christie.dr> <015D1F30-1587-470E-860B-DDFC899BECF3@jabberwocky.com> <20140402120720.3ac7dcf2@bigbox.christie.dr> <53422417.7080206@fifthhorseman.net> Message-ID: <20140410161821.2a04f689@bigbox.christie.dr> On 2014-04-07 00:05, Daniel Kahn Gillmor wrote: > It sounds to me like you might be setting up some sort of automated > encrypted JSON message-passing scheme. If so, you should be aware > that if any of the encrypted JSON could be controlled by an > attacker, that attacker could possibly learn information about the > other parts of the message that are not controlled by them when > using compression, just by inspecting the size of the traffic. Thanks for the heads-up. If I understand you (after some further reading on CRIME attacks), this only is an issue in the event that a 3rd party is injecting content into the requests and then able to see the resulting encrypted data. In my use-case, the encrypting party is in control of the entire message (modulo some metadata controlled by my wrapping app, including nothing from other parties) so such a CRIME attack would have to be self-inflicted, and yield unsurprising results because it would reveal message content they already possess. Thanks, -Tim From cwal989 at comcast.net Thu Apr 10 22:33:15 2014 From: cwal989 at comcast.net (Christopher J. Walters) Date: Thu, 10 Apr 2014 16:33:15 -0400 Subject: Heartbleed attack on Openssl In-Reply-To: <53460C74.2000208@sixdemonbag.org> References: <53460C74.2000208@sixdemonbag.org> Message-ID: <5347000B.4090508@comcast.net> On 4/9/2014 11:13 PM, Robert J. Hansen wrote: >> Thanks everyone for the quick and complete feedback. New questions arose: > > Again, you will have better luck asking on an OpenSSL mailing list. > There is no guarantee that anyone on this mailing list is an expert in > OpenSSL. I, for one, admit that I am not an expert on OpenSSL. *IF* I were, I would be posting on the OpenSSL mailing lists about the bug. I doubt that ANYONE, including the OpenSSL community and developers know just how serious this bug has compromised the general security of the Internet, or what sites were actually (not theoretically could be) compromised. There is just not enough information to make any definitive statements on that issue, and there probably never will be given all of the other bugs (known and unknown) that can compromise a server's security. As for regular users, from what I've read, there is really no additional risk to what you face from spyware, keyloggers, other malware and upstream bugs. That is UNLESS you either use a vulnerable version of OpenSSL with a data storage / encryption application to store site user names and passwords, credit / debit card information, etc., or you run a server on your system that has a vulnerable version of OpenSSL. In any case, I have to agree with you, Robert, the best place for information is the official heartbleed site and the OpenSSL mailing lists. From JPClizbe at GingerBear.net Fri Apr 11 00:22:09 2014 From: JPClizbe at GingerBear.net (John Clizbe) Date: Thu, 10 Apr 2014 17:22:09 -0500 Subject: It's 2014. Are we there yet? In-Reply-To: <53458A50.2050906@sixdemonbag.org> References: <53458A50.2050906@sixdemonbag.org> Message-ID: <53471991.5070508@GingerBear.net> The send from last night seems to have gone astray. Robert J. Hansen wrote: >> The ?secure communications? paradigm of course spans a whole spectrum >> from ?I don?t give a ****? to ?I?ll do anything to protect my >> communications, including giving away my first born?. I suspect the >> ?average Joe user? in 2014 is slightly above the former, but way below >> the latter. Without going to the other end of the spectrum, what will >> make adoption of secure communications a bit more palatable to the >> ?average Joe user?? > > Every year or so this subject comes up, and my answers are unchanged > from last time: start by reading up on academic papers studying this > exact problem. For a while John Clizbe and I kept a list of good > papers, but I have to confess I haven't been keeping up on the latest > literature. Still, our last list is pretty good reading. > > (These selections come from both John and me, but John is the one who > assembled them into proper cite format -- thanks, John. For the > original message, see "Re: what is killing PKI?" on this mailing list, > posted on 24 Aug 2012.) > > ===== Oh yeah, THAT thread. There hasn't been much new work that I've seen. Certainly nothing invalidating any of these. The list along with available from links: Gaw, S., Felten, E. W., and Fernandez-Kelly, P. 2006. Secrecy, flagging, and paranoia: adoption criteria in encrypted email. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Montreal, Quebec, Canada, April 22 - 27, 2006). R. Grinter, T. Rodden, P. Aoki, E. Cutrell, R. Jeffries, and G. Olson, Eds. CHI '06. ACM, New York, NY, 591-600. DOI= http://doi.acm.org/10.1145/1054972.1055069 Available at: http://www.soe.ucsc.edu/classes/cmps223/Spring09/Gaw%2006.pdf I would also add Garfinkel, S. L., Margrave, D., Schiller, J. I., Nordlander, E., and Miller, R. C. 2005. How to make secure email easier to use. In _Proceedings of the SIGCHI Conference on Human Factors in Computing Systems_ (Portland, Oregon, USA, April 02 - 07, 2005). CHI '05. ACM, New York, NY, 701-710. DOI= http://doi.acm.org/10.1145/1054972.1055069 Available at: http://simson.net/ref/2004/chi2005_smime_submitted.pdf And a perennial favorite: Steve Sheng, Levi Broderick, Colleen Alison Koranda, and Jeremy J. Hyland. Why Johnny Still Can?t Encrypt: Evaluating the Usability of Email Encryption Software. Poster session, 2006 Symposium On Usable Privacy and Security, Pittsburgh, PA, July 2006. http://cups.cs.cmu.edu/soups/2006/posters/sheng-poster_abstract.pdf And its predecessor: Alma Whitten and J.D. Tygar. Why Johnny Can?t Encrypt: A Usability Evaluation of PGP 5.0. In Proceedings of the 8th USENIX Security Symposium, Washington, DC, August 1999. http://bit.ly/OaEeTD > > Everyone on this mailing list has their own pet theory for why PKI > > adoption is so lousy. All of us are probably wrong. However, > > published, peer-reviewed studies of PKI adoption and the forces driving > > and inhibiting them are probably less wrong. The peer reviewed literature has many, many, references on this topic. They're a great place to start when assumptions and pet theories take root. http://scholar.google.com/scholar?q=email+encryption ++++++++++++ 2nd msg:Chatting with Kristen [Fiskerstrand], he pointed me to Usability of Security: A Case Study. Alma Whitten and J. D. Tygar. Carnegie Mellon University Computer Science technical report CMU-CS-98-155, December 1998. Abstract: http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA361032 'The unmotivated user property' and 'The abstraction property' are particularly worth noting and keeping in mind. -John -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 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" -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 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: 520 bytes Desc: OpenPGP digital signature URL: From dan at geer.org Fri Apr 11 04:54:12 2014 From: dan at geer.org (dan at geer.org) Date: Thu, 10 Apr 2014 22:54:12 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: Your message of "Wed, 09 Apr 2014 23:36:25 BST." Message-ID: <20140411025412.35F682280F0@palinka.tinho.net> > One possible answer: https://www.mailpile.is/faq/ * Where does Mailpile store my mail? With Mailpile, your e-mail is downloaded from the Internet (via an email server POP3 / IMAP), and stored locally on the computer where Mailpile is running. * Then how do I access it when my computer is turned off? You don't! Exactly so. Putting aside, for the moment, outright attacks, the individual or the enterprise that outsources its e-mail to a third party thereby creates by itself and for itself the risk of silent subpoenas delivered to their outsourcer. If, instead, the individual or the enterprise insources its e-mail then at the very least it knows when its data assets are being sought because the subpoena comes to them. Maybe insourcing your e-mail is too much work, but need I remind anyone that plaintext e-mail cannot be web-bugged, so why would anyone ever render HTML e-mail at all? Apologies, --dan From nico at josuttis.de Thu Apr 10 18:03:17 2014 From: nico at josuttis.de (Nicolai Josuttis) Date: Thu, 10 Apr 2014 18:03:17 +0200 Subject: GPG and BCC Message-ID: <5346C0C5.8050704@josuttis.de> Recently I was reading http://crypto.stanford.edu/portia/papers/bb-bcc.pdf However, I don't know how old this article is and whether we still have a conceptional or concrete problem using encryption and bcc with GPG. I also found no answer on this in the FAQ you "startpaging" (using startpage.com) the terms. So: Can anybody answer/explain whether there is or might be a problem or risk if using encryption combined with bcc addresses with GPG? And if so, what should I do/avoid to run into this problem? I am especially interested in an answer which helps me to understand WHY there is or might be a/no problem. In fact: - Does GPG reveal the number of BCC rcipients? - Does GPG reveal BCC identities (partially)? If the answer depends on the browser or other components, please tell me. The reason I ask is because for a UI to be programmed on top of GPG I want to understand which warnings I should raise or what I should deny when users try to send encrypted emails also to bcc receivers. And if there is a place discussing and answering that please tell me. I didn't find one. Thanks a lot. -- Nico From p.h.delgado at xoxy.net Fri Apr 11 10:37:10 2014 From: p.h.delgado at xoxy.net (p.h.delgado at xoxy.net) Date: Fri, 11 Apr 2014 08:37:10 +0000 Subject: GPG and BCC In-Reply-To: <5346C0C5.8050704@josuttis.de> References: <5346C0C5.8050704@josuttis.de> Message-ID: <5347A9B6.8070908@mail.ru> On 04/10/2014 04:03 PM, Nicolai Josuttis wrote: > Recently I was reading > http://crypto.stanford.edu/portia/papers/bb-bcc.pdf This article is quite misleading. Encryption process knows nothing about the "bcc" functionality of the e-mail system (or, indeed, any system) used to transport the generated cipher-text. Cipher-text does, under normal MO, include the identification of the keys of all the recipients when the message is "encrypted for multiple recipients". While this can be circumvented, such practice introduces additional burden and fragility on the recipients and the transport system has no way of knowing it. In short, GPG encrypted messages should never be encrypted to multiple recipients if it is undesirable that they are able to learn the identity of all the recipients. From that, every recipient can learn public key and thus of the identity of all the co-recipients. This would be the case no matter what is the transportation system used to distribute the cipher-text. From the e-mail system point of view, it would be the same as sending a message to a list of bcc addresses but include the list of those addresses in the body of the message itself. delgado From nb.linux at xandea.de Fri Apr 11 12:03:20 2014 From: nb.linux at xandea.de (nb.linux) Date: Fri, 11 Apr 2014 10:03:20 +0000 Subject: GPG and BCC In-Reply-To: <5347A9B6.8070908@mail.ru> References: <5346C0C5.8050704@josuttis.de> <5347A9B6.8070908@mail.ru> Message-ID: <5347BDE8.6020605@xandea.de> p.h.delgado at xoxy.net: > On 04/10/2014 04:03 PM, Nicolai Josuttis wrote: >> Recently I was reading >> http://crypto.stanford.edu/portia/papers/bb-bcc.pdf If the addressees aren't bored with that, you could add the `--throw-keyids' option. For enigmail this would be the `extensions.enigmail.agentAdditionalParam' key. This would remove the key IDs from the message. On the other hand, the receivers will be asked for a passphrase until a matching key (one that can decrypt the message) is found, for every key they have. >From the man page: > --throw-keyids > > --no-throw-keyids > Do not put the recipient key IDs into encrypted messages. This > helps to hide the receivers of the message and is a limited > countermeasure against traffic analysis. ([Using a little social > engineering anyone who is able to decrypt the message can check > whether one of the other recipients is the one he suspects.]) > On the receiving side, it may slow down the decryption process > because all available secret keys must be tried. --no-throw- > keyids disables this option. This option is essentially the same > as using --hidden-recipient for all recipients. cheers, --nb.linux From cspitzer at godaddy.com Fri Apr 11 17:31:45 2014 From: cspitzer at godaddy.com (Charles Spitzer) Date: Fri, 11 Apr 2014 15:31:45 +0000 Subject: It's 2014. Are we there yet? In-Reply-To: <20140411025412.35F682280F0@palinka.tinho.net> References: Your message of "Wed, 09 Apr 2014 23:36:25 BST." <20140411025412.35F682280F0@palinka.tinho.net> Message-ID: <98f5135cf9ae4197aa4dade0c0f17465@BLUPR02MB066.namprd02.prod.outlook.com> Except when your ISP is silently subpoenaed and they satisfy it without notifying you. There's no telling what the ISP has stashed away without your knowledge. I have had my gmail email subpoenaed, but Google notified me when they received it that they would supply the requested data on a specific date unless I filed in a CA court reasons why they should not do so. Regards, Charlie -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of dan at geer.org Sent: Thursday, April 10, 2014 7:54 PM To: Sam Kuper Cc: gnupg-users mailing list Subject: Re: It's 2014. Are we there yet? > One possible answer: https://www.mailpile.is/faq/ * Where does Mailpile store my mail? With Mailpile, your e-mail is downloaded from the Internet (via an email server POP3 / IMAP), and stored locally on the computer where Mailpile is running. * Then how do I access it when my computer is turned off? You don't! Exactly so. Putting aside, for the moment, outright attacks, the individual or the enterprise that outsources its e-mail to a third party thereby creates by itself and for itself the risk of silent subpoenas delivered to their outsourcer. If, instead, the individual or the enterprise insources its e-mail then at the very least it knows when its data assets are being sought because the subpoena comes to them. Maybe insourcing your e-mail is too much work, but need I remind anyone that plaintext e-mail cannot be web-bugged, so why would anyone ever render HTML e-mail at all? Apologies, --dan _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From kappu at hotmail.com Fri Apr 11 17:56:32 2014 From: kappu at hotmail.com (Kapil Aggarwal) Date: Fri, 11 Apr 2014 11:56:32 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: <98f5135cf9ae4197aa4dade0c0f17465@BLUPR02MB066.namprd02.prod.outlook.com> References: Your message of "Wed, 09 Apr 2014 23:36:25 BST." <20140411025412.35F682280F0@palinka.tinho.net> <98f5135cf9ae4197aa4dade0c0f17465@BLUPR02MB066.namprd02.prod.outlook.com> Message-ID: What if you used multiple email addresses between two parties and at random picked one to communicate? Sure there will be a copy on the ISPs servers, but it'll be encrypted as such and the email addresses can be changed on a frequent/infrequent basis. -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Charles Spitzer Sent: Friday, April 11, 2014 11:32 AM To: dan at geer.org; Sam Kuper Cc: gnupg-users mailing list Subject: RE: It's 2014. Are we there yet? Except when your ISP is silently subpoenaed and they satisfy it without notifying you. There's no telling what the ISP has stashed away without your knowledge. I have had my gmail email subpoenaed, but Google notified me when they received it that they would supply the requested data on a specific date unless I filed in a CA court reasons why they should not do so. Regards, Charlie -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of dan at geer.org Sent: Thursday, April 10, 2014 7:54 PM To: Sam Kuper Cc: gnupg-users mailing list Subject: Re: It's 2014. Are we there yet? > One possible answer: https://www.mailpile.is/faq/ * Where does Mailpile store my mail? With Mailpile, your e-mail is downloaded from the Internet (via an email server POP3 / IMAP), and stored locally on the computer where Mailpile is running. * Then how do I access it when my computer is turned off? You don't! Exactly so. Putting aside, for the moment, outright attacks, the individual or the enterprise that outsources its e-mail to a third party thereby creates by itself and for itself the risk of silent subpoenas delivered to their outsourcer. If, instead, the individual or the enterprise insources its e-mail then at the very least it knows when its data assets are being sought because the subpoena comes to them. Maybe insourcing your e-mail is too much work, but need I remind anyone that plaintext e-mail cannot be web-bugged, so why would anyone ever render HTML e-mail at all? Apologies, --dan _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From ashtongj at comcast.net Fri Apr 11 18:33:32 2014 From: ashtongj at comcast.net (Gerard Ashton) Date: Fri, 11 Apr 2014 12:33:32 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: References: Your message of "Wed, 09 Apr 2014 23:36:25 BST." <20140411025412.35F682280F0@palinka.tinho.net> <98f5135cf9ae4197aa4dade0c0f17465@BLUPR02MB066.namprd02.prod.outlook.com> Message-ID: <000801cf55a3$c7922e30$56b68a90$@comcast.net> > Sent: Friday, April 11, 2014 11:57 AM > Subject: RE: It's 2014. Are we there yet? > > What if you used multiple email addresses between two parties and at random picked one to communicate? > > Sure there will be a copy on the ISPs servers, but it'll be encrypted as such and the email addresses can be changed on a frequent/infrequent basis. I don't think the technique is compatible with the subject of the thread: "It's 2014. Are we there yet?" This implies email encryption that's easy to install and easy to use routinely, with almost everyone. Multiple email addresses is a non-starter. Gerry Ashton From one.jsim at gmail.com Fri Apr 11 20:16:14 2014 From: one.jsim at gmail.com (One Jsim) Date: Fri, 11 Apr 2014 19:16:14 +0100 Subject: It's 2014. Are we there yet? Message-ID: > > PRELIMINARIES > > In the '90 (I am old!) I was a moderated evangelist of the universal use > of PGP (and later GPG) and public key infrastructure (web of trust) in > order to achieve acceptable universal privacy and trust in email > communication. > > At the time I have a good comprehension of the principles involved. > Although I am physics?s PhD, I have also been a computer buff since the > '70 and almost all my work involve and has always involved a lot of > mathematics, computers and all sort of information technologies. > > At that time most of the people, using email, did that through an email > client (that was usually also a news - remember usenet - client ) using > the POP (POP3) and latter IMAP and IMAP4. protocols. > > HOWEVER > > The idea NEVER took off, despite the internet users, at that time, were > quite well-informed about the technicalities of the technology they used. > > I still maintain a neat pair of public-private keys, with an insanely > complex password, and keeping the private key itself inside a password > manager utility (keePass) together with more mundane passwords. > > (Once in a while I use my public key to encode sensitive documents, that I > may or may not, send as email attachments). > > FAST FORWARD > > Nowadays most people use web-mail (gmail, yahoo, hotmail, outlook.com, > etc), not pop mail, and understand almost nothing of computer science (rare > web-mail providers let you use POP/IMAP, most times under conditions). > > And in a very next future they will be using iOS, android, ChromeOS (all, > in any of the available versions) just to mention the more popular ones > at the moment, that not even use (E)SMTP, I think. > > > Facing those facts I concluded that the idea of private email for the > masses is not feasible in the near future. > > Write a document->encrypt with public key->send as an email attachmente > (better as compressed RAR) is the only option I found useful yet. To sign > the document can also be useful. > > ANY COMMENT? > > Is useless to refer magic software in test that will solve everything, but > is not going to materialize ever. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kappu at hotmail.com Fri Apr 11 20:30:47 2014 From: kappu at hotmail.com (Kapil Aggarwal) Date: Fri, 11 Apr 2014 14:30:47 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: References: Message-ID: I?ll have to disagree. I think there?s a growing sense of ?uhhh maybe these email providers are not such a good idea after all?. And something else to note. Every iOS or Android or Windows 8/mobile device (except ChromeOS based) includes a mail ?app/program? which includes POP and IMAP functionality. And every single ?webmail? provider offers alternate means (like POP/IMAP) to access their webmail. I seriously doubt dedicated email clients are going away anytime soon. The protocols may change over time, but there will always be a need for a dedicated program for email. From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of One Jsim Sent: Friday, April 11, 2014 2:16 PM To: Gnupg-users Subject: Re: It's 2014. Are we there yet? PRELIMINARIES In the '90 (I am old!) I was a moderated evangelist of the universal use of PGP (and later GPG) and public key infrastructure (web of trust) in order to achieve acceptable universal privacy and trust in email communication. At the time I have a good comprehension of the principles involved. Although I am physics?s PhD, I have also been a computer buff since the '70 and almost all my work involve and has always involved a lot of mathematics, computers and all sort of information technologies. At that time most of the people, using email, did that through an email client (that was usually also a news - remember usenet - client ) using the POP (POP3) and latter IMAP and IMAP4. protocols. HOWEVER The idea NEVER took off, despite the internet users, at that time, were quite well-informed about the technicalities of the technology they used. I still maintain a neat pair of public-private keys, with an insanely complex password, and keeping the private key itself inside a password manager utility (keePass) together with more mundane passwords. (Once in a while I use my public key to encode sensitive documents, that I may or may not, send as email attachments). FAST FORWARD Nowadays most people use web-mail (gmail, yahoo, hotmail, outlook.com, etc), not pop mail, and understand almost nothing of computer science (rare web-mail providers let you use POP/IMAP, most times under conditions). And in a very next future they will be using iOS, android, ChromeOS (all, in any of the available versions) just to mention the more popular ones at the moment, that not even use (E)SMTP, I think. Facing those facts I concluded that the idea of private email for the masses is not feasible in the near future. Write a document->encrypt with public key->send as an email attachmente (better as compressed RAR) is the only option I found useful yet. To sign the document can also be useful. ANY COMMENT? Is useless to refer magic software in test that will solve everything, but is not going to materialize ever. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Fri Apr 11 20:47:03 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 11 Apr 2014 14:47:03 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: References: Message-ID: <534838A7.9050205@sixdemonbag.org> > I?ll have to disagree. I think there?s a growing sense of ?uhhh?maybe > these email providers are not such a good idea after all?. In 2007-8 (the last time I taught undergrad Computer Literacy), over a third of my students only used email for university business (like submitting papers to me) and talking to their older relatives. Among their own age bracket, most communication was done through Facebook. (Today it's more Instagram and Snapchat and the percentage is approaching 50%, according to my friends who are still teaching.) But yes, email really is on the way out as a communications medium. The younger generation sees it as an antiquated technology. I suspect in another 20 years it'll be used about as much as Gopher is today. From kappu at hotmail.com Fri Apr 11 21:08:24 2014 From: kappu at hotmail.com (Kapil Aggarwal) Date: Fri, 11 Apr 2014 15:08:24 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: <534838A7.9050205@sixdemonbag.org> References: <534838A7.9050205@sixdemonbag.org> Message-ID: Sure. But I think that age group is not the intended target audience for secure communications. The target audience that does want to (potentially) use secure communications has a very large technological barrier to entry. Hence they don't use it. -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Robert J. Hansen Sent: Friday, April 11, 2014 2:47 PM To: gnupg-users at gnupg.org Subject: Re: It's 2014. Are we there yet? > I'll have to disagree. I think there's a growing sense of "uhhh.maybe > these email providers are not such a good idea after all". In 2007-8 (the last time I taught undergrad Computer Literacy), over a third of my students only used email for university business (like submitting papers to me) and talking to their older relatives. Among their own age bracket, most communication was done through Facebook. (Today it's more Instagram and Snapchat and the percentage is approaching 50%, according to my friends who are still teaching.) But yes, email really is on the way out as a communications medium. The younger generation sees it as an antiquated technology. I suspect in another 20 years it'll be used about as much as Gopher is today. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From cspitzer at godaddy.com Fri Apr 11 21:14:41 2014 From: cspitzer at godaddy.com (Charles Spitzer) Date: Fri, 11 Apr 2014 19:14:41 +0000 Subject: It's 2014. Are we there yet? In-Reply-To: <534838A7.9050205@sixdemonbag.org> References: <534838A7.9050205@sixdemonbag.org> Message-ID: It's happening even faster. My kids, in their mid to late 30s, don't use email at all. It's all quick, instant gratification type communications, like texts or their internet-type ilk. Almost none of their friends uses email anymore. Regards, Charlie 480.505.8800 x4123 -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Robert J. Hansen Sent: Friday, April 11, 2014 11:47 AM To: gnupg-users at gnupg.org Subject: Re: It's 2014. Are we there yet? > I'll have to disagree. I think there's a growing sense of "uhhh...maybe > these email providers are not such a good idea after all". In 2007-8 (the last time I taught undergrad Computer Literacy), over a third of my students only used email for university business (like submitting papers to me) and talking to their older relatives. Among their own age bracket, most communication was done through Facebook. (Today it's more Instagram and Snapchat and the percentage is approaching 50%, according to my friends who are still teaching.) But yes, email really is on the way out as a communications medium. The younger generation sees it as an antiquated technology. I suspect in another 20 years it'll be used about as much as Gopher is today. From gnupg at lists.grepular.com Fri Apr 11 21:18:29 2014 From: gnupg at lists.grepular.com (Mike Cardwell) Date: Fri, 11 Apr 2014 20:18:29 +0100 Subject: It's 2014. Are we there yet? In-Reply-To: <534838A7.9050205@sixdemonbag.org> References: <534838A7.9050205@sixdemonbag.org> Message-ID: <20140411191829.GA29577@glue.grepular.com> * on the Fri, Apr 11, 2014 at 02:47:03PM -0400, Robert J. Hansen wrote: >> I?ll have to disagree. I think there?s a growing sense of ?uhhh?maybe >> these email providers are not such a good idea after all?. > > In 2007-8 (the last time I taught undergrad Computer Literacy), over a > third of my students only used email for university business (like > submitting papers to me) and talking to their older relatives. Among > their own age bracket, most communication was done through Facebook. > (Today it's more Instagram and Snapchat and the percentage is > approaching 50%, according to my friends who are still teaching.) And when those students finish University and get jobs, do they use Facebook, Instagram and Snapchat at work, or do they use Email at work? The fact that alternative communication methods exist that are more suitable for certain types of conversations between certain people, isn't that interesting. Email does not need to be used for even the majority of online communication in order for it to be successfull. > But yes, email really is on the way out as a communications medium. The > younger generation sees it as an antiquated technology. I suspect in > another 20 years it'll be used about as much as Gopher is today. I don't find, "kids don't use email for casual conversations" to be a very convincing argument that email is on its way out. In 20 years, Facebook will be a footnote on wikipedia, but people will still be using Email, in some form or other. There will always be a system for pushing messages around electronically that isn't tied to a single provider. If email is replaced, it will be by something similar to email. Not by whichever social network the kids are currently using. -- Mike Cardwell https://grepular.com https://emailprivacytester.com OpenPGP Key 35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 598 bytes Desc: Digital signature URL: From rjh at sixdemonbag.org Fri Apr 11 21:35:20 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 11 Apr 2014 15:35:20 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: <20140411191829.GA29577@glue.grepular.com> References: <534838A7.9050205@sixdemonbag.org> <20140411191829.GA29577@glue.grepular.com> Message-ID: <534843F8.8040602@sixdemonbag.org> > And when those students finish University and get jobs, do they use > Facebook, Instagram and Snapchat at work, or do they use Email at work? Right now, Microsoft Sharepoint is in use at 80% of Fortune 500 firms. Normally it's used to set up internal social networking for the company. Some firms are adopting it halfheartedly, and other firms are seeing it significantly cut into email usage. The trend is upwards. Whether I think this is wise makes no difference to whether I see this happening. I think it's unwise, and I see it happening in droves. > I don't find, "kids don't use email for casual conversations" to be a very > convincing argument that email is on its way out. I find it to be an overwhelming one. The future has spoken, and it thinks email is for old folks and fuddy-duddies. No technology can be said to be ascendant, or even keeping its market share, if future generations are not signing on to use it. Will email still be around in twenty years? Sure. But we still have Gopher servers today, too. From dan at geer.org Fri Apr 11 22:07:32 2014 From: dan at geer.org (dan at geer.org) Date: Fri, 11 Apr 2014 16:07:32 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: Your message of "Fri, 11 Apr 2014 15:35:20 EDT." <534843F8.8040602@sixdemonbag.org> Message-ID: <20140411200732.CD3F8228116@palinka.tinho.net> I employ quite a few young people on my farm. Text messages are almost entirely what they do. Two (that I know of) are *never* without their phones but at the time *never* use them for voice comms. The only way to reach them is text. One of those claims that he has never answered a call on a mobile phone. Small sample,... --dan From rjh at sixdemonbag.org Fri Apr 11 22:08:36 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 11 Apr 2014 16:08:36 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: References: <534838A7.9050205@sixdemonbag.org> Message-ID: <53484BC4.70901@sixdemonbag.org> > Sure. But I think that age group is not the intended target audience > for secure communications. You might want to think long and hard about that. College campuses are filled with politically active young people who have just received the right to vote and are consumed with passionate intensity about their rights -- including their right to privacy. They're young, politically active, mostly left-wing, and more technologically adept than their parents. They also shape future trends and future political debates. If they're not your target audience, then you're doing it wrong. From kloecker at kde.org Fri Apr 11 22:59:21 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 11 Apr 2014 22:59:21 +0200 Subject: GPG and BCC In-Reply-To: <5346C0C5.8050704@josuttis.de> References: <5346C0C5.8050704@josuttis.de> Message-ID: <1430606.o2gaqJObOZ@thufir.ingo-kloecker.de> On Thursday 10 April 2014 18:03:17 Nicolai Josuttis wrote: > Can anybody answer/explain whether there is or might be a problem or > risk if using encryption combined with bcc addresses with GPG? > And if so, what should I do/avoid to run into this problem? > I am especially interested in an answer which helps me to understand > WHY there is or might be a/no problem. > In fact: > - Does GPG reveal the number of BCC rcipients? > - Does GPG reveal BCC identities (partially)? Those questions have already been answered by the others. > If the answer depends on the browser or other components, please tell > me. > > The reason I ask is because for a UI to be programmed on top of GPG > I want to understand which warnings I should raise or > what I should deny > when users try to send encrypted emails also to bcc receivers. Apart from using the '--throw-keyids' option you could send multiple copies of the message. One copy for the public recipients which is encrypted with the keys of all public recipients (To, Cc). And n copies for the n Bcc recipients where each copy is encrypted with the key of one Bcc recipient. That's what KMail does. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From nico at josuttis.de Sat Apr 12 11:00:16 2014 From: nico at josuttis.de (Nicolai Josuttis) Date: Sat, 12 Apr 2014 11:00:16 +0200 Subject: PGP and GPG and bcc Message-ID: <534900A0.20002@josuttis.de> Thanks a lot for all answers regarding my question regarding GPG and bcc. Allow me to summarize what I learned for both: - double checking that I understood everything correctly - documenting this for others (I found no place where it is explained; therefore also the change in the subject) In general, if sending emails encrypted (or in general sending cipher-text) then the usual approach is that this text contains the identity of those who should receive the message. This is to help to find the place where the key for that identity is stored (note that there might be multiple receivers). That means: - In general, adding the "usual key" for a bcc receiver would reveal the identity of this receiver. Thus, a bcc receiver becomes more or less a cc receiver. Or: === In general, the concept of BCC is BROKEN when sending encrypted emails with keys for the bcc recipients. To deal with that, mailers have multiple options when users try to send encrypted emails to bcc recipients: - Don't allow that (or only with strong request for confirmation). - Don't add keys for bcc recipients at all. This probably only makes sense if bcc recipients can use one of the other of the keys in the message. - Don't add the identities for the keys of bcc recipients - with GPG you can e.g. use --hidden-recipient instead of --recipient (see also --throw-keyids) Then, however, recipients might have to try to use their key against any of the passed key without identity (slows down decryption with multiple bcc recipients). - Split the email, sending it to each bcc recipient separately. Note that mailers should take into account not only for sending bcc to others but also for the common case where senders (always) bcc to themselves (using a different but may be secret email address). -- Nico From gnupg at lists.grepular.com Sat Apr 12 13:15:43 2014 From: gnupg at lists.grepular.com (Mike Cardwell) Date: Sat, 12 Apr 2014 12:15:43 +0100 Subject: It's 2014. Are we there yet? In-Reply-To: <534843F8.8040602@sixdemonbag.org> References: <534838A7.9050205@sixdemonbag.org> <20140411191829.GA29577@glue.grepular.com> <534843F8.8040602@sixdemonbag.org> Message-ID: <20140412111543.GA24332@glue.grepular.com> * on the Fri, Apr 11, 2014 at 03:35:20PM -0400, Robert J. Hansen wrote: >> And when those students finish University and get jobs, do they use >> Facebook, Instagram and Snapchat at work, or do they use Email at work? > > Right now, Microsoft Sharepoint is in use at 80% of Fortune 500 firms. > Normally it's used to set up internal social networking for the company. > Some firms are adopting it halfheartedly, and other firms are seeing it > significantly cut into email usage. The trend is upwards. I'm pretty confident that for every firm using sharepoint as their primary means of communication, there are hundreds if not thousands using email instead. And each of those Fortune 500 firms are almost certainly also using email too. Email isn't just a communication mechanism, it's also the basis of your online identity. > Whether I think this is wise makes no difference to whether I see this > happening. I think it's unwise, and I see it happening in droves. That's not what I'm seeing at all. I see people using instant chat protocols for instant chat, and I see people using Email when it is appropriate for them to use Email. >> I don't find, "kids don't use email for casual conversations" to be a very >> convincing argument that email is on its way out. > > I find it to be an overwhelming one. The future has spoken, and it > thinks email is for old folks and fuddy-duddies. No technology can be > said to be ascendant, or even keeping its market share, if future > generations are not signing on to use it. The future has spoken. Kids know about email. They know what it's for. They use it when it's appropriate to use it. They use it more the older they get. the World is only becoming more and more reliant on it as time goes on. I am 100% confident that the future very firmly has Email, or something very similar in it. > Will email still be around in twenty years? Sure. But we still have > Gopher servers today, too. Gopher was replaced by a similar but better protocol (HTTP). I would be happy to see Email replaced by a similar but better protocol. It will probably still be called Email though. I think it's more likely that various Email protocols will be extended and refined rather than an outright replacement though. -- Mike Cardwell https://grepular.com https://emailprivacytester.com OpenPGP Key 35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 598 bytes Desc: Digital signature URL: From wk at gnupg.org Sun Apr 13 11:03:11 2014 From: wk at gnupg.org (Werner Koch) Date: Sun, 13 Apr 2014 11:03:11 +0200 Subject: GPG and BCC In-Reply-To: <1430606.o2gaqJObOZ@thufir.ingo-kloecker.de> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22's?= message of "Fri, 11 Apr 2014 22:59:21 +0200") References: <5346C0C5.8050704@josuttis.de> <1430606.o2gaqJObOZ@thufir.ingo-kloecker.de> Message-ID: <87zjjp8uuo.fsf@vigenere.g10code.de> On Fri, 11 Apr 2014 22:59, kloecker at kde.org said: > encrypted with the keys of all public recipients (To, Cc). And n copies > for the n Bcc recipients where each copy is encrypted with the key of > one Bcc recipient. That's what KMail does. And that is the Right Thing to do. --throw-keyids or -R only remove the keyid but still encrypts to the BCC recipient. The extra encryption packet would be a good indication for the use of BCC with a broken mailer. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rdohm321 at gmail.com Sun Apr 13 22:38:48 2014 From: rdohm321 at gmail.com (Randolph) Date: Sun, 13 Apr 2014 22:38:48 +0200 Subject: ElGamal without padding - why? Message-ID: Hi, why has ElGamal no padding in gcryt ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Apr 14 09:51:13 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Apr 2014 09:51:13 +0200 Subject: ElGamal without padding - why? In-Reply-To: (Randolph's message of "Sun, 13 Apr 2014 22:38:48 +0200") References: Message-ID: <87zjjo73im.fsf@vigenere.g10code.de> On Sun, 13 Apr 2014 22:38, rdohm321 at gmail.com said: > Hi, why has ElGamal no padding in gcryt ? Please me more verbose. See RFC-4880 on how Elgamal is used in OpenPGP. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cwal989 at comcast.net Mon Apr 14 17:56:49 2014 From: cwal989 at comcast.net (Christopher J. Walters) Date: Mon, 14 Apr 2014 11:56:49 -0400 Subject: Am I being blocked from posting on this list? Message-ID: <534C0541.4020703@comcast.net> I tried to post a message on that certain bug to this list yesterday, and it has never shown up. I had two sources that suggested that said bug is far more severe than most people think. So this message is a test. From cwal989 at comcast.net Mon Apr 14 18:00:19 2014 From: cwal989 at comcast.net (Christopher J. Walters) Date: Mon, 14 Apr 2014 12:00:19 -0400 Subject: Am I being blocked from posting on this list? In-Reply-To: <534C0541.4020703@comcast.net> References: <534C0541.4020703@comcast.net> Message-ID: <534C0613.6020703@comcast.net> On 4/14/2014 11:56 AM, Christopher J. Walters wrote: > I tried to post a message on that certain bug to this list yesterday, and it > has never shown up. I had two sources that suggested that said bug is far more > severe than most people think. So this message is a test. So, is there a keyword block on the name of that bug? This message posted, but the other one (I tried posting it twice - once yesterday, and once today), never showed up. From cwal989 at comcast.net Mon Apr 14 20:24:20 2014 From: cwal989 at comcast.net (Christopher J. Walters) Date: Mon, 14 Apr 2014 14:24:20 -0400 Subject: The bug... More info. Message-ID: <534C27D4.6030300@comcast.net> The discussion on the Heatbleed bug has apparently stopped here, and just about everywhere else, but I found (courtesy of another mailing list), some more reports on it, that you may have not seen. These reports suggest the the NSA knew about and exploited the bug for "at least" two years, and may have even worked to stop it from being reported and fixed. http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html Shorter link to the above article: http://tinyurl.com/mq8owa2 Also, http://www.sfgate.com/opinion/editorials/article/Encryption-security-compromised-in-a-heartbeat-5396510.php Shorter link to the above article: http://tinyurl.com/kmmqkfv The NSA, or course, denies any knowledge, or exploitation of the bug, but you can read the article and make your own decisions on that. Chris From dougb at dougbarton.us Mon Apr 14 20:35:02 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 14 Apr 2014 11:35:02 -0700 Subject: The bug... More info. In-Reply-To: <534C27D4.6030300@comcast.net> References: <534C27D4.6030300@comcast.net> Message-ID: <534C2A56.8040804@dougbarton.us> Aside from the obvious fact that this is off-topic for this list, as has been pointed out several times already, wouldn't the existence of a subject line block give you a pretty good hint about the list owner's intentions? Doug From cwal989 at comcast.net Mon Apr 14 20:42:21 2014 From: cwal989 at comcast.net (Christopher J. Walters) Date: Mon, 14 Apr 2014 14:42:21 -0400 Subject: The bug... More info. In-Reply-To: <534C2A56.8040804@dougbarton.us> References: <534C27D4.6030300@comcast.net> <534C2A56.8040804@dougbarton.us> Message-ID: <534C2C0D.3040607@comcast.net> On 4/14/2014 2:35 PM, Doug Barton wrote: > Aside from the obvious fact that this is off-topic for this list, as has been > pointed out several times already, wouldn't the existence of a subject line > block give you a pretty good hint about the list owner's intentions? > > Doug Are you the list owner? Did you put a "subject line block" on this list? If so, you should have said so, if not, then the list owner should have said so. I do NOT believe that this is off topic for this list, if the list owner believes that it is, and put such a block in place, that was the list owner's responsibility to tell everyone on list not to post about it anymore on THIS list. And finally, no. My messages not showing up on this list did not give me any clue as to the list owners' intentions, as it could've been a problem with the email getting to the list. From rjh at sixdemonbag.org Mon Apr 14 20:43:45 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 Apr 2014 11:43:45 -0700 Subject: Am I being blocked from posting on this list? In-Reply-To: <534C0541.4020703@comcast.net> References: <534C0541.4020703@comcast.net> Message-ID: <20140414114345.Horde.hc1qOjJmwGEZlNyYU7WCRw1@mail.sixdemonbag.org> > I tried to post a message on that certain bug to this list > yesterday, and it has never shown up. I had two sources that > suggested that said bug is far more severe than most people think. > So this message is a test. Heartbleed! Heartbleed! Heartbleed! Nope, no Great Old Ones have risen from the depths and begun to expose humanity to unimaginable horrors. Maybe if I try again with the word "Hastur"... [*] Heartbleed was bad, yes. However, it's hard for me to believe it's "far more severe than most people think." Being able to read 64k chunks out of server memory at-will and on-demand by exploiting commonly-used software is already a Chernobyl-level disaster. Really, how's it going to get worse? If it starts replacing my Glenmorangie Quinta Ruban with Black Velvet, okay, then it'll be time to scream, wail and grieve. But until then, let's keep our heads, let's face the future with a smile, let's not panic, and let's not think the GnuPG list is censoring anything that contains the word 'Heartbleed'. Now, if you'll forgive me, there's a Great Old One I've been trying to awaken. Hastur! Hastur! Hast--*urgkl* *thud* [*] if this makes no sense to you, go read some H.P. Lovecraft's _The Whisperer in Darkness_. :) From cwal989 at comcast.net Mon Apr 14 20:56:52 2014 From: cwal989 at comcast.net (Christopher J. Walters) Date: Mon, 14 Apr 2014 14:56:52 -0400 Subject: Am I being blocked from posting on this list? In-Reply-To: <20140414114345.Horde.hc1qOjJmwGEZlNyYU7WCRw1@mail.sixdemonbag.org> References: <534C0541.4020703@comcast.net> <20140414114345.Horde.hc1qOjJmwGEZlNyYU7WCRw1@mail.sixdemonbag.org> Message-ID: <534C2F74.3030507@comcast.net> On 4/14/2014 2:43 PM, Robert J. Hansen wrote: .snip. > Heartbleed! Heartbleed! Heartbleed! > > Nope, no Great Old Ones have risen from the depths and begun to expose humanity > to unimaginable horrors. Maybe if I try again with the word "Hastur"... [*] > > Heartbleed was bad, yes. However, it's hard for me to believe it's "far more > severe than most people think." Being able to read 64k chunks out of server > memory at-will and on-demand by exploiting commonly-used software is already a > Chernobyl-level disaster. Really, how's it going to get worse? .snip. > heads, let's face the future with a smile, let's not panic, and let's not think > the GnuPG list is censoring anything that contains the word 'Heartbleed'. It is not just this list. That message has not shown up on other lists I have posted it to. > Now, if you'll forgive me, there's a Great Old One I've been trying to awaken. > > Hastur! Hastur! Hast--*urgkl* *thud* > .snip. > > [*] if this makes no sense to you, go read some H.P. Lovecraft's _The Whisperer > in Darkness_. :) Well, you can read the links and decide for yourself if they have any value. As the Great One, Doug Barton stated (paraphrasing), this topic is totally off-topic for this list, and I have violated the owners' wishes by posting on it, and, of course I should have known this, and not even tried to post on this topic on this list. From wk at gnupg.org Mon Apr 14 21:15:09 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Apr 2014 21:15:09 +0200 Subject: The bug... More info. In-Reply-To: <534C2C0D.3040607@comcast.net> (Christopher J. Walters's message of "Mon, 14 Apr 2014 14:42:21 -0400") References: <534C27D4.6030300@comcast.net> <534C2A56.8040804@dougbarton.us> <534C2C0D.3040607@comcast.net> Message-ID: <87vbub67uq.fsf@vigenere.g10code.de> On Mon, 14 Apr 2014 20:42, cwal989 at comcast.net said: > Are you the list owner? Did you put a "subject line block" on this > list? If so, you should have said so, if not, then the list owner There are only a few anti-spam measures on all gnupg.org lists and they have been there for years. Specific procmail fitering is: :0 * ^Subject:.*=\?ks_c_5601-1987\? /dev/null :0 * ^Subject:.*=\?GB2312\? /dev/null :0: * ^Subject: Delivery Status Notification /dev/null :0: * ^From:.*lottery.* spam :0 * ^Content-Type:.*multipart/mixed { :0 B * ^Content-Type:.*text/plain;.*Windows-1252 * ^Content-Type:.*application/octet-stream /dev/null } # We don't accept ZIP or EXE file attachments. :0 BH * ? scrutmime --match-zip --match-exe --quiet /dev/null :0: * ^Subject:[ ]=\?Windows-1251\?B\? /dev/null :0fw: spamassassin.lock | /usr/bin/spamassassin :0: * ^X-Spam-Flag: yes /dev/null and there is also greylisting and an RBL at the receiving MX. And my private filtering drops everything which has HTML inside; do I do not see all posted mails. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Mon Apr 14 21:27:13 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 Apr 2014 12:27:13 -0700 Subject: The bug... More info. In-Reply-To: <534C27D4.6030300@comcast.net> References: <534C27D4.6030300@comcast.net> Message-ID: <20140414122713.Horde.6CjkoTfBrocTDJW3ttzALw1@mail.sixdemonbag.org> > list), some more reports on it, that you may have not seen. These > reports suggest the the NSA knew about and exploited the bug for "at > least" two years, and may have even worked to stop it from being > reported and fixed. Given the bug was introduced in March of 2012, that would mean the bug would have had to been discovered, an exploit tested, a product weaponized, a product distributed to end-users, and deployed by end-users against targets, all in under a month from the moment the bug was introduced. I'm not saying it can't happen, but a healthy distrust would seem appropriate here. Further, the use of "at least" two years is meant to imply it could have been substantially longer -- but it could not have been more than two years and a month. Between that and the journo's mishandling of anonymous sources, I am not confident the Bloomberg journo did his homework. With respect to anonymous sources, the standard is generally -- 1. You give their background, broadly speaking 2. You say something about where they got the information 3. You specify they asked for anonymity -- it wasn't your idea 4. You explain why you're granting anonymity If you can't meet those four requirements, you don't use the source. If you can't give the public information about their background and the source of their information, then you can't give the public enough information to decide whether your source is credible. And if you can't give the public enough information to decide whether your source is credible, why should the public believe you? (ObDisclosure: I used to work as a tech journo. My four-point outline there was the standard we used, and my editor was fastidious about enforcement -- whether it was as small as "one space after a colon and the word is capitalized" or "four-point process for anonymous sources," Terry was on top of things. I never used an anonymous source.) From rjh at sixdemonbag.org Mon Apr 14 21:42:58 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 Apr 2014 12:42:58 -0700 Subject: Am I being blocked from posting on this list? In-Reply-To: <534C2F74.3030507@comcast.net> References: <534C0541.4020703@comcast.net> <20140414114345.Horde.hc1qOjJmwGEZlNyYU7WCRw1@mail.sixdemonbag.org> <534C2F74.3030507@comcast.net> Message-ID: <20140414124258.Horde.pEKghLtNDVznUzUsFce7kQ2@mail.sixdemonbag.org> > As the Great One, Doug Barton stated (paraphrasing), this topic is > totally off-topic for this list, and I have violated the owners' > wishes by posting on it, and, of course I should have known this, > and not even tried to post on this topic on this list. There have been several posts on this list saying, "you know, you will probably get better discussion and better answers on an OpenSSL mailing list." I understand you believe the Heartbleed bug needs more visibility. I respectfully suggest that pretty much everyone on this list knows about Heartbleed, and talking about it here will not increase the visibility of this issue one bit. > It is not just this list. That message has not shown up on other > lists I have posted it to. I mean this with sincerity, caution, and respect. Go watch the cherry blossoms. In the current climate it's easy to think there's shadowy, nefarious things going on in the darkness. There's terrorism all over the Middle East, there's a 777 that's gone completely missing in the South Pacific, civilians getting nerve-gassed in Syria, Russians in the Crimea and possibly agitating Eastern Ukraine, the Snowden revelations, the Manning revelations, the controversy over domestic and international surveillance, will the Iranians get the bomb, is Pakistan an ally or an enemy, the Baltic States worried about an invasion from the east, North Korean missile and nuclear tests... the list goes on and on and on. It's easy to think that life has turned into a remake of _Three Days of the Condor_. It is. I've been there and I've had those thoughts. But it's not about you, man. Any more than it's about me. And your messages are not getting censored because they reference the Heartbleed bug. If you're in the Northern Hemisphere, then you're in the middle of spring. Around here in northern Virginia it's absolutely beautiful. The cherry blossoms have come to Washington. Life is beautiful. Go out and enjoy it for a while, and enjoy the fact that as bad as the international news is nowadays ... it's not about you. And that's good advice for the rest of us, too. If you ever get overwhelmed by all the bad news, go watch the cherry blossoms for a while. It's cheaper than therapy, and in my personal experience it's far more effective. :) From cwal989 at comcast.net Mon Apr 14 21:42:54 2014 From: cwal989 at comcast.net (Christopher J. Walters) Date: Mon, 14 Apr 2014 15:42:54 -0400 Subject: The bug... More info. In-Reply-To: <20140414122713.Horde.6CjkoTfBrocTDJW3ttzALw1@mail.sixdemonbag.org> References: <534C27D4.6030300@comcast.net> <20140414122713.Horde.6CjkoTfBrocTDJW3ttzALw1@mail.sixdemonbag.org> Message-ID: <534C3A3E.1010603@comcast.net> On 4/14/2014 3:27 PM, Robert J. Hansen wrote: > Given the bug was introduced in March of 2012, that would mean the bug would > have had to been discovered, an exploit tested, a product weaponized, a product > distributed to end-users, and deployed by end-users against targets, all in > under a month from the moment the bug was introduced. I'm not saying it can't > happen, but a healthy distrust would seem appropriate here. Further, the use > of "at least" two years is meant to imply it could have been substantially > longer -- but it could not have been more than two years and a month. Between > that and the journo's mishandling of anonymous sources, I am not confident the > Bloomberg journo did his homework. > > With respect to anonymous sources, the standard is generally -- > > 1. You give their background, broadly speaking > 2. You say something about where they got the information > 3. You specify they asked for anonymity -- it wasn't your idea > 4. You explain why you're granting anonymity > > If you can't meet those four requirements, you don't use the source. If you > can't give the public information about their background and the source of > their information, then you can't give the public enough information to decide > whether your source is credible. And if you can't give the public enough > information to decide whether your source is credible, why should the public > believe you? > > (ObDisclosure: I used to work as a tech journo. My four-point outline there > was the standard we used, and my editor was fastidious about enforcement -- > whether it was as small as "one space after a colon and the word is > capitalized" or "four-point process for anonymous sources," Terry was on top of > things. I never used an anonymous source.) I tend to agree, actually. As to Snowden, how exactly could a private contractor have that level of security clearance, anyway? I said that the report "suggests" NSA involvement - not that I agree. The anonymous sources are a major problem for believability. The NSA has gotten a lot of bad press lately, and it looks to me like Bloomberg (not the best source of information, in general, IMHO) has jumped on the bandwagon. Since I have NO security clearance with the NSA, I cannot comment on any involvement, and I doubt anyone on this list, or the 'sources' have such clearance to comment on it, either. So, I retain my disbelief. Note: I only wanted to post those articles for people to be able to read and make up their own minds. I will post no more here on this bug. From dougb at dougbarton.us Mon Apr 14 21:57:45 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 14 Apr 2014 12:57:45 -0700 Subject: The bug... More info. In-Reply-To: <534C2C0D.3040607@comcast.net> References: <534C27D4.6030300@comcast.net> <534C2A56.8040804@dougbarton.us> <534C2C0D.3040607@comcast.net> Message-ID: <534C3DB9.6020106@dougbarton.us> On 04/14/2014 11:42 AM, Christopher J. Walters wrote: > I do NOT believe that this is off topic for this list Then can we get a ruling from the list owners/moderators please? From peter at digitalbrains.com Mon Apr 14 22:36:53 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 14 Apr 2014 22:36:53 +0200 Subject: The bug... More info. In-Reply-To: <20140414122713.Horde.6CjkoTfBrocTDJW3ttzALw1@mail.sixdemonbag.org> References: <534C27D4.6030300@comcast.net> <20140414122713.Horde.6CjkoTfBrocTDJW3ttzALw1@mail.sixdemonbag.org> Message-ID: <534C46E5.7070309@digitalbrains.com> On 14/04/14 21:27, Robert J. Hansen wrote: > Given the bug was introduced in March of 2012, that would mean the bug would > have had to been discovered, an exploit tested, a product weaponized In /this specific instance/, I believe these three can indeed be the product of, well, mere hours. I don't think it's unreasonable to suppose it might very well be :) the NSA is reading through all patches that go into the OpenSSL stable tree; it's not that much work for a big organisation and you might catch some low-hanging fruit. This specific patch was extremely low-hanging! We take an unchecked 16-bit length from a packet we receive from the internet, and use that to copy a block of newly-allocated data to the return packet! Holy crap. The OpenSSL developer that accepted this patch (that was submitted by an outsider) was not having a good day, and I think he would never write this code. For a programmer that has been working on a security project for quite a while, I believe it becomes just a reflex while writing such code: you take a length argument from user-supplied data, you do sanity checks on it. Similarly, I think people at the NSA, trained at reading code for possible exploits, might have actually squirted coffee when they read through this patch. And it's really easily exploited, so yes, I think you can weaponize in a mere afternoon. > a product distributed to end-users, and deployed by end-users against > targets I'm not going to assess these few points though, they are less obvious. However, I think you don't need much distribution. You can just send the heartbeats yourself, and read other people's data from the process's memory. Sifting through that memory for interesting stuff is more complicated, but doesn't need to be done on the spot. > Further, the use of "at least" two years is meant to imply it could have > been substantially longer -- but it could not have been more than two years > and a month. That indeed is pure sensationalism. The news report might have been completely made up. However, I think it might still be true, given how big a target OpenSSL is, and how easy to spot the bug was. Too bad none of the good guys actually spotted it. Such is life, unfortunately. People make mistakes. Sometimes pretty big, dumb mistakes. Even the smartest people. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From rjh at sixdemonbag.org Mon Apr 14 22:47:46 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 Apr 2014 13:47:46 -0700 Subject: The bug... More info. In-Reply-To: <534C3A3E.1010603@comcast.net> References: <534C27D4.6030300@comcast.net> <20140414122713.Horde.6CjkoTfBrocTDJW3ttzALw1@mail.sixdemonbag.org> <534C3A3E.1010603@comcast.net> Message-ID: <20140414134746.Horde._l0pc9d43-CUjVXGHrZtjg1@mail.sixdemonbag.org> > how exactly could a private contractor have that level > of security clearance, anyway? The government had a seat that needed filling, they couldn't get the seat filled at the paycheck they're legally allowed to offer to a direct employee, so they hired a private contractor to fill the role. Pretty simple, really. The government pay rate for someone with a Master's degree and ten years of experience hovers around $60,000 per year, incidentally. It's shockingly low by the standards of the tech sector. From cwal989 at comcast.net Mon Apr 14 22:49:51 2014 From: cwal989 at comcast.net (Christopher J. Walters) Date: Mon, 14 Apr 2014 16:49:51 -0400 Subject: The bug... More info. / OFF TOPIC In-Reply-To: <534C3DB9.6020106@dougbarton.us> References: <534C27D4.6030300@comcast.net> <534C2A56.8040804@dougbarton.us> <534C2C0D.3040607@comcast.net> <534C3DB9.6020106@dougbarton.us> Message-ID: <534C49EF.8010809@comcast.net> On 4/14/2014 3:57 PM, Doug Barton wrote: > On 04/14/2014 11:42 AM, Christopher J. Walters wrote: >> I do NOT believe that this is off topic for this list > > Then can we get a ruling from the list owners/moderators please? We already have one from Werner Koch. However, that doesn't matter, it IS off-topic and, as I said, I will not be posting about it again. From byrnejb at harte-lyne.ca Mon Apr 14 23:03:58 2014 From: byrnejb at harte-lyne.ca (James B. Byrne) Date: Mon, 14 Apr 2014 17:03:58 -0400 Subject: The bug... More info. In-Reply-To: <20140414134746.Horde._l0pc9d43-CUjVXGHrZtjg1@mail.sixdemonbag.org> References: <534C27D4.6030300@comcast.net> <20140414122713.Horde.6CjkoTfBrocTDJW3ttzALw1@mail.sixdemonbag.org> <534C3A3E.1010603@comcast.net> <20140414134746.Horde._l0pc9d43-CUjVXGHrZtjg1@mail.sixdemonbag.org> Message-ID: On Mon, April 14, 2014 16:47, Robert J. Hansen wrote: >> how exactly could a private contractor have that level >> of security clearance, anyway? > > The government had a seat that needed filling, they couldn't get the > seat filled at the paycheck they're legally allowed to offer to a > direct employee, so they hired a private contractor to fill the role. > Pretty simple, really. > > The government pay rate for someone with a Master's degree and ten > years of experience hovers around $60,000 per year, incidentally. > It's shockingly low by the standards of the tech sector. Not to mention that the U.S. Government, for all intents and purposes, gave up doing background security checks around 2006 since it could not manage the backlog. Well, they did not give it up so much as contract it out to a company that put profit ahead of product and they essentially stopped doing it on the governments behalf. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 From JPClizbe at tx.rr.com Thu Apr 10 06:16:47 2014 From: JPClizbe at tx.rr.com (John Clizbe) Date: Wed, 09 Apr 2014 23:16:47 -0500 Subject: It's 2014. Are we there yet? In-Reply-To: <53458A50.2050906@sixdemonbag.org> References: <53458A50.2050906@sixdemonbag.org> Message-ID: <53461B2F.3020205@tx.rr.com> Robert J. Hansen wrote: >> The ?secure communications? paradigm of course spans a whole spectrum >> from ?I don?t give a ****? to ?I?ll do anything to protect my >> communications, including giving away my first born?. I suspect the >> ?average Joe user? in 2014 is slightly above the former, but way below >> the latter. Without going to the other end of the spectrum, what will >> make adoption of secure communications a bit more palatable to the >> ?average Joe user?? > > Every year or so this subject comes up, and my answers are unchanged > from last time: start by reading up on academic papers studying this > exact problem. For a while John Clizbe and I kept a list of good > papers, but I have to confess I haven't been keeping up on the latest > literature. Still, our last list is pretty good reading. > > (These selections come from both John and me, but John is the one who > assembled them into proper cite format -- thanks, John. For the > original message, see "Re: what is killing PKI?" on this mailing list, > posted on 24 Aug 2012.) > > ===== Oh yeah, THAT thread. There hasn't been much new work that I've seen. Certainly nothing invalidating any of these. The list along with available from links: Gaw, S., Felten, E. W., and Fernandez-Kelly, P. 2006. Secrecy, flagging, and paranoia: adoption criteria in encrypted email. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Montreal, Quebec, Canada, April 22 - 27, 2006). R. Grinter, T. Rodden, P. Aoki, E. Cutrell, R. Jeffries, and G. Olson, Eds. CHI '06. ACM, New York, NY, 591-600. DOI= http://doi.acm.org/10.1145/1054972.1055069 Available at: http://www.soe.ucsc.edu/classes/cmps223/Spring09/Gaw%2006.pdf I would also add Garfinkel, S. L., Margrave, D., Schiller, J. I., Nordlander, E., and Miller, R. C. 2005. How to make secure email easier to use. In _Proceedings of the SIGCHI Conference on Human Factors in Computing Systems_ (Portland, Oregon, USA, April 02 - 07, 2005). CHI '05. ACM, New York, NY, 701-710. DOI= http://doi.acm.org/10.1145/1054972.1055069 Available at: http://simson.net/ref/2004/chi2005_smime_submitted.pdf And a perennial favorite: Steve Sheng, Levi Broderick, Colleen Alison Koranda, and Jeremy J. Hyland. Why Johnny Still Can?t Encrypt: Evaluating the Usability of Email Encryption Software. Poster session, 2006 Symposium On Usable Privacy and Security, Pittsburgh, PA, July 2006. http://cups.cs.cmu.edu/soups/2006/posters/sheng-poster_abstract.pdf And its predecessor: Alma Whitten and J.D. Tygar. Why Johnny Can?t Encrypt: A Usability Evaluation of PGP 5.0. In Proceedings of the 8th USENIX Security Symposium, Washington, DC, August 1999. http://bit.ly/OaEeTD > > Everyone on this mailing list has their own pet theory for why PKI > > adoption is so lousy. All of us are probably wrong. However, > > published, peer-reviewed studies of PKI adoption and the forces driving > > and inhibiting them are probably less wrong. The peer reviewed literature has many, many, references on this topic. They're a great place to start when assumptions and pet theories take root. http://scholar.google.com/scholar?q=email+encryption ++++++++++++ 2nd msg:Chatting with Kristen [Fiskerstrand], he pointed me to Usability of Security: A Case Study. Alma Whitten and J. D. Tygar. Carnegie Mellon University Computer Science technical report CMU-CS-98-155, December 1998. Abstract: http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA361032 'The unmotivated user property' and 'The abstraction property' are particularly worth noting and keeping in mind. -John -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 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: 475 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Apr 15 00:51:44 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 Apr 2014 18:51:44 -0400 Subject: The bug... More info. In-Reply-To: References: <534C27D4.6030300@comcast.net> <20140414122713.Horde.6CjkoTfBrocTDJW3ttzALw1@mail.sixdemonbag.org> <534C3A3E.1010603@comcast.net> <20140414134746.Horde._l0pc9d43-CUjVXGHrZtjg1@mail.sixdemonbag.org> Message-ID: <534C6680.5060408@sixdemonbag.org> > backlog. Well, they did not give it up so much as contract it out to a > company that put profit ahead of product and they essentially stopped doing it > on the governments behalf. I was about to not respond, but -- I have this thing about errors of fact: I want to see them corrected. So yes, this is off-topic, and I plan on letting this end here. The USG still does a lot of these, and there are several companies providing these background check services. USIS, one of the largest providers, is under investigation for misconduct -- but let's not go about thinking the entire system has collapsed, or that the USG doesn't do any of the work itself any more. Neither is true. From mirimir at riseup.net Tue Apr 15 00:03:12 2014 From: mirimir at riseup.net (Mirimir) Date: Mon, 14 Apr 2014 16:03:12 -0600 Subject: It's 2014. Are we there yet? In-Reply-To: <53461B2F.3020205@tx.rr.com> References: <53458A50.2050906@sixdemonbag.org> <53461B2F.3020205@tx.rr.com> Message-ID: <534C5B20.7090307@riseup.net> On 04/09/2014 10:16 PM, John Clizbe wrote: > Robert J. Hansen wrote: >>> The ?secure communications? paradigm of course spans a whole spectrum >>> from ?I don?t give a ****? to ?I?ll do anything to protect my >>> communications, including giving away my first born?. I suspect the >>> ?average Joe user? in 2014 is slightly above the former, but way below >>> the latter. Without going to the other end of the spectrum, what will >>> make adoption of secure communications a bit more palatable to the >>> ?average Joe user?? >> >> Every year or so this subject comes up, and my answers are unchanged >> from last time: start by reading up on academic papers studying this >> exact problem. For a while John Clizbe and I kept a list of good >> papers, but I have to confess I haven't been keeping up on the latest >> literature. Still, our last list is pretty good reading. >> >> (These selections come from both John and me, but John is the one who >> assembled them into proper cite format -- thanks, John. For the >> original message, see "Re: what is killing PKI?" on this mailing list, >> posted on 24 Aug 2012.) Some of us wonder why Mixmaster nyms never took off, and we consider Enigmail as the Holy Grail of usability ;) From florian at florian-wolters.de Tue Apr 15 16:34:30 2014 From: florian at florian-wolters.de (Florian Wolters) Date: Tue, 15 Apr 2014 16:34:30 +0200 Subject: Chipdrive SPR 532 and OpenPGP Card with 4096Bit RSA Keys In-Reply-To: References: <20140403124204.GB11096@miraculix.wolters.lan> <533FE41F.4030009@digitalbrains.com> <20140405135757.GA6302@miraculix.wolters.lan> Message-ID: <534D4376.4050506@florian-wolters.de> Hi @ll, I got one further question regarding the Chipdrive. This device is one with a pinpad. But currently the PIN is asked on the monitor and to be entered with the keyboard rather than the pinpad. Can that be associated with running just "gpg2 --card-status"? How does GnuPG decide wether to ask for the Pin on screen or to let it be entered on the pinpad? I had that working when I ran "keytocard" but I cannot return to this state ... Regards Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Apr 15 22:06:57 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 15 Apr 2014 22:06:57 +0200 Subject: Chipdrive SPR 532 and OpenPGP Card with 4096Bit RSA Keys In-Reply-To: <534D4376.4050506@florian-wolters.de> References: <20140403124204.GB11096@miraculix.wolters.lan> <533FE41F.4030009@digitalbrains.com> <20140405135757.GA6302@miraculix.wolters.lan> <534D4376.4050506@florian-wolters.de> Message-ID: <534D9161.3010205@digitalbrains.com> On 15/04/14 16:34, Florian Wolters wrote: > How does GnuPG decide wether to ask for the Pin on screen or to let it > be entered on the pinpad? AFAIK, only the internal CCID driver supports entry on the pinpad, and it is by default enabled when using the internal CCID driver. However, if you have pcscd running, I suppose GnuPG will use that. Then the pinpad is not supported. So: do you have a pcscd running? If you don't need it, stop it, and scdaemon will use it's interal driver. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From mailinglisten at hauke-laging.de Wed Apr 16 16:14:23 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 16 Apr 2014 16:14:23 +0200 Subject: signatures for other people's emails Message-ID: <1877363.7A8bajizQs@inno> Hello, this is not GnuPG-specific, not even crypto-specific in the sense that I guess no real change to any crypto tool or standard would be necessary. Technically it's about a new MIME container usage but crypto-related. I hope here are the right people to comment on that. Somehow I prefer getting slammed here over the openpgp working group mailing list... This idea came from a real experience a few days ago. I am trying to get crypto usage on a large scale to one of Germany's biggest universities (FU Berlin). The CS and math departments organize a small (but official) information event. I give four real courses (inofficial but supported by the dean; http://crypto.spline.de/). As this is mainly about peer pressure for the freshman students I wanted to teach some of the Ph.D. students crypto first. We invited about 30 people, none even reacted. I was told that this effect was less about the offer itself but more about the point that this was "one more email from a stranger to a group of people". I.e. probably not even read by many of them. That was the example, now the idea: With a small change to the PGP/MIME standard this would have been possible: I write the email but do not send it to the intended recipients but to the dean first. He makes a signature (some easy one- click feature maybe with a comment) about the email (or about my signature) and sends it back to me. Then I add his signature to my email and send it to the recipients. Now this happens: The recipients still see an email from a stranger to a group of people but now their mail client tells them that their dean (and maybe even more people) supports this email. Of course, you have noticed that a crypto feature does not work in a mail which shall make people start using crypto but you get the idea. This would be possible without crypto, too, but I guess to easy to abuse for being accepted. I guess it would be enough to replace the signature container by a multipart container with several signatures. Somehow the real sender signature would have to be marked (or rather: the support signatures should be marked as such, either implicitly by being a signature over the sender signature or explicitly by a notation). I don't want to be too optimistic but I guess this could be so useful that it might actually become a reason for the not so small "I have nothing to hide" group to start using crypto. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Wed Apr 16 18:21:16 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 16 Apr 2014 18:21:16 +0200 Subject: signatures for other people's emails In-Reply-To: <1877363.7A8bajizQs@inno> References: <1877363.7A8bajizQs@inno> Message-ID: The usual way it works here would be, in your example, for the dean to send the recipients a message with "Please consider the request in the attached message", and your message would be attached. That way, it is the dean who requests something, and the PhD would be inclined to read it. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From mailinglisten at hauke-laging.de Wed Apr 16 18:37:56 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 16 Apr 2014 18:37:56 +0200 Subject: signatures for other people's emails In-Reply-To: References: <1877363.7A8bajizQs@inno> Message-ID: <1567753.xkBQJNmas7@inno> Am Mi 16.04.2014, 18:21:16 schrieb Peter Lebbing: > The usual way it works here would be, in your example, for the dean to > send the recipients a message with "Please consider the request in > the attached message", and your message would be attached. That way, > it is the dean who requests something, and the PhD would be inclined > to read it. That is indeed possible but has disadvantages: a) It does not work with more than one supporter. b) The supporter becomes more involved in the communication than he wants to: He appears as the sender and may receive answers (even bounces and autoresponders). c) The real sender does not have the mail in his sent mail archive thus breaking the usual communication structure. In case of doubt he does not even know whether the mail has already been sent by the supporter. d) The same for the recipients: They cannot simply search for a mail from the real sender. e) The supporter must handle the recipients in that case. That may be a complicated procedure; he may not even have all the addresses yet. I guess you agree that the procedure you suggest is possible but would be used only due to the lack of something better and not because it was the best (or even a good) way of doing that. The practical question is: Would you vote / argue against the development of such a new feature because of the existing possibilities? A general remark: Some time ago we had a discussion here about the future of email. Who's still using it and for what and the like. I think with this background it makes sense to consider how email can become better. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From tux.tsndcb at free.fr Wed Apr 16 17:40:30 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Wed, 16 Apr 2014 17:40:30 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <534D9161.3010205@digitalbrains.com> Message-ID: <1064592255.112549990.1397662830669.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello Peter, Actually, I'm on a fresh sid Debian installed, I've use during install crypted LVM volume for all my partitions excepted for /boot. So now I've two files like these : /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # /dev/mapper/sda5_crypt / btrfs ssd,discard,noatime 0 1 # /boot was on /dev/sda1 during installation UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /boot btrfs ssd,discard,noatime 0 2 /dev/mapper/sda7_crypt /data btrfs ssd,discard,noatime 0 2 ... and /etc/cryptab : sda5_crypt UUID=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy none luks,discard sda7_crypt UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx none luks,discard .... In a first time, I want to add a key.gpg file solution, so in the firt time I want it ask to me the pincode for the key.gpg file, and if it's wrong or broken ask me the usual passphrase. So could you explain us step by step, how to add this key.gpg as passphrase on a existing lvm crypted partition and how to have gnupg smartcard activate on boot to decrypt the key.gpg file ? Thanks in advanced for your return. PS : my gnupg smartcard works actually fine on a terminal on xsession. Best Regards From tim at piratemail.se Wed Apr 16 17:39:15 2014 From: tim at piratemail.se (tim at piratemail.se) Date: Wed, 16 Apr 2014 11:39:15 -0400 (EDT) Subject: signatures for other people's emails Message-ID: <0a6c5f9e-fbc1-6a04-fffb-29fecfbb2b04@piratemail.se> I'm sure there are more qualified people to answer this, but since I've been staring at pgp-mime for the last few months, I thought I would give a few thoughts. I believe you are asking, "is it possible to concatenate signatures, to create a new signature block which is then used with pgp-mime." 1. I think this is possible. If the dean signs your content, and you receive his signature, I *believe* that once an implementation gets the signature packet from the signature, it could added to a signature block. Each signature packet contains the keyid of the signer (if put there), and its own signature type/algorithm/hash/etc. So, I *believe* each signature is independent of every other signature. In my process of checking a signature, I find the keyId and lookup the keyId for the publicKey. So it doesn't matter who the mail is actually from. 2. An alternative, which you spoke of, I believe, would also work. Where a pgp-mime signature pair, contains a pgp-mime signature pair. So your dean would send you the mail, and you could encapsulate it with your own signature. The tricky part, of course, would be if any implementation actually facilitates this. Cheers, -tim p.s. Thanks for your help with the pgp-mime previously, -- g at pmx.mooo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 513 bytes Desc: Message signed with OpenPGPJS URL: From mwood at IUPUI.Edu Wed Apr 16 19:28:02 2014 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Wed, 16 Apr 2014 13:28:02 -0400 Subject: signatures for other people's emails In-Reply-To: <1567753.xkBQJNmas7@inno> References: <1877363.7A8bajizQs@inno> <1567753.xkBQJNmas7@inno> Message-ID: <20140416172802.GC32102@IUPUI.Edu> I also thought it would be preferable just to pass the message through the person whose prestige would, if lent, get you a reading. The problem with having the message come from an unknown is that it is coming from an unknown. If the message is not opened, it doesn't matter whose signatures are on it, because they will not be seen. So, I don't think that multiple signatures addresses the original problem at all. However, there are uses for documents which must bear multiple signatures from *known* individuals or roles, and being able to present all of those signatures as a set, rather than having them scattered through layers of MIME frosting, would be valuable to some. OTOH some types of multiple signature may require "signature over signature": a signed document contained in another signed document, so that the outer signature attests that at the time it was made, the inner document bore a specific signature. It may be possible to compress the structure if there were defined signature types for these uses, so that one knows (for example) to include all of the foregoing signatures in the text to be validated. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Machines should not be friendly. Machines should be obedient. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From tux.tsndcb at free.fr Wed Apr 16 22:19:28 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Wed, 16 Apr 2014 22:19:28 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: Message-ID: <264630471.113417177.1397679568591.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello, Thanks for your answer, I've already see your article and I asked to me many questions. But in my case I've already crypted lvm partition with a passphrase, so can I only generated key.txt file and encrypt it with my gnupg key and add in cryptab file : /etc/cryptab : sda5_crypt UUID=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy /etc/gpg_luks/luks-key.txt none luks,keyscript=/usr/local/sbin/decrypt_luks.sh sda5_crypt UUID=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy none luks,discard crypto /dev/sda2 none luks,keyscript=/usr/local/sbin/decrypt_luks.sh sda7_crypt UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx none luks,discard But in the debian case, it's seems than I neeed to use /lib/cryptsetup/scripts/decrypt_gnupg, but I've not really exemple on that. Best Regards ----- Mail original ----- De: "Thomas Harning Jr." ?: "tux tsndcb" Cc: "Peter Lebbing" , gnupg-users at gnupg.org Envoy?: Mercredi 16 Avril 2014 21:32:22 Objet: Re: gnupg smartcard on boot for LUKS on sid debian howto ? I believe this blog article could be a useful reference: https://blog.kumina.nl/2010/07/two-factor-luks-using-ubuntu/ This happens to work beautifully w/ the Yubikey NEO and the GPG Applet The article does omit any backup measures, so I added a separate long passphrase to use in the backup case - but to use it requires the initial boot UI to fail and I manually unlock the volumes and resume boot w/o the gnupg unlock. On Wed, Apr 16, 2014 at 11:40 AM, < tux.tsndcb at free.fr > wrote: Hello Peter, Actually, I'm on a fresh sid Debian installed, I've use during install crypted LVM volume for all my partitions excepted for /boot. So now I've two files like these : /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # /dev/mapper/sda5_crypt / btrfs ssd,discard,noatime 0 1 # /boot was on /dev/sda1 during installation UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /boot btrfs ssd,discard,noatime 0 2 /dev/mapper/sda7_crypt /data btrfs ssd,discard,noatime 0 2 ... and /etc/cryptab : sda5_crypt UUID=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy none luks,discard sda7_crypt UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx none luks,discard .... In a first time, I want to add a key.gpg file solution, so in the firt time I want it ask to me the pincode for the key.gpg file, and if it's wrong or broken ask me the usual passphrase. So could you explain us step by step, how to add this key.gpg as passphrase on a existing lvm crypted partition and how to have gnupg smartcard activate on boot to decrypt the key.gpg file ? Thanks in advanced for your return. PS : my gnupg smartcard works actually fine on a terminal on xsession. Best Regards _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Thomas Harning Jr. ( http://about.me/harningt ) From harningt at gmail.com Wed Apr 16 21:32:22 2014 From: harningt at gmail.com (Thomas Harning Jr.) Date: Wed, 16 Apr 2014 15:32:22 -0400 Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <1064592255.112549990.1397662830669.JavaMail.root@zimbra33-e6.priv.proxad.net> References: <534D9161.3010205@digitalbrains.com> <1064592255.112549990.1397662830669.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: I believe this blog article could be a useful reference: https://blog.kumina.nl/2010/07/two-factor-luks-using-ubuntu/ This happens to work beautifully w/ the Yubikey NEO and the GPG Applet The article does omit any backup measures, so I added a separate long passphrase to use in the backup case - but to use it requires the initial boot UI to fail and I manually unlock the volumes and resume boot w/o the gnupg unlock. On Wed, Apr 16, 2014 at 11:40 AM, wrote: > Hello Peter, > > Actually, I'm on a fresh sid Debian installed, I've use during install > crypted LVM volume for all my partitions excepted for /boot. > > So now I've two files like these : > > /etc/fstab > # /etc/fstab: static file system information. > # > # Use 'blkid' to print the universally unique identifier for a > # device; this may be used with UUID= as a more robust way to name devices > # that works even if disks are added and removed. See fstab(5). > # > # > > /dev/mapper/sda5_crypt / btrfs > ssd,discard,noatime 0 1 > # /boot was on /dev/sda1 during installation > UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /boot btrfs > ssd,discard,noatime 0 2 > /dev/mapper/sda7_crypt /data btrfs > ssd,discard,noatime 0 2 > ... > > and > > /etc/cryptab : > sda5_crypt UUID=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy none luks,discard > sda7_crypt UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx none luks,discard > .... > > In a first time, I want to add a key.gpg file solution, so in the firt > time I want it ask to me the pincode for the key.gpg file, and if it's > wrong or broken ask me the usual passphrase. > > > So could you explain us step by step, how to add this key.gpg as > passphrase on a existing lvm crypted partition and how to have gnupg > smartcard activate on boot to decrypt the key.gpg file ? > > Thanks in advanced for your return. > > PS : my gnupg smartcard works actually fine on a terminal on xsession. > > Best Regards > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Thomas Harning Jr. (http://about.me/harningt) -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2014-667rhzu3dc-lists-groups at riseup.net Thu Apr 17 10:21:44 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 17 Apr 2014 09:21:44 +0100 Subject: signatures for other people's emails In-Reply-To: <1567753.xkBQJNmas7@inno> References: <1877363.7A8bajizQs@inno> <1567753.xkBQJNmas7@inno> Message-ID: <903543789.20140417092144@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 NotDashEscaped: You need GnuPG to verify this message Hi On Wednesday 16 April 2014 at 5:37:56 PM, in , Hauke Laging wrote: > c) The real sender does not have the mail in his sent > mail archive That assumes he deleted it from his archive after sending to the supporter. > In case of doubt he does not even know > whether the mail has already been sent by the > supporter. Possible, if the supporter didn't cc him. > d) The same for the recipients: They cannot simply > search for a mail from the real sender. There is no reason the real sender couldn't also send the message directly. I see this at work from time to time, where somebody of high profile (or their PA) forwards a message that was already circulated and directs people to act on the contents. -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net I think not, said Descartes, and promptly disappeared -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNPjyhXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pzHcEAI0u78qAlWyajTuSalOAQwcS0RIHivlNEsHE mstGb2N47pJVwP/GiqcxO0KD1KNGyJPHFvx9SXCwlos6V4hSLZzboLo2xsWi1eV1 zwguargWGpvyVMYN52jlSU6sYEbYESlqMJiDjAhpm+oDPCRyq9ccs93uK2UQtO+J BU7+UWt7 =6qxZ -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Thu Apr 17 12:36:59 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 17 Apr 2014 11:36:59 +0100 Subject: GPG and BCC In-Reply-To: <1430606.o2gaqJObOZ@thufir.ingo-kloecker.de> References: <5346C0C5.8050704@josuttis.de> <1430606.o2gaqJObOZ@thufir.ingo-kloecker.de> Message-ID: <1297234681.20140417113659@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 NotDashEscaped: You need GnuPG to verify this message Hi On Friday 11 April 2014 at 9:59:21 PM, in , Ingo Kl?cker wrote: > Apart from using the '--throw-keyids' option you could > send multiple copies of the message. One copy for the > public recipients which is encrypted with the keys of > all public recipients (To, Cc). And n copies for the n > Bcc recipients where each copy is encrypted with the > key of one Bcc recipient. That's what KMail does. A few years ago when trialling various email programs, one that I tried encrypted an individual copy for each recipient when you sent an encrypted mail with multiple recipients. -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net A picture is a poem without words -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNPrulXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pYJgD/RQscR9CcMwHqXWHoyZ6lXM4ZUmaJvxZ8iz8 VTmI8l8m+dWc3VylQGfouEdjoIKqQagc0sNEd3SXMu98izAcejPXDWr/hW3kpB/M y93V0gzoc1FrgNO0ldmpqsuOhZ5PehoSoLlglYFm3IfTSAXU3TQQB4OOJ3V+X8qG R48jQVf/ =cgsC -----END PGP SIGNATURE----- From aheinecke at intevation.de Thu Apr 17 14:56:15 2014 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 17 Apr 2014 14:56:15 +0200 Subject: GPG tool for Windows Embeddd Compact 7 In-Reply-To: References: Message-ID: <201404171456.25251.aheinecke@intevation.de> Hi, At Thursday 17 April 2014 14:08:06 dbhukta . wrote: > On Wed, Apr 9, 2014 at 10:09 AM, dbhukta . wrote: > > > > Can you give the solution for GPGtool which will run for Windows Embedded > > Compact 7. Or any Binary file which will be compatible for windows > > embedded compact 7. > > As already said, there is no Version of GnuPG known to work wiht Windows Embedded Compact 7. The last Windows CE I know of where GnuPG was able to run was Windows Mobile 6.5 (Windows CE 5 Kernel). I have no idea about Windows Embedded Compact 7. And I can not estimate the effort / work required to port / compile GnuPG for that platform. If you have professional interest in this maybe you can contract Werner Koch's company g10code ( http://www.g10code.com/ ) to look into this for you. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Thu Apr 17 20:14:21 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 17 Apr 2014 20:14:21 +0200 Subject: GPG and BCC In-Reply-To: <1297234681.20140417113659@my_localhost> References: <5346C0C5.8050704@josuttis.de> <1430606.o2gaqJObOZ@thufir.ingo-kloecker.de> <1297234681.20140417113659@my_localhost> Message-ID: <1527946.suRYxdqfv7@thufir.ingo-kloecker.de> On Thursday 17 April 2014 11:36:59 MFPA wrote: > On Friday 11 April 2014 at 9:59:21 PM, in > , Ingo Kl?cker wrote: > > Apart from using the '--throw-keyids' option you could > > send multiple copies of the message. One copy for the > > public recipients which is encrypted with the keys of > > all public recipients (To, Cc). And n copies for the n > > Bcc recipients where each copy is encrypted with the > > key of one Bcc recipient. That's what KMail does. > > A few years ago when trialling various email programs, one that I > tried encrypted an individual copy for each recipient when you sent an > encrypted mail with multiple recipients. Sure. One could do this. But I don't see the point of encrypting an individual copy for each To/Cc recipient. The only additional information a single message encrypted for all To/Cc recipients gives the recipients is the list of key IDs of the other recipients. Under very special circumstances this could be undesirable, but under those special circumstances one probably also doesn't want to have all recipients listed in To/Cc. So, we are back to using Bcc or sending completely indiviual messages. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From 2014-667rhzu3dc-lists-groups at riseup.net Thu Apr 17 21:55:49 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 17 Apr 2014 20:55:49 +0100 Subject: GPG and BCC In-Reply-To: <1527946.suRYxdqfv7@thufir.ingo-kloecker.de> References: <5346C0C5.8050704@josuttis.de> <1430606.o2gaqJObOZ@thufir.ingo-kloecker.de> <1297234681.20140417113659@my_localhost> <1527946.suRYxdqfv7@thufir.ingo-kloecker.de> Message-ID: <162943225.20140417205549@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 NotDashEscaped: You need GnuPG to verify this message Hi On Thursday 17 April 2014 at 7:14:21 PM, in , Ingo Kl?cker wrote: > Sure. One could do this. But I don't see the point of > encrypting an individual copy for each To/Cc > recipient. The only additional information a single > message encrypted for all To/Cc recipients gives the > recipients is the list of key IDs of the other > recipients. Under very special circumstances this > could be undesirable, And could be avoided with --throw-keyids. > but under those special > circumstances one probably also doesn't want to have > all recipients listed in To/Cc. So, we are back to > using Bcc My opinion is that it is usually a good idea to err on the side of caution and use BCC, but in certain specific circumstances it is acceptable to use multiple entries in To or CC. > or sending completely indiviual messages. Tha mailer to which I was referring actually did send completely individual messages, when you told it to encrypt a message that had multiple recipients. -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net A closed door is an invitation to knock -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNQMdtXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pIpYEAINFaDN9hZhpCgI1aHt34w9oW6xqjrLWIvf/ NI9Qug3UL+g6t8PngJvjD44zhxekLZIVatjx5+bZlif6aXAnwjpt6nBdF7z/03A9 fPhXhwG6YKFGmGcl9YkYiNls3vVSp0ZzyM4MWP14bALcA7nm2moHlgM5y0h48PRD bYoOHfGe =xsrr -----END PGP SIGNATURE----- From dbhukta at gmail.com Thu Apr 17 14:08:06 2014 From: dbhukta at gmail.com (dbhukta .) Date: Thu, 17 Apr 2014 17:38:06 +0530 Subject: GPG tool for Windows Embeddd Compact 7 In-Reply-To: References: <201402201801.39298.aheinecke@intevation.de> Message-ID: Hi, Waiting for your valuable answer of the GPGtool for compatible in Windows embedded compact 7. Looking forward ... Thanks On Wed, Apr 9, 2014 at 10:09 AM, dbhukta . wrote: > Hi, > > Can you give the solution for GPGtool which will run for Windows Embedded > Compact 7. Or any Binary file which will be compatible for windows embedded > compact 7. > > looking forward to hear from you. > > Regards > > D Bhukta > +918600096629 > > > > > On Fri, Feb 21, 2014 at 1:29 AM, Alan Meekins wrote: > >> Not all Windows Embedded OSes are built on top of CE! Look here for a >> listing of the products. >> It sounds like you are likely using Windows Embedded Standard 7(aka WES7, >> yuck what a mouthful!) which is just a rebranded version of normal old >> Windows 7. If this is the case it means anything that can run on windows >> 7(big windows) will run on WES7 with no modification. The caveat about >> Windows Embedded is that you have the flexibility to strip out just about >> any componenet of Windows so the most likely issues you will hit are around >> what you have removed from the image causing breaks in 3rd party software >> such as GnuPG. So in short we need to know the exact version if Windows you >> are running to really give accurate advice. CE is a different world which >> may require you to recompile the programs you wish to run depending on your >> exact scenario. >> >> Cheers, >> -Alan >> >> >> On Thu, Feb 20, 2014 at 9:01 AM, Andre Heinecke wrote: >> >>> Hi, >>> >>> On Wednesday 19 February 2014 08:13:36 dbhukta . wrote: >>> > Let me know any version which is compatible for Windows embedded >>> Compact 7 >>> > to encrypt/decrypt a text file at least. >>> >>> GnuPG has been ported to Windows CE 5.0 so it should / could work on >>> Windows >>> embedded 7 (I guess its untested) as this work was done 2010 as part of a >>> Project and there has been little interest in Windows CE since. >>> >>> We still have some binaries lying around: >>> >>> http://files.kolab.org/local/windows-ce/gpg-snapshots/gpg_wince-dev-190111.zip >>> >>> Sources for that version: >>> >>> http://files.kolab.org/local/windows-ce/gpg-snapshots/gpg-ce-dev-190111-src.zip >>> >>> And a signed sha1sums file in: >>> http://files.kolab.org/local/windows-ce/gpg-snapshots/ >>> >>> Maybe it works, maybe not. >>> Have fun >>> >>> -- >>> Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ >>> Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B >>> 18998 >>> Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner >>> >>> _______________________________________________ >>> Gnupg-users mailing list >>> Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>> >>> >> > > > -- > Regards, > > Dinabandhu Bhukta > 8600096629 > -- Regards, Dinabandhu Bhukta 8600096629 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tux.tsndcb at free.fr Fri Apr 18 18:21:40 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Fri, 18 Apr 2014 18:21:40 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <264630471.113417177.1397679568591.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <886573318.119724133.1397838100571.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello all, Someone has an idea to do that please and how to do that ? All help is appreciated. Thanks in advanced. Best Regards. ----- Mail original ----- De: "tux tsndcb" ?: "Thomas Harning Jr." Cc: gnupg-users at gnupg.org Envoy?: Mercredi 16 Avril 2014 22:19:28 Objet: Re: gnupg smartcard on boot for LUKS on sid debian howto ? Hello, Thanks for your answer, I've already see your article and I asked to me many questions. But in my case I've already crypted lvm partition with a passphrase, so can I only generated key.txt file and encrypt it with my gnupg key and add in cryptab file : /etc/cryptab : sda5_crypt UUID=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy /etc/gpg_luks/luks-key.txt none luks,keyscript=/usr/local/sbin/decrypt_luks.sh sda5_crypt UUID=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy none luks,discard crypto /dev/sda2 none luks,keyscript=/usr/local/sbin/decrypt_luks.sh sda7_crypt UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx none luks,discard But in the debian case, it's seems than I neeed to use /lib/cryptsetup/scripts/decrypt_gnupg, but I've not really exemple on that. Best Regards ----- Mail original ----- De: "Thomas Harning Jr." ?: "tux tsndcb" Cc: "Peter Lebbing" , gnupg-users at gnupg.org Envoy?: Mercredi 16 Avril 2014 21:32:22 Objet: Re: gnupg smartcard on boot for LUKS on sid debian howto ? I believe this blog article could be a useful reference: https://blog.kumina.nl/2010/07/two-factor-luks-using-ubuntu/ This happens to work beautifully w/ the Yubikey NEO and the GPG Applet The article does omit any backup measures, so I added a separate long passphrase to use in the backup case - but to use it requires the initial boot UI to fail and I manually unlock the volumes and resume boot w/o the gnupg unlock. On Wed, Apr 16, 2014 at 11:40 AM, < tux.tsndcb at free.fr > wrote: Hello Peter, Actually, I'm on a fresh sid Debian installed, I've use during install crypted LVM volume for all my partitions excepted for /boot. So now I've two files like these : /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # /dev/mapper/sda5_crypt / btrfs ssd,discard,noatime 0 1 # /boot was on /dev/sda1 during installation UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /boot btrfs ssd,discard,noatime 0 2 /dev/mapper/sda7_crypt /data btrfs ssd,discard,noatime 0 2 ... and /etc/cryptab : sda5_crypt UUID=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy none luks,discard sda7_crypt UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx none luks,discard .... In a first time, I want to add a key.gpg file solution, so in the firt time I want it ask to me the pincode for the key.gpg file, and if it's wrong or broken ask me the usual passphrase. So could you explain us step by step, how to add this key.gpg as passphrase on a existing lvm crypted partition and how to have gnupg smartcard activate on boot to decrypt the key.gpg file ? Thanks in advanced for your return. PS : my gnupg smartcard works actually fine on a terminal on xsession. Best Regards _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Thomas Harning Jr. ( http://about.me/harningt ) _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From schittli at gmx.ch Sat Apr 19 13:34:34 2014 From: schittli at gmx.ch (Thomas Schittli) Date: Sat, 19 Apr 2014 13:34:34 +0200 Subject: gpg Feature request: merge gpg.exe and gpgsm.exe into one tool Message-ID: Dear?GnuPG community ? I'm not sure if I'm right here for feature requests... I try it: ? Many open source tools like Git uses GnuPG. Unfortunately, they usually only support gpg.exe - and therefore don't know how to handle X.509 certificates. It's a pitty, because GnuPG supports X.509 certificates since 3 years... Therefore my Idea: please merge the functions of gpg.exe and pgpsm.exe into one application. And - I'm not sure if this is possible - try to automatically detect which kind of certificate is meant, e.g. if a function can not find the OpenSSL key, then it tries to use X.509. Thanks a lot for this great tool! Kind regards, Tom From peter at digitalbrains.com Sat Apr 19 15:15:24 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 19 Apr 2014 15:15:24 +0200 Subject: gpg Feature request: merge gpg.exe and gpgsm.exe into one tool In-Reply-To: References: Message-ID: <535276EC.4020306@digitalbrains.com> On 19/04/14 13:34, Thomas Schittli wrote: > please merge the functions of gpg.exe and pgpsm.exe into one application. Don't most applications that support/use GnuPG use OpenPGP signatures? If you would want to have signatures made by X.509 certs, the application needs to understand CMS (S/MIME is one form of CMS) unless it is agnostic about it. Being agnostic about it might be implementable in many scenarios, obtaining the signed text from GPGME. I just read[1] that a GPGME backend for CMS is already developed, so if an application uses GPGME (or some as yet unreleased version of GPGME) in the appropriate way, it might already benefit from both OpenPGP and CMS/X.509. But it boils down to: I don't think you can just change stuff on the GnuPG end and expect the programs that use GnuPG to be able to handle the different format produced. Maybe a different feature request would be: use the X.509 certificates and trust model in an OpenPGP context. That way, programs using GnuPG only ever see OpenPGP messages. But that feature request (or one very similar) has recently been done, and I can't remember seeing any acknowledgement of that. I myself commented that I'd rather see CMS use a better trust model than porting the X.509 trust model to OpenPGP: it's the wrong away around in my opinion. HTH, Peter. [1] http://www.gnupg.org/related_software/gpgme/ -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From one.jsim at gmail.com Sat Apr 19 16:35:39 2014 From: one.jsim at gmail.com (One Jsim) Date: Sat, 19 Apr 2014 15:35:39 +0100 Subject: It's 2014. Are we there yet? In-Reply-To: References: Message-ID: from: http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-keys.html#key-public-key-forgery at 2014-04-19T14:49+1 I retrieve "Yes, it is possible to create a public key with the same fingerprint as an existing one, thanks to a design misfeature in PGP 2.x when signing RSA keys. The fake key will not be of the same length, so it should be easy to detect. Usually such keys have odd key lengths" How percentage of PGP (or GPG?) users, do you think, know that checking fingerprint only is not an assurance against fake signatures? Did you know? Jose Simoes -------------- next part -------------- An HTML attachment was scrubbed... URL: From one.jsim at gmail.com Sat Apr 19 16:41:17 2014 From: one.jsim at gmail.com (One Jsim) Date: Sat, 19 Apr 2014 15:41:17 +0100 Subject: I never going to understand all this... Message-ID: from: http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-keys.html#key-public-key-forgery at 2014-04-19T14:49+1 I retrieve "Yes, it is possible to create a public key with the same fingerprint as an existing one, thanks to a design misfeature in PGP 2.x when signing RSA keys. The fake key will not be of the same length, so it should be easy to detect. Usually such keys have odd key lengths" How percentage of PGP (or GPG?) users, do you think, know that checking fingerprint only is not an assurance against fake signatures? Did you know? Jose Simoes -------------- next part -------------- An HTML attachment was scrubbed... URL: From one.jsim at gmail.com Sat Apr 19 17:00:15 2014 From: one.jsim at gmail.com (One Jsim) Date: Sat, 19 Apr 2014 16:00:15 +0100 Subject: It's 2014. Are we there yet? In-Reply-To: References: Message-ID: Any (easy) way to find out the version of a given key? 2014-04-19 15:46 GMT+01:00 Nicholas Cole : > On Sat, Apr 19, 2014 at 3:35 PM, One Jsim wrote: > > > > from: > > > > > > > http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-keys.html#key-public-key-forgery > > > > > > at 2014-04-19T14:49+1 > > > > > > I retrieve > > > > > > "Yes, it is possible to create a public key with the same fingerprint as > an > > existing one, thanks to a design misfeature in PGP 2.x when signing RSA > > keys. The fake key will not be of the same length, so it should be easy > to > > detect. Usually such keys have odd key lengths" > > > > > > How percentage of PGP (or GPG?) users, do you think, know that checking > > fingerprint only is not an assurance against fake signatures? Did you > know? > > > I *thought* [citation?] that this problem was fixed with version 4 keys. > > N. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas.cole at gmail.com Sat Apr 19 16:46:47 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sat, 19 Apr 2014 15:46:47 +0100 Subject: It's 2014. Are we there yet? In-Reply-To: References: Message-ID: On Sat, Apr 19, 2014 at 3:35 PM, One Jsim wrote: > > from: > > > http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-keys.html#key-public-key-forgery > > > at 2014-04-19T14:49+1 > > > I retrieve > > > "Yes, it is possible to create a public key with the same fingerprint as an > existing one, thanks to a design misfeature in PGP 2.x when signing RSA > keys. The fake key will not be of the same length, so it should be easy to > detect. Usually such keys have odd key lengths" > > > How percentage of PGP (or GPG?) users, do you think, know that checking > fingerprint only is not an assurance against fake signatures? Did you know? I *thought* [citation?] that this problem was fixed with version 4 keys. N. From rjh at sixdemonbag.org Sat Apr 19 18:02:26 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 19 Apr 2014 12:02:26 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: References: Message-ID: <53529E12.7000302@sixdemonbag.org> > How percentage of PGP (or GPG?) users, do you think, know that checking > fingerprint only is not an assurance against fake signatures? Did you know? Given that this only affects PGP 2.6 certificates, and GnuPG users overwhelmingly use modern v4 certificates, this is not a major problem for GnuPG users. From peter at digitalbrains.com Sat Apr 19 18:27:01 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 19 Apr 2014 18:27:01 +0200 Subject: I never going to understand all this... In-Reply-To: References: Message-ID: <5352A3D5.7000101@digitalbrains.com> On 19/04/14 16:41, One Jsim wrote: > How percentage of PGP (or GPG?) users, do you think, know that checking > fingerprint only is not an assurance against fake signatures? Did you know? This is for V3 keys, an old key format which has been superseded by V4 keys for a long time. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From one.jsim at gmail.com Sat Apr 19 22:45:10 2014 From: one.jsim at gmail.com (One Jsim) Date: Sat, 19 Apr 2014 21:45:10 +0100 Subject: It's 2014. Are we there yet? In-Reply-To: <53529E12.7000302@sixdemonbag.org> References: <53529E12.7000302@sixdemonbag.org> Message-ID: This is not clear to me. Certainly a key manager (example GPA) can have certificates that can be version 2. Other keys may or may not be version two but have been signed by the older version. As far as I understand the all thing can not be trusted (worse if you can not figure out the version of a given key). Jose Simoes 2014-04-19 17:02 GMT+01:00 Robert J. Hansen : > > How percentage of PGP (or GPG?) users, do you think, know that checking > > fingerprint only is not an assurance against fake signatures? Did you > know? > > Given that this only affects PGP 2.6 certificates, and GnuPG users > overwhelmingly use modern v4 certificates, this is not a major problem > for GnuPG users. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sat Apr 19 23:14:47 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 19 Apr 2014 17:14:47 -0400 Subject: It's 2014. Are we there yet? In-Reply-To: References: <53529E12.7000302@sixdemonbag.org> Message-ID: <5352E747.3030509@sixdemonbag.org> > Certainly a key manager (example GPA) can have certificates that can be > version 2. Version 3. PGP 2.6 used version 3 certificates. PGP 5 and beyond, and all versions of GnuPG, have always used version 4 certificates natively; support for version 3 certificates is done only for backwards compatibility. > As far as I understand the all thing can not be trusted (worse if you > can not figure out the version of a given key). If you don't want to trust GnuPG, don't look to me to talk you out of it. Life's too short. If you have questions I'll happily answer them, but I have zero interest in persuading you that GnuPG should be used or trusted. From tim at piratemail.se Sat Apr 19 23:40:04 2014 From: tim at piratemail.se (tim at piratemail.se) Date: Sat, 19 Apr 2014 17:40:04 -0400 (EDT) Subject: pgp key servers cors support Message-ID: <0a896968-c2a4-a527-8465-063f04229a2b@piratemail.se> Greetings, I believe I asked a pgp key server http interface question on this list a while ago, and received a useful response. I also wrote tobug-pks at mit.eduwith the request below.. With no response. Is there any way that the http pgp key servers could be changed to provide cors headers allowing access from any site? This could also be done through some proxy server (njinx?) which accepts, forwards and then concatenates cors headers to the response. The reason is to enable sites' clients such as the one I'm developing, to hit a random assortment of pgp keyservers without proxying through my server. (although proxying through my server is fine, it would be better, I think, to talk directly to those pgp keyservers). I realize this is not the pgp keyserver mailing list. But I figure the developers of that server also reside in this list -- and I'm not sure exactly which list is the right list to post to. http://www.alt.org/pipermail/pgp-keyserver-folk/ 404s -tim From tux.tsndcb at free.fr Sun Apr 20 09:05:48 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Sun, 20 Apr 2014 09:05:48 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <1064592255.112549990.1397662830669.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <202515263.124170533.1397977548221.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello Peter, I've read the README.gnupg file in cryptsetup, and it is indicate 3 steps to do : 1) First, you'll have to create the encrypted keyfile by: # dd if=/dev/random bs=1 count=256 | gpg --no-options --no-random-seed-file \ --no-default-keyring --keyring /dev/null --secret-keyring /dev/null \ --trustdb-name /dev/null --symmetric --output /etc/keys/cryptkey.gpg 2) Formate the partition with this cryptkey.gpg key file # /lib/cryptsetup/scripts/decrypt_gnupg /etc/keys/crytpkey.gpg | \ cryptsetup --key-file=- luksFormat /dev/ 3) Modifie the /etc/crypttab file : cdev1 /dev/ /etc/keys/cryptkey.gpg luks,keyscript=decrypt_gnupg But in fact I've a problem in the step 1, because if I use the command line : # dd if=/dev/random bs=1 count=256 | gpg --no-options --no-random-seed-file \ --no-default-keyring --keyring /dev/null --secret-keyring /dev/null \ --trustdb-name /dev/null --symmetric --output /etc/keys/cryptkey.gpg It is not my gnupg key use to encrypt this cryptkey.gpg file, so it will be not my gnupg key on my smartcard use to decrypt it. How can I modify in this command line to use my gnupg key to generate this cryptkey.gpg ? Thanks in advanced for your return. Best Regards. From peter at digitalbrains.com Sun Apr 20 11:05:54 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 20 Apr 2014 11:05:54 +0200 Subject: gpg Feature request: merge gpg.exe and gpgsm.exe into one tool In-Reply-To: References: Message-ID: <53538DF2.2090603@digitalbrains.com> On 19/04/14 23:31, Thomas Schittli wrote: > It does not make sense to manage another kind of certs just because > applications that suport/use GnuPG did not added gpgsm support. > [...] > I made a test with Git: I just renamed gpgsm.exe to gpg.exe. It worked > perfectly! I see the real problem in a different area. gpg.exe with OpenPGP keys generates OpenPGP messages. gpgsm.exe with X.509 certificates generates CMS messages. Applications calling gpg.exe expect an OpenPGP message. If you replace this OpenPGP message by a CMS message, perhaps the application will still work. Or it will break in certain places or break after the author of the application changes it in a way that needs OpenPGP messages, because the author is under the /correct/ impression that gpg.exe gives him an OpenPGP message, or parses an OpenPGP message passed to it. Most applications should be using GPGME anyway instead of calling gpg.exe directly, and X.509 support for GPGME is something that is being worked on, so an application that doesn't mind whether it handles OpenPGP messages or CMS messages can just use the appropriate functions of GPGME. > Therefore I'm pretty sure it was a conceptual error to support X.509 in > another tool. If X.509 were added into gpg, then every application would > immediately had support for both worlds :-) Unfortunately, no. A lot of applications would break. Suppose you are expecting a certain subsystem to generate German messages, and you put those messages on your website. If the subsystem would suddenly switch to Chinese, do you think your clients from Switzerland would be happy that they now had support for both languages, or do you think they would contact support and ask what the #@%& that stuff on your site is supposed to mean? ;) It's up to the applications. If they call gpg.exe directly, they are expecting OpenPGP functionality. You can just break that assumption and hope the application still works, but it seems to me you're breaking the expectations the programmer had when he wrote the code calling gpg.exe directly. On the other hand, if the application uses GPGME, then CMS support (and thus the X.509 trust model) seems to be already in the works, and when applications choose they also want to support that, it might be as easy to support both OpenPGP and CMS as it is to support just one. I don't know if CMS support in GPGME is already usable, but it seems much more viable to do a feature request[1] in that area than to request that the two binaries gpg.exe and gpgsm.exe, which handle completely different messages, be merged into one. I don't think that is going to happen, because it would break a lot of applications. HTH, Peter. [1] Possibly involving funding -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From kristian.fiskerstrand at sumptuouscapital.com Sun Apr 20 18:37:43 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sun, 20 Apr 2014 18:37:43 +0200 Subject: pgp key servers cors support In-Reply-To: <0a896968-c2a4-a527-8465-063f04229a2b@piratemail.se> References: <0a896968-c2a4-a527-8465-063f04229a2b@piratemail.se> Message-ID: <5353F7D7.3080702@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/19/2014 11:40 PM, tim at piratemail.se wrote: > > > Greetings, > > I believe I asked a pgp key server http interface question on this > list a while ago, and received a useful response. > > I also wrote tobug-pks at mit.eduwith the request below.. With no > response. For questions regarding keyservers, sks-devel[0] is probably your best bet.. > > > > Is there any way that the http pgp key servers could be changed to > provide cors headers allowing access from any site? This could > also be done through some proxy server (njinx?) which accepts, > forwards and then concatenates cors headers to the response. This is alreday included in the SKS trunk as of commit [1] for an upcoming 1.1.5 release. Once that is released subset.pool.sks-keyservers.net[2] will be bumped to this as a min requirement and can be used for your purposes. > > I realize this is not the pgp keyserver mailing list. But I figure > the developers of that server also reside in this list -- and I'm > not sure exactly which list is the right list to post to. > References [0] http://lists.nongnu.org/archive/html/sks-devel/ [1] https://bitbucket.org/skskeyserver/sks-keyserver/commits/f6e4e88a049a3497cc17b0ad15530782d78bc59f?at=default [2] https://sks-keyservers.net/overview-of-pools.php#pool_subset - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "I have always wished that my computer would be as easy to use as my telephone. My wish has come true -- I no longer know how to use my telephone" (Bjarne Stroustrup, April 1999) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTU/fUAAoJEPw7F94F4TaggwwP/jNtYKU4h27XPGudP8GmxKF3 0MIYyXUYqQElcHyNl/Ji/hcCrILZ8bj2XCyxMvulNEvNs23lLxCccziL0t8FKCOG iralbpjwszSqmeKsuZ1dr5ZsG2DzOvqgLz3d/k1pRSo3XHwmB4rlvM3W++hlwT/A sYNizJVwrQ2OdZSApnnufub4b0VNcTvIIalMDnkAtI43Dk4hL1gFaPEpbnLneExd lDDcUKDyqudBi7oNvQhS8nIGiPOp4cmU/+AJy5nU0NoNTJ60CYBO97TIifgWJuY5 Dwt6aSEoXZTraIS0tlEWguzY3Le4ztY/8ho9HSKgKSshatCq5z2LUfpZpVZvBQ3r vK4fgK0uGpHm1oz9ah9V0lH1nWnSWKYvDldrm44k9PJ3F7zl3gSSAGi+A+2OFqGY mDVrFmidLUEztKnD0hw7Hee1Ooj36EUBkYxhTGdGxDLzvY7ZKkq7so6stsc4FmSj mhOw10ju1SF8Ag1dWe3VH+H22dsukU6B+ZgEKlKRnO0R2ZPFJ08ik/WiKBjyJ+N9 cveOxZeIKGsb/urJtR8ExTLt3fVW7ampDRlz0624FcGc4ETY54x/tEDQWD9XEN37 haM9MWr8xTQR5katIwnq80h1xSpEJVvoBi+8jWI6C9LyW8TGD9fb+lw87lRbTFkt rCzcQ3DejmyS82DZCZrh =Rp3p -----END PGP SIGNATURE----- From schittli at gmx.ch Sat Apr 19 23:31:45 2014 From: schittli at gmx.ch (Thomas Schittli) Date: Sat, 19 Apr 2014 23:31:45 +0200 Subject: gpg Feature request: merge gpg.exe and gpgsm.exe into one tool Message-ID: An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Mon Apr 21 17:33:00 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 21 Apr 2014 17:33 +0200 Subject: signatures for other people's emails In-Reply-To: <20140416172802.GC32102@IUPUI.Edu> References: <1877363.7A8bajizQs@inno> <1567753.xkBQJNmas7@inno> <20140416172802.GC32102@IUPUI.Edu> Message-ID: <4849028.pvhLXguCOh@inno> Am Mi 16.04.2014, 13:28:02 schrieb Mark H. Wood: > I also thought it would be preferable just to pass the message through > the person whose prestige would, if lent, get you a reading. The > problem with having the message come from an unknown is that it is > coming from an unknown. If the message is not opened, it doesn't > matter whose signatures are on it, because they will not be seen. That's obviously not what would happen in typical situations. A mail client which implements such a feature would notify the user about this point; even if the user marks the mail just for deletion. Mails from strangers are usully "actively not read": You see it and decide not to (really) read it; or to have a loot at it but not really care about it. Mails from strangers are not filtered out on the mailbox server before they reach the MUA. It might help to define an additional X-header which marks the mail as having support signatures so that an IMAP client can notice this without looking at the "attachments". Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Apr 21 19:37:37 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Apr 2014 19:37:37 +0200 Subject: gpg Feature request: merge gpg.exe and gpgsm.exe into one tool In-Reply-To: <53538DF2.2090603@digitalbrains.com> (Peter Lebbing's message of "Sun, 20 Apr 2014 11:05:54 +0200") References: <53538DF2.2090603@digitalbrains.com> Message-ID: <87zjjewplq.fsf@vigenere.g10code.de> On Sun, 20 Apr 2014 11:05, peter at digitalbrains.com said: > directly, and X.509 support for GPGME is something that is being worked on, so > an application that doesn't mind whether it handles OpenPGP messages or CMS > messages can just use the appropriate functions of GPGME. Exactly. However there is much more to it than calling gpgme_set_protocol. S/MIME and PGP/MIME/OpenPGP is quite different in some important details. Changing MUAs to support both is quite some work. I have done that several times over the last decade. The implementation of the actual protocol is entirely different thus consider it still a sound decision to separate the problem domains into two separate processes and some helper processes. > X.509 trust model) seems to be already in the works, and when applications > choose they also want to support that, it might be as easy to support both > OpenPGP and CMS as it is to support just one. I don't know if CMS support in > GPGME is already usable, but it seems much more viable to do a feature Unfortunately this is not the case for one a widely used MUA. CMS support in GPGME is matured for a long time. KMail (and Mutt) was rated fully compatible to all other matured S/MIME implementations except for Outlook which was at that time not compatible to any modern CMS (PKIX) standards. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nico at josuttis.de Tue Apr 22 12:25:04 2014 From: nico at josuttis.de (Nicolai Josuttis) Date: Tue, 22 Apr 2014 12:25:04 +0200 Subject: UI terminology for calculated validities Message-ID: <53564380.10000@josuttis.de> Hi, please allow me to raise an issue I'd like to have harmonized among all web mail frontends using PGP and GPG. The reason I ask is because I am currently adding a feature for auto encryption to enigmail. The question is which terminology shall we use IN FRONTENDS if we use the web of trust and want to signal which keys can be used and which not. According to doc/DETAILS we have the following validity entries: > o = Unknown (this key is new to the system) > i = The key is invalid (e.g. due to a missing self-signature) > d = The key has been disabled > (deprecated - use the 'D' in field 12 instead) > r = The key has been revoked > e = The key has expired > - = Unknown validity (i.e. no value assigned) > q = Undefined validity > '-' and 'q' may safely be treated as the same > value for most purposes > n = The key is valid > m = The key is marginal valid. > f = The key is fully valid > u = The key is ultimately valid. This often means > that the secret key is available, but any key may > be marked as ultimately valid. That means, a key is "valid" if it is not disabled/expired/revoked and has no unknown validity. But everything else is valid. That raises first questions: - What does 'n' exactly stand for (seems to be "less than marginal valid")? Is this accepted if trust-model is "always"? - My understanding is that even with always encrypted is not allowed if the validity is i/d/r/e. Is this correct? Then there is the question how to present this to user-interfaces for non-expert(!) user. Intuitively, people would assume the following terminology: - a key is "valid" if it is not expired, revoked, or disabled. - we should send emails if we "trust a key" (i.e. a key is trusted if the calculated validity is enough to send the email encrypted) Now "trust" for a key (or the associated uid) might be a problem, because we use the term "trust" usually for ownertrust only. But do we? Note that the terminology is even used in the GPG 2.0 manual: > --trust-model always: > Skip key validation and assume that used keys are always fully > trusted. So the next question is: Is "trust a key" a valid term? And if so, which of the calculated validity values fall under it? If "trust a key" is fine I could describe the effect of trust-model always as something like: - "Always trust all keys (except disabled/expired/revoked)" If you don't like the term "trust a key" what else intuitive terminology do you suggest? (note: ideally all mailer should use the same in their UI's) Best Nico -- Nicolai M. Josuttis www.josuttis.de From mailinglisten at hauke-laging.de Tue Apr 22 12:56:52 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 22 Apr 2014 12:56:52 +0200 Subject: UI terminology for calculated validities In-Reply-To: <53564380.10000@josuttis.de> References: <53564380.10000@josuttis.de> Message-ID: <12403760.hMomyj5PjS@inno> Am Di 22.04.2014, 12:25:04 schrieb Nicolai Josuttis: > So the next question is: > Is "trust a key" a valid term? The better question is: "Is it a useful term?" I consider this confusion a huge problem. I guess hardly anyone outside this list get these two concepts right. There is even an OpenPGP GUI which mixes up these two (claims to show trust but shows validity...). Using "trust" for both cases is probably the best way to ensure that normal users will never understand this. I strongly advise against the use of the term "trust" in a validity context. > If you don't like the term "trust a key" what else intuitive > terminology do you suggest? "consider a key as valid" Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nico at josuttis.de Tue Apr 22 13:36:23 2014 From: nico at josuttis.de (Nicolai Josuttis) Date: Tue, 22 Apr 2014 13:36:23 +0200 Subject: UI terminology for calculated validities In-Reply-To: <12403760.hMomyj5PjS@inno> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> Message-ID: <53565437.1070403@josuttis.de> Am 22.04.2014 12:56, Hauke Laging schrieb/wrote: > Am Di 22.04.2014, 12:25:04 schrieb Nicolai Josuttis: > >> So the next question is: Is "trust a key" a valid term? > > The better question is: "Is it a useful term?" > > I consider this confusion a huge problem. I guess hardly anyone > outside this list get these two concepts right. May be, that's a clear sign that the technical terms don't fit well. In the non-technical world you can't just define some terms and expect that people take time to understand them. For this reason, the terms have to be self describing. If if they are not, you need different terminology. > There is even an OpenPGP GUI which mixes up these two (claims to > show trust but shows validity...). > I am asking for "permission" or "acceptance" or at least feedback regarding also to do that. ;-) BTW, which one is it? (remember I want to establish common terminology for GUIs) > Using "trust" for both cases is probably the best way to ensure > that normal users will never understand this. I strongly advise > against the use of the term "trust" in a validity context. > What is so confusing about trust for different thing? One thing is: - Do I trust a person (that he/she signs carefully)? Another thing is: - Do I trust the computed validity of a key? Or in short: Do I trust a key? And s the computed validity is derived from a trust model, it is in effect the answer to the question of whether I can trust a key. And even PGP use the term "trust the key". May be the whole confusion is raised because we constantly you try to use all these technical details when they should be hidden. For anybody sending encrypted emails the whole point is only one question: - Can I trust this key I got so that it is safe to use it? And I can easily explain that using the term "trust" for both: To trust this key, you have to trust the owner that signed it (or trust indirectly marginal trusted owners). That's so simple to explain and I doubt that this is hard to understand (although still hard to remember). And the whole model behind is so hard to explain. Explaining that a key is "valid" if it is "not only valid (expired/revoked/disabled), but also trusted according to the web of trust" is a nightmare. Don't get me wrong. It is important to have this fine grained model behind the scenes. But it is also important to wrap it by something really easy. >> If you don't like the term "trust a key" what else intuitive >> terminology do you suggest? > > "consider a key as valid" > As I said, I need some self-intuitive wording for what technically is "valid". Thanks Nico > > Hauke > -- Nicolai M. Josuttis www.josuttis.de From peter at digitalbrains.com Tue Apr 22 21:57:48 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 22 Apr 2014 21:57:48 +0200 Subject: UI terminology for calculated validities In-Reply-To: <53565437.1070403@josuttis.de> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> Message-ID: <5356C9BC.7040401@digitalbrains.com> Perhaps the novice interface should just stick to "validity" and do away with the whole concept of ownertrust to keep things simple. Suggest that people meet up with someone and sign their key personally if they want validity. Also, I think the word "trust" by itself should probably be avoided everywhere. The word "ownertrust" is uncommon enough that people might be more inclined to look up what it means, instead of thinking they already know what "trust" means. My 2 cents, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From mailinglisten at hauke-laging.de Tue Apr 22 13:56:03 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 22 Apr 2014 13:56:03 +0200 Subject: UI terminology for calculated validities In-Reply-To: <53565437.1070403@josuttis.de> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> Message-ID: <2013842.cKsNLi2euY@inno> Am Di 22.04.2014, 13:36:23 schrieb Nicolai Josuttis: > For this reason, the terms have to be self describing. > If if they are not, you need different terminology. "Self describing" is a hard requirement if the person who shall feel that way is not familiar with the technical concepts. It the concepts are clear then there is no risk of confusion by terms. > BTW, which one is it? Kgpg. Bug report has been made. > What is so confusing about trust for different thing? > And I can easily explain that using the term "trust" for both: > To trust this key, you have to trust the owner that signed it > (or trust indirectly marginal trusted owners). You involuntarily show the next terminology problem: owner trust. This is not about the owner, it is about the key. This can easily be seen from the facts that (a) the same owner can have several keys and (b) there are scenarios in which you will not assign the same trust to these keys. Thus I recommend to call this "certification trust". The owner is an important part of it but not all. Back to your point: The problem is that most people do not learn crypto in a straight, high-quality way. Most people just download the software and see what happens. That you could have explained that well in theory does not change the practice. > That's so simple to explain and I doubt that this is hard to > understand (although still hard to remember). You could say the same about other aspects of crypto. But: That's not the reality we see. > But it is also important to wrap it by something really easy. The subject is not easy. Period. You cannot make it easy by wrapping. The only thing you can achive that way is an illusion of security. > As I said, I need some self-intuitive wording for > what technically is "valid". I am not a native speaker but "valid" seems quite self-intuitive to me. At least about the general idea, not about the technical details, of course. But they will never be self-intuitive, they must be learnt. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Tue Apr 22 23:40:40 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 22 Apr 2014 23:40:40 +0200 Subject: UI terminology for calculated validities In-Reply-To: <2013842.cKsNLi2euY@inno> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> Message-ID: <5356E1D8.9000106@digitalbrains.com> On 22/04/14 13:56, Hauke Laging wrote: > This can easily be seen from the facts that (a) the same owner can have > several keys and (b) there are scenarios in which you will not assign the > same trust to these keys. Oh wow. I understand you can make any topic as difficult as you want if you put some effort into it, but are there seriously people who have different keys for different levels of identity verification? And do they admit they do this because they are sadistic, or is there some way they try to explain this away? Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dkg at fifthhorseman.net Tue Apr 22 23:44:39 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 22 Apr 2014 17:44:39 -0400 Subject: UI terminology for calculated validities In-Reply-To: <5356C9BC.7040401@digitalbrains.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <5356C9BC.7040401@digitalbrains.com> Message-ID: <5356E2C7.2060603@fifthhorseman.net> On 04/22/2014 03:57 PM, Peter Lebbing wrote: > Perhaps the novice interface should just stick to "validity" and do away with > the whole concept of ownertrust to keep things simple. Suggest that people meet > up with someone and sign their key personally if they want validity. > > Also, I think the word "trust" by itself should probably be avoided everywhere. > The word "ownertrust" is uncommon enough that people might be more inclined to > look up what it means, instead of thinking they already know what "trust" means. These proposals from Peter have the merits of simplicity and clarity. I like the idea of starting from this place, and allowing users to dig in deeper if they want to. We could do a much better job of facilitating keysigning to reflect users' beliefs in a robust way as well, whether that's done with non-exportable signatures from hidden signing keys or some other way. This would make Peter's proposal even more usable for the novice user and be convenient for experienced users too. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Apr 22 23:58:58 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 22 Apr 2014 17:58:58 -0400 Subject: UI terminology for calculated validities In-Reply-To: <5356E1D8.9000106@digitalbrains.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> Message-ID: <5356E622.5000001@fifthhorseman.net> On 04/22/2014 05:40 PM, Peter Lebbing wrote: > On 22/04/14 13:56, Hauke Laging wrote: >> This can easily be seen from the facts that (a) the same owner can have >> several keys and (b) there are scenarios in which you will not assign the >> same trust to these keys. > > Oh wow. I understand you can make any topic as difficult as you want if you put > some effort into it, but are there seriously people who have different keys for > different levels of identity verification? And do they admit they do this > because they are sadistic, or is there some way they try to explain this away? I can give an example where i know that the same person holds exclusive access to multiple keys, but i grant different levels of ownertrust to each key. I do this because of the rules of how GnuPG interprets signatures in the WoT, not because the keyholder has any different policy about the two different keys: My friend X does a decent job at checking identities. I wouldn't want to rely on X's certifications directly, but i consider them useful as corroboration from other friends. X has an 8-year-old 1024-bit DSA key (key "A") that has collected a lot of certifications, and X is attached to it. X also has a 2-year old 4096-bit RSA key (key "B") that doesn't have as many certifications. both A and B are in active use, because X is trying to transition from A to B, but hasn't completed the transition. My intent is to grant "marginal" ownertrust to X, meaning that i'm willing to consider a (key,uid) pairing as valid if it has certifications from X and at least two other marginally-trusted friends. If i grant "marginal" ownertrust to both A and B, then X only needs one other friend to collaborate to get my gnupg implementation to accept certificates that i'm not intending to accept. X might even be in the habit of certifying keys with both A and B (this would be reasonable for as long as X is actively using A and B, since some of X's peers might know about and rely on certifications from A only, and some might know and rely on B only). I actually know several people who meet X's description (the pool of debian developers is moving from older, weaker keys to stronger keys). So, my current policy for dealing with this for people like X is that i set "no ownertrust" on A, and "marginal ownertrust" on B; i also explain to them that if they want to make a certification that i can rely on, they should make it with their newer, stronger key. if GPG was closer to a contact manager, its implementation of ownertrust could be made more sophisticated, to address this situation, by having an abstract concept of "peers" where each peer could have an arbitrary number of keys. You could even approximate something like this by matching User IDs and discounting cumulative marginal ownertrust if the two certifications come from keys that are each bound to the same User ID. I'm not suggesting that we make these changes right now to the gpg WoT caluculation model, because i think there is more important work to be tackled first, though. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Apr 23 00:11:22 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 23 Apr 2014 00:11:22 +0200 Subject: UI terminology for calculated validities In-Reply-To: <5356E622.5000001@fifthhorseman.net> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> Message-ID: <5356E90A.90600@digitalbrains.com> On 22/04/14 23:58, Daniel Kahn Gillmor wrote: > If i grant "marginal" ownertrust to both A and B, then X only needs one > other friend to collaborate to get my gnupg implementation to accept > certificates that i'm not intending to accept. I might have snipped my quote too much. Hauke was arguing that the term "ownertrust" is not correct because it is not about trust in the owner, but trust in specific keys. In your example, you do not trust the two keys differently[1]. However, due to a technicality, you can't assign both the same ownertrust, because they would add up. I don't think this is a fundamental thing that changes the concept of ownertrust, it is an unfortunate technicality. If GnuPG were somehow enhanced that you could mark them as "this is the same person", you would assign both "marginal" and benefit from certifications of either key. If it's that easily fixed, it's not a fundamental issue in my book. Peter. [1] Although you might mistrust a key that's no longer considered secure by current cracking standards. Again, not an issue with trust in the owner, but a technicality. --- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From nico at josuttis.de Wed Apr 23 00:22:01 2014 From: nico at josuttis.de (Nicolai Josuttis) Date: Wed, 23 Apr 2014 00:22:01 +0200 Subject: technical question: effect of trust-model always and what validity 'n' means Message-ID: <5356EB89.1080704@josuttis.de> Before we continue to discuss "trust" and "valid", allow me again to raise some technical questions regarding GPG options and values, which I at least didn't understand by reading docs and (roughly) source code (but I need a clear understanding to program a frontend on it). a) What is the effect of --trust-model always in detail? Does it mean that when sending emails the calculated validity is completely ignored (so that even 'e' and 'r' count as "valid") or does it "only" mean that '-', 'q', and 'm' count as valid as 'f' does with the default trust models? b) What does the calculated validity 'n' means and when is it created? - doc/DETAILS says: n = The key is valid - the GPG manual says: n Never trust this key. - In the source code, it seems to be created in combination with GPG_ERR_NOT_TRUSTED: > else if (gpg_err_code (rc) == GPG_ERR_NOT_TRUSTED) > *truststring = 'n'; /* No, we do not trust this one. */ c) IF 'n' means "never trust this key", why is it "higher rated" than unknown? What I mean is: In code and doc there is always the following order: > case TRUST_UNDEFINED: min_num=1; break; > case TRUST_NEVER: min_num=2; break; > case TRUST_MARGINAL: min_num=3; break; > case TRUST_FULLY: min_num=4; break; or: > - = Unknown validity (i.e. no value assigned) > q = Undefined validity > n = The key is valid > m = The key is marginal valid. > f = The key is fully valid > u = The key is ultimately valid. This leads to the impression that the order is from minimal to maximal trust. However, that's not how I would sort it. For me not knowing whether I can trust is better than knowing that I can not trust. Thus, IMO, the order should be n -/q m f u Am I missing something? -- Nico From dkg at fifthhorseman.net Wed Apr 23 00:38:36 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 22 Apr 2014 18:38:36 -0400 Subject: UI terminology for calculated validities In-Reply-To: <5356E90A.90600@digitalbrains.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> Message-ID: <5356EF6C.30201@fifthhorseman.net> On 04/22/2014 06:11 PM, Peter Lebbing wrote: > In your example, you do not trust the two keys differently[1]. However, due to a > technicality, you can't assign both the same ownertrust, because they would add > up. I don't think this is a fundamental thing that changes the concept of > ownertrust, it is an unfortunate technicality. If GnuPG were somehow enhanced > that you could mark them as "this is the same person", you would assign both > "marginal" and benefit from certifications of either key. If it's that easily > fixed, it's not a fundamental issue in my book. > > Peter. > > [1] Although you might mistrust a key that's no longer considered secure by > current cracking standards. Again, not an issue with trust in the owner, but a > technicality. I understand your argument, and i agree that this reflects a technical weakness in the GnuPG cryptographic certification mechanism based on what it knows about keys, and how it makes validity calculations. Did you see my two proposals at the end of my note about ways it could be improved if anyone has time and effort to put into it? the "same owner if both assert the same user ID" fix might be the least-fiddly one, which would catch a large fraction of the cases in question. But it still wouldn't cover circumstances where you know someone who has a "work key" and a "home key" where the User IDs are disjoint. What would you think about work key/home key distinctions? what if the work key was stored on a machine administered by the local sysadmin? Adding in a separate "person" concept to the gpg keystore seems much more fiddly and complex in terms of UI/UX, unless gpg is willing to commit to being a full contact manager (which i don't think it necessarily should be). So anyway, i think i generally agree with you that the concept itself should stay at "ownertrust", though i do have some concerns about the work/home split, where i can imagine different levels of care taken by the same person in different contexts (perhaps by enforced workplace policy, even). thanks for the discussion, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Wed Apr 23 00:49:37 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 23 Apr 2014 00:49:37 +0200 Subject: UI terminology for calculated validities In-Reply-To: <5356E1D8.9000106@digitalbrains.com> References: <53564380.10000@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> Message-ID: <3070206.M9fFJ1Pur0@inno> Am Di 22.04.2014, 23:40:40 schrieb Peter Lebbing: > Oh wow. I understand you can make any topic as difficult as you want > if you put some effort into it, We do agree that crypto is by its nature difficult (I don't mean the math I mean the organizational envorinment) and that a serious part of this difficulty is more or less hidden by current tools (in order not to scare the users away), don't we? > but are there seriously people who > have different keys for different levels of identity verification? The answer seems to point to the wrong direction as, of course, having only one (active) key (per address) which is probably the situation for the majority of OpenPGP users, is just another problem as you cannot cover the spectrum of common security needs with just one key. You can even see that on this list where several people do not sign their email. In at least one case due to the rather strange argument that this would imply a higher "security" of the message than it really has. The reality is that this ignores the real problem: The lack of transparency of the security level (German only: http://www.crypto-fuer-alle.de/wishlist/securitylevel/). Thus we should head for most users having several keys. But as dkg has just pointed out (his suggestion to handle groups of keys belonging to the same person or organization has already been on this list years ago): We are technically not yet equipped for handling this. On the other hand: The current WoT is of little use anyway. But if this is supposed to change in e.g. five years we have to start to change something now. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nico at josuttis.de Wed Apr 23 00:50:24 2014 From: nico at josuttis.de (Nicolai Josuttis) Date: Wed, 23 Apr 2014 00:50:24 +0200 Subject: UI terminology for calculated validities In-Reply-To: <5356E90A.90600@digitalbrains.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> Message-ID: <5356F230.3010608@josuttis.de> First, thanks to all for helping to clarify the issue (for me) Here is an example of a real world novice problem based on the current terminology and what we discuss (a real example from today): In enigmail a user enabled the option "trust_model always" (it's currently named there as "Always trust people's keys" ;-) ). When I asked why, the user told me: If I don't do that, I always get error messages. So the dialog between me and the user ("he") continued roughly as follows: me: so the keys are missing he: no, I downloaded them from keyserver xy me: oh, but you need trust for the keys (meaning they have to be valid) he: yes, it works if I assign ultimate trust to the key (he meant the owner) me: no, no, don#t do that. ultimate is if you created the key he: so what? me: you either can sign the key or trust somebody else who signed the key (such as pgpca at ct.heise.de) he: Oh, I even registered my email/key there but what else is missing? me: load the key for pgpca at ct.heise.de he: done, but trust is still missing me: oh, yes, you also have to express trust for this key/owner Then it worked ... That's a summary of learning step by step what has to be done to benefit from the web-of-trust (and BTW "he" was even an IT guy). BTW, the dialog would have been different if I would have used "valid" instead of "trusted". E.g. as follows: me: oh, but you need valid(!) keys he: but they are! Look, neither expired or revoked! me: no, no, valid in the sense that you can trust them he ah, I need to trust the keys ... The essence, we have to teach is: - create a key - and then either - exchange the key - and sign then key you got (after validating the fingerprint) or - load the key for pgpca at ct.heise.de or other central "trust agencies" - AND express trust for that key/owner Thus, I am really surprised that you suggest to teach "validity" instead of "trust". And I agree that "owner" make things unnecessary complicated. I am more and more convinced that we simply always should talk about trust: - If I trust the key/owner that/who signs other keys, I can trust these keys and safely use them Note that although we can skip the term "owner" we need the term trust, because without trusting any owner the trust model doesn't work. Am 23.04.2014 00:11, Peter Lebbing schrieb/wrote: > On 22/04/14 23:58, Daniel Kahn Gillmor wrote: >> If i grant "marginal" ownertrust to both A and B, then X only needs one >> other friend to collaborate to get my gnupg implementation to accept >> certificates that i'm not intending to accept. > > I might have snipped my quote too much. Hauke was arguing that the term > "ownertrust" is not correct because it is not about trust in the owner, but > trust in specific keys. > > In your example, you do not trust the two keys differently[1]. However, due to a > technicality, you can't assign both the same ownertrust, because they would add > up. I don't think this is a fundamental thing that changes the concept of > ownertrust, it is an unfortunate technicality. If GnuPG were somehow enhanced > that you could mark them as "this is the same person", you would assign both > "marginal" and benefit from certifications of either key. If it's that easily > fixed, it's not a fundamental issue in my book. > > Peter. > > [1] Although you might mistrust a key that's no longer considered secure by > current cracking standards. Again, not an issue with trust in the owner, but a > technicality. > > --- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -- Nicolai M. Josuttis www.josuttis.de From rjh at sixdemonbag.org Wed Apr 23 00:56:58 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 22 Apr 2014 18:56:58 -0400 Subject: UI terminology for calculated validities In-Reply-To: <5356E1D8.9000106@digitalbrains.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> Message-ID: <5356F3BA.9060507@sixdemonbag.org> > Oh wow. I understand you can make any topic as difficult as you want > if you put some effort into it, but are there seriously people who > have different keys for different levels of identity verification? > And do they admit they do this because they are sadistic, or is there > some way they try to explain this away? I can see it, actually. Let's say that I have a certificate for personal use, and a separate one for corporate use where the private part is escrowed with the firm. You might trust signatures from my personal cert but not from the corporate cert, due to your concerns over my corporate masters being able to impersonate me at-will. From mailinglisten at hauke-laging.de Wed Apr 23 01:03:05 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 23 Apr 2014 01:03:05 +0200 Subject: UI terminology for calculated validities In-Reply-To: <5356F230.3010608@josuttis.de> References: <53564380.10000@josuttis.de> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> Message-ID: <233065256.1ecAcXsO30@inno> Am Mi 23.04.2014, 00:50:24 schrieb Nicolai Josuttis: > In enigmail a user enabled the option "trust_model always" > (it's currently named there as "Always trust people's keys" ;-) ). "A user"? LOL The developers did. This is the default setting (hidden in the experts settings and "hidden" by not showing the key validity by default; OK, by default they don't show any keys at all so why bother...). IMHO an absolutely crazy decision. The worst possible organizational failure. And the MacOS GPGTools don't show you the fingerprint when certifying a key. That's where mainstream crypto software is going currently. Welcome to the world of easy crypto... Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nico at josuttis.de Wed Apr 23 01:18:01 2014 From: nico at josuttis.de (Nicolai Josuttis) Date: Wed, 23 Apr 2014 01:18:01 +0200 Subject: UI terminology for calculated validities In-Reply-To: <233065256.1ecAcXsO30@inno> References: <53564380.10000@josuttis.de> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <233065256.1ecAcXsO30@inno> Message-ID: <5356F8A9.2010707@josuttis.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This discussion is part of my trial to make things better (but now I know why I also had it turned on ;-) ). We can change that easily BUT we MUST AVOID to FRUSTRATE first-time-users. I was also thinking about a general non-expert option, switching between safe and unsafe mode. (The unsafe mode is very important to send more encrypted emails to help those who really need encryption). Am 23.04.2014 01:03, Hauke Laging schrieb/wrote: > Am Mi 23.04.2014, 00:50:24 schrieb Nicolai Josuttis: > >> In enigmail a user enabled the option "trust_model always" (it's >> currently named there as "Always trust people's keys" ;-) ). > > "A user"? LOL > > The developers did. This is the default setting (hidden in the > experts settings and "hidden" by not showing the key validity by > default; OK, by default they don't show any keys at all so why > bother...). IMHO an absolutely crazy decision. The worst possible > organizational failure. And the MacOS GPGTools don't show you the > fingerprint when certifying a key. That's where mainstream crypto > software is going currently. Welcome to the world of easy > crypto... > > > Hauke > - -- Nicolai M. Josuttis www.josuttis.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTVvioAAoJEN75/ICKHETQVYYQAKQH9FVLx0gWumzCXXw7KwYn ASSM6uYsDV0QLVlwOE3WPOvlWbgB/g8J9YIjNpKqub1o+b1QdwNPcZldIIIawrZs JELhFsi9ba7khVQ5kf+HNUPGf7olWBGWVYa5IG1beZzfMZic4EIvMN2QdgUkdT3D LEKxPfAO1+t759MtFf+tc86hxBNB8+eGZgG4f4gp4fDO8+DGro9ZQwoufSoRWDwg X8I/M3+DgkGM0Zj7dlvXSz2//S5I5BoI8Y+v0V81MgYWs8S5bhqC8qCyb/JnfFyw kJvXLsIm8c2bfHOib3k9NfA8ZRwNwSWjvYwo077YTGsz4ORw/rqZvjQFKNNRQxoC PtXcJC8Tl9JVuWWt2/0kgWAzWkkx622WgkCcnMzKsW0d9Ng5cAFHmb+LxjAV3/01 nTrDiaOP35nvhaV4Bi92WmPveFmNZnI4WLDPrjqS8ZvbuvI5lotVjwAfcl5pTOxv I5wR7fjO0LkEjjVtrwEUme4vONqsR54Fl3sJcctfyyyrZHLcZ4pkw9Ksy0MUvd7x dz8GWJC3Av5rS5vNIJZa9JcBzJLkd4EgikbyxLZfTbEbTRTMAzH2j3x/wnQewkYg udwaMwwAdXPSn/C3NfK0mYb1uzXM9HPOUqfn46jLDYclM/beLTVficbecqxx0bKk whpIE0zGBTy7G3Uzgs0f =vljo -----END PGP SIGNATURE----- From peter at digitalbrains.com Wed Apr 23 11:23:01 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 23 Apr 2014 11:23:01 +0200 Subject: UI terminology for calculated validities In-Reply-To: <5356F3BA.9060507@sixdemonbag.org> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356F3BA.9060507@sixdemonbag.org> Message-ID: <53578675.80903@digitalbrains.com> On 23/04/14 00:56, Robert J. Hansen wrote: > I can see it, actually. Yes, after dkg's last message yesterday I also realised I had overlooked that scenario. I think it can be generalised as "different roles", as even the verification effort / signing policy can be different. Your boss might expect you to sign certain keys with your work key while you are much more stringent with your personal key. But I don't see why we need to drop the term ownertrust for that. Sometimes you need to pick a descriptive identifier for something and then define what it exactly means; it happens all the time in science. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From p.h.delgado at xoxy.net Wed Apr 23 10:08:52 2014 From: p.h.delgado at xoxy.net (p.h.delgado at xoxy.net) Date: Wed, 23 Apr 2014 08:08:52 +0000 Subject: UI terminology for calculated validities In-Reply-To: <3070206.M9fFJ1Pur0@inno> References: <53564380.10000@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <3070206.M9fFJ1Pur0@inno> Message-ID: <53577514.6020307@mail.ru> On 04/22/2014 10:49 PM, Hauke Laging wrote: > We do agree that crypto is by its nature difficult... I agree, but I believe the statement should be more specific, i.e.,: ...Web-of-Trust is by its nature difficult... If I can propose a "we do agree" statement, it would be the following: *We do agree that the WoT is the principal obstacle to a wider adoption of GnuPG.* (What we might or might not agree on is whether GPG without the WoT is still GPG: an indispensable communication security tool, one of the best around) If the complex structure of the beast is not reasonably well understood by the user, it is of little value to the novice. There is nothing that the user interface skin can cover it with, that can, IMHO, change that fact. Struggling with the physiology consisting of large number of arcane rules, with no understanding of the full anatomy of the underlying system is a path to endless frustration and a source of frequent critical usage errors. There are two kinds of circumstances where new users are motivated to use the tool: communication with parties that the user has had prior familiarity with, and those where the first and only contact is via GPG generated cypher-text. New users that belong to the first kind above should be given an option of completely ditching the whole WoT superstructure in favour of the independent procurement of the key fingerprint, and should be explained how to go about the key verification using the trusted fingerprint, and provided with the UI devices that make this as simple as possible. No WoT functionality whatsoever should be exposed to the user. I strongly believe that a wast majority of present and prospective GPG users with the "real world" threat model would be well served by this approach. delgado From peter at digitalbrains.com Wed Apr 23 11:51:02 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 23 Apr 2014 11:51:02 +0200 Subject: UI terminology for calculated validities In-Reply-To: <3070206.M9fFJ1Pur0@inno> References: <53564380.10000@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <3070206.M9fFJ1Pur0@inno> Message-ID: <53578D06.4090206@digitalbrains.com> On 23/04/14 00:49, Hauke Laging wrote: > We do agree that crypto is by its nature difficult (I don't mean the math I > mean the organizational envorinment) and that a serious part of this > difficulty is more or less hidden by current tools (in order not to scare > the users away), don't we? We agree on the first point, crypto is by its nature difficult. Which is /precisely/ why you shouldn't make it more difficult than necessary. On the latter point: I think the user interfaces can be made better, but I disagree with your description of that. We do agree to disagree, don't we? > Thus we should head for most users having several keys. That's how you want to improve the user interface for, I quote, the "non-expert(!) user"? In that case we disagree about the right way to do this on such a fundamental level that I don't think we're going to come to common ground. Also, I think this discussion would benefit from a narrower scope. Let's focus on terminology and user interface elements with the current mechanics, and leave things like "the lack of transparency of the security level" to other threads. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed Apr 23 11:56:17 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 23 Apr 2014 11:56:17 +0200 Subject: UI terminology for calculated validities In-Reply-To: <53577514.6020307@mail.ru> References: <53564380.10000@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <3070206.M9fFJ1Pur0@inno> <53577514.6020307@mail.ru> Message-ID: <53578E41.3090802@digitalbrains.com> On 23/04/14 10:08, p.h.delgado at xoxy.net wrote: > *We do agree that the WoT is the principal obstacle to a > wider adoption of GnuPG.* Only a few days ago, a list of literature on the subject was posted to this mailing list. I propose we keep the scope of this discussion narrower, and not touch the subject of adoption of crypto. I fear the discussion will quickly go nowhere otherwise. Let's stick to improving user interfaces for novice users so they use them reasonably correctly. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed Apr 23 12:36:41 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 23 Apr 2014 12:36:41 +0200 Subject: UI terminology for calculated validities In-Reply-To: <53577514.6020307@mail.ru> References: <53564380.10000@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <3070206.M9fFJ1Pur0@inno> <53577514.6020307@mail.ru> Message-ID: <535797B9.2050203@digitalbrains.com> On 23/04/14 10:08, p.h.delgado at xoxy.net wrote: > New users that belong to the first kind above should be > given an option of completely ditching the whole WoT > superstructure in favour of the independent procurement > of the key fingerprint Yes, I think the experience for novice users would be improved if you guide them towards signing keys directly. Ownertrust, the WoT, being hidden for novice users might take away enough complexity that you can explain to the novice that the way to secure communications with someone is meeting up with them, verifying the fingerprint and making a signature. I think the word "validity" is still fine for that. I don't think it's difficult to convey that a key won't be valid until you validated it yourself with the owner by checking the fingerprint. A key that is expired or revoked might be called "unusable" if it needs a stronger term than simply "invalid". This need not be imposed as the default mode: you could ask on first use which "mode" the user desires, giving a short explanation about the strengths and weaknesses of different modes, and possibly referring to documentation on-line. There could be a version of the documentation that completely ignores the WoT and simply focusses on direct signatures. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dkg at fifthhorseman.net Wed Apr 23 15:24:45 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 23 Apr 2014 09:24:45 -0400 Subject: UI terminology for calculated validities In-Reply-To: <53578675.80903@digitalbrains.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356F3BA.9060507@sixdemonbag.org> <53578675.80903@digitalbrains.com> Message-ID: <5357BF1D.2090400@fifthhorseman.net> On 04/23/2014 05:23 AM, Peter Lebbing wrote: > On 23/04/14 00:56, Robert J. Hansen wrote: >> I can see it, actually. > > Yes, after dkg's last message yesterday I also realised I had overlooked that > scenario. I think it can be generalised as "different roles", as even the > verification effort / signing policy can be different. Your boss might expect > you to sign certain keys with your work key while you are much more stringent > with your personal key. or vice versa, actually. You might think someone is personally inclined towards sloppiness, but will obey the rules of an organization they're part of, and that organization might have stricter criteria for making certifications with keys associated with the org. > But I don't see why we need to drop the term ownertrust for that. Sometimes you > need to pick a descriptive identifier for something and then define what it > exactly means; it happens all the time in science. I agree with this; also, the reason that your willingness to rely on one key or the other are associated with who you think really "owns" the key. even if an individual holds both keys, if the organization can exert control over the use of one of them, there's a sense in which the "ownership" of that key is different. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From gpg at mdsresource.net Wed Apr 23 21:24:36 2014 From: gpg at mdsresource.net (helices) Date: Wed, 23 Apr 2014 14:24:36 -0500 Subject: GPG cannot import public key Message-ID: GPG version trying to import: gpg (GnuPG) 2.0.14 Header from shared armored public key: Version: Encryption Desktop 10.3.0 (Build 8741) GPG error on import: # gpg --import /tmp/imps.asc gpg: key 845F5188: no valid user IDs gpg: this may be caused by a missing self-signature gpg: Total number processed: 1 gpg: w/o user IDs: 1 Other GPG import: # gpg --allow-non-selfsigned-uid --import /tmp/imps.asc gpg: key 845F5188: accepted non self-signed user ID "Concerto Support Key < concerto.support at impact-ps.com>" gpg: key 845F5188: public key "Concerto Support Key < concerto.support at impact-ps.com>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) Then: # gpg --list-keys 845F5188 pub 0s/845F5188 2013-03-05 uid Concerto Support Key # gpg --edit-key 845F5188 gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub 0s/845F5188 created: 2013-03-05 expires: never usage: SC trust: unknown validity: unknown [ unknown] (1). Concerto Support Key Command> sign User ID "Concerto Support Key " is not self-signed. Unable to sign. Nothing to sign with key 31A070A8 No matter how I try, I cannot encrypt a file using that public key, even using --edit-key to assign trust: gpg: 845F5188: skipped: Unusable public key gpg: /tmp/test.txt: encryption failed: Unusable public key The owner of the public key insists that it is self-signed; but, our GPG cannot find the self-signature What am I missing? Please, advise. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabriel.niebler at gmail.com Wed Apr 23 23:00:41 2014 From: gabriel.niebler at gmail.com (Gabriel Niebler) Date: Wed, 23 Apr 2014 23:00:41 +0200 Subject: UI terminology for calculated validities In-Reply-To: <5356F230.3010608@josuttis.de> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> Message-ID: <535829F9.1010503@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 tl;dr: "validity" is confusing, please consider using "ownership" or "authenticity" for same concept. Dear all, it seems to me that the problem here is mainly one of semantics. The technical concepts are clear to everyone involved, the question is how to name and explain them so they can be readily understood - especially by novices and non-technical users. To this end, I would like to add two points: 1) I believe that the word "validity" is a poor choice for how it is used at present (i.e. the assignment of faith in the identity of the key's purported owner), because it gets people thinking along the wrong lines. The average layperson already has a concept of "validity" from such things as credit cards ("valid thru"), mass transit tickets ("not valid unless stamped") and passports ("valid from ... until ...", also made invalid when one gets a new one). These pre-existing notions, which are impossible to rub out, naturally translate to _expiration_ and _revocation_ of keys, NOT to the question who the key really belongs to. Technically inclined people have a second association with the word "valid", more akin to "well-formed" ("is this valid XML?"), which naturally translates to whether e.g. a given version and implementation of OpenPGP can understand a given key etc. and, again, does NOT translate to the question of the key holder's true identity. Hence the confusion. What makes it worse is that in the above examples, i.e. the cases people are familiar with, validity can usually be determined from the document itself (here that would be the key), or at worst the system that works with the document (here that would be GnuPG), but neither is the case with key ownership. Instead, it is a determination only the user can make (possibly through intermediaries, with the WoT). Simply put, the word "validity" already means something to most people, but it was taken and redefined to mean something else in the context of asymmetric encryption keys - it's a bit like making a calculator and using the '+' sign for multiplication: it will do the correct thing and it's all in the manual, but it's still horribly confusing. Therefore, I propose that the word "validity" is not chosen well for what it now means in GnuPG, because it carries with it connotations that are quite different from the intended meaning, which is confusing. And thus a better, clearer word should be found and used in future. Which word is obviously a matter for debate. 2) There are words that are already used to describe the right sort of relation between an object and a person, or between a document and an identity, and thus convey the right sort of meaning. The two best examples that came to my mind (so far) are: a) "ownership" and b) "authenticity". Ad (a): A user wants to know whether the key they obtained is really _owned_ by the person whose UserID(s) came with it. Instead of saying the UserID is "invalid", the UI may warn that the UserID's "ownership" is unconfirmed/has not been confirmed and may even say "this UserID could be (a) fake". A GUI button could read "Sign to confirm ownership" and open a dialogue that further asks "Are you (reasonably) sure/certain/confident that the key with fingerprint ... belongs to ?" and then maybe have a link "How do I check this?" to some explanatory text, below. GnuPG options could be renamed "show-uid-ownership". Ad (b): A user wants to know whether a key is authentic, i.e. the identity of the person it belongs to is that given in the UserID(s). Instead of saying the key is "invalid", the UI may warn that its "authenticity" is unknown/unconfirmed or that the key is "possibly FAKE". A GUI button could read "Sign to authenticate" and open a dialogue like above. GnuPG options could be renamed "show-uid-authenticity". This language is very similar to the one we use for passports, ID cards etc. and I believe this is a good thing, because the understanding carries over: My government issued passport is authentic and I own it, because it's really me on the picture and that's my name and there's my date of birth and these things can be checked, if needs be. But it may well be invalid, because it expired or I got issued a new one and they punched a hole through my old document. Likewise, my key is authentic and I own it, because that's my name and email address in the UserID and this can be checked by anyone who knows me with the help of my fingerprint. But it may well be invalid, because it expired or I revoked it. A fake or stolen passport OTOH is valid, near as anyone can tell, based on the expiration date printed in it, but if it's fake it's not authentic and if it's stolen then the person carrying it is not the owner. Likewise, a fake or "stolen" (copied) key is still valid, as long as it hasn't expired or been revoked, but if it's fake it's not authentic, and if it's been stolen then the person I'm talking to may not be the owner. The customs agent at the border checks both validity and ownership/authenticity and so do we with UserIDs on keys. Validity, in the sense of expiration and revocation status, can be checked more or less automatically with the help of key servers (just like the expiration date can be read by machine with with OCR or RFID), but ownership/authenticity must be checked manually (or by WoT) If you've made it this far, please also note that the word "trust" was completely avoided in the above wall of text. No collision of meaning with the WoT's concept of ownertrust. Faithfully Yours gabe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWCnrAAoJEO7XEikU4kSzoVAH/2623vUp7YBddv96I6lrZTcT NL647wYE2nSrOf5Tt+NBedCRk/KfHphv5Zt1oEHU5AVTqMyi7zCAEGkcfJcXGI4W 7RhPlv5O0lALMwrPpuOVWLnYuF8tI70BuRqdFaTEzL9tMHmxv1y/aEcINVuTBsvM 9DWng4hvqjIQP9bNSl+8J0SEmYPx/bsn5Ci6DyuRXmIHmJipB1MQtO6ah5v5jdbq ufOUQTf8dhBVTkQ+GyczovI4vAVFFO2Qdceqcvs3p4YgwZ9ZNq4Z6KpxB3Sa7znC IFyJp+JqsPdMMgi3E/V67vzOcuutj0gY7faeqg57gur8owEAiobHGZX2LbkU9nQ= =VcrW -----END PGP SIGNATURE----- From tim at piratemail.se Thu Apr 24 00:13:15 2014 From: tim at piratemail.se (tim at piratemail.se) Date: Wed, 23 Apr 2014 18:13:15 -0400 (EDT) Subject: best practice for pgp mail service, revoking keys Message-ID: <0a33252a-4a50-4dd8-1850-084186b21f3d@piratemail.se> Greetings, This is a tiny bit philosophical. Perhaps a little off-topic. I think this is probably the best list to ask never-the-less. So I've been working on this pgp base web based mail service. https://github.com/timprepscius/mv Here is the problem I hope eventually to be confronted with: 1. User registers name "decker at piratemail.se," user auto-magically generates a pgp pub/priv key. The pub key is registered on the pgp key servers. 2. User goes away. Account is closed. 3. User still has "decker at piratemail.se" registered on the pgp key servers. 4. Another person wants to use "decker at piratemail.se." He would generate a brand new pgp key with a later creation date, but still that old one seems like a liability. What should I do? A few options I can see: 1. email addresses are used only once. 2. email addresses are used more than once, but with a warning, "there already exists an unrevoked pgp key for this address." 3. user gives me a revocation certification when he generates his pgp key, I can revoke accounts which close. 4. user generates pgp keys which expire after a year 5. ? I would like to do #3. But perhaps this is not the way to go. I'm not sure if #4 is possible with the javascript pgp lib I'm using atm. Any thoughts? Cheers, -tim From dshaw at jabberwocky.com Thu Apr 24 05:14:24 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 23 Apr 2014 23:14:24 -0400 Subject: best practice for pgp mail service, revoking keys In-Reply-To: <0a33252a-4a50-4dd8-1850-084186b21f3d@piratemail.se> References: <0a33252a-4a50-4dd8-1850-084186b21f3d@piratemail.se> Message-ID: <9AD9E4DA-FD95-47AE-B799-42B8E44ECBEF@jabberwocky.com> On Apr 23, 2014, at 6:13 PM, tim at piratemail.se wrote: > Greetings, > > This is a tiny bit philosophical. Perhaps a little off-topic. I think this is probably the best list to ask never-the-less. > > So I've been working on this pgp base web based mail service. > https://github.com/timprepscius/mv > > Here is the problem I hope eventually to be confronted with: > > 1. User registers name "decker at piratemail.se," user auto-magically generates a pgp pub/priv key. The pub key is registered on the pgp key servers. > 2. User goes away. Account is closed. > 3. User still has "decker at piratemail.se" registered on the pgp key servers. > 4. Another person wants to use "decker at piratemail.se." He would generate a brand new pgp key with a later creation date, but still that old one seems like a liability. > > What should I do? > > A few options I can see: > 1. email addresses are used only once. > 2. email addresses are used more than once, but with a warning, "there already exists an unrevoked pgp key for this address." > 3. user gives me a revocation certification when he generates his pgp key, I can revoke accounts which close. > 4. user generates pgp keys which expire after a year > 5. ? I haven't looked extensively at your design, so this isn't a suggestion as to what you should do, but just to mention a possibility you may have missed: 5. User appoints you (or a designated key) as their designated revoker. This allows your key to issue a revocation on their key. Pro: no need to store revocation certificates for all of your users, which could leak. Con: the revocation only works if the person checking has both your key and their key. It's similar in many ways to 3. David From dshaw at jabberwocky.com Thu Apr 24 05:14:25 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 23 Apr 2014 23:14:25 -0400 Subject: GPG cannot import public key In-Reply-To: References: Message-ID: On Apr 23, 2014, at 3:24 PM, helices wrote: > No matter how I try, I cannot encrypt a file using that public key, even using --edit-key to assign trust: > > gpg: 845F5188: skipped: Unusable public key > > gpg: /tmp/test.txt: encryption failed: Unusable public key > > > The owner of the public key insists that it is self-signed; but, our GPG cannot find the self-signature It doesn't look like it's self-signed, but without looking at the key itself, I couldn't say for sure. Is it posted anywhere on the net? In any event, you can override the check for encryption with the same flag you used to override the check on import. So: gpg -r 845F5188 --allow-non-selfsigned-uid -e the-file-i-am-encrypting-etc.txt David From dshaw at jabberwocky.com Thu Apr 24 05:25:10 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 23 Apr 2014 23:25:10 -0400 Subject: GPG cannot import public key In-Reply-To: References: Message-ID: <030B5D79-04C4-480D-9063-72CEBF928FAC@jabberwocky.com> On Apr 23, 2014, at 11:14 PM, David Shaw wrote: > On Apr 23, 2014, at 3:24 PM, helices wrote: > >> No matter how I try, I cannot encrypt a file using that public key, even using --edit-key to assign trust: >> >> gpg: 845F5188: skipped: Unusable public key >> >> gpg: /tmp/test.txt: encryption failed: Unusable public key >> >> >> The owner of the public key insists that it is self-signed; but, our GPG cannot find the self-signature > > It doesn't look like it's self-signed, but without looking at the key itself, I couldn't say for sure. Is it posted anywhere on the net? > > In any event, you can override the check for encryption with the same flag you used to override the check on import. So: > > gpg -r 845F5188 --allow-non-selfsigned-uid -e the-file-i-am-encrypting-etc.txt I should add, though, that overriding these checks is something you should do with suitable verification of the key. Don't override the check unless you know what you're doing, and have assured yourself that the key you are encrypting to is really owned by the person/group that you believe it is. Those checks are there for a reason. David From 2014-667rhzu3dc-lists-groups at riseup.net Wed Apr 23 21:32:27 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 23 Apr 2014 20:32:27 +0100 Subject: UI terminology for calculated validities In-Reply-To: <5356EF6C.30201@fifthhorseman.net> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356EF6C.30201@fifthhorseman.net> Message-ID: <1132800573.20140423203227@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 NotDashEscaped: You need GnuPG to verify this message Hi On Tuesday 22 April 2014 at 11:38:36 PM, in , Daniel Kahn Gillmor wrote: > Did you see my two proposals at the end > of my note about ways it could be improved if anyone > has time and effort to put into it? the "same owner if > both assert the same user ID" fix might be the > least-fiddly one, which would catch a large fraction of > the cases in question. Would it be feasible to have a signature notation for use when signing other keys you own, that could potentially be parsed by GnuPG? It would have to be reciprocal to prevent abuse. Say a user has two keys, 0x0123456789abcdef and 0xfedcba9876543210. I propose each key could sign the other with a signature notation something like:- siblings-0x0123456789abcdef-0xfedcba9876543210 at example.org. If there were more than two keys it could be extended, or maybe each pair would have to cross-sign. When GnuPG encountered "siblings" from the same set that had cross-signatures with this notation, the "family" could be counted only once in trust calculations. -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Did you hear? They took the word gullible out of the dictionary -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNYFV5XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pqfUEAIrOAus4esvo6/Jo3XGZEQPDAZEPxHQYn3K3 s9uf6WACvJP3Uheql5A3E3PK26R6W55xXZ88hC5bcDChuUC2sApujrE0Rkm8NNsi mwjn4tPpuYTJviGZelbwkghh/6O6AEbRjIoS6fH9daFC6b/FFvAAQ3ILfVaf7ajS YP5vqY3F =Jr/G -----END PGP SIGNATURE----- From mike at mdsresource.net Wed Apr 23 20:11:44 2014 From: mike at mdsresource.net (Mike Schleif) Date: Wed, 23 Apr 2014 13:11:44 -0500 Subject: GPG cannot import public key Message-ID: GPG version trying to import: gpg (GnuPG) 2.0.14 Header from shared armored public key: Version: Encryption Desktop 10.3.0 (Build 8741) GPG error on import: # gpg --import /tmp/imps.asc gpg: key 845F5188: no valid user IDs gpg: this may be caused by a missing self-signature gpg: Total number processed: 1 gpg: w/o user IDs: 1 Other GPG import: # gpg --allow-non-selfsigned-uid --import /tmp/imps.asc gpg: key 845F5188: accepted non self-signed user ID "Concerto Support Key < concerto.support at impact-ps.com>" gpg: key 845F5188: public key "Concerto Support Key < concerto.support at impact-ps.com>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) Then: # gpg --list-keys 845F5188 pub 0s/845F5188 2013-03-05 uid Concerto Support Key # gpg --edit-key 845F5188 gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub 0s/845F5188 created: 2013-03-05 expires: never usage: SC trust: unknown validity: unknown [ unknown] (1). Concerto Support Key Command> sign User ID "Concerto Support Key " is not self-signed. Unable to sign. Nothing to sign with key 31A070A8 No matter how I try, I cannot encrypt a file using that public key, even using --edit-key to assign trust: gpg: 845F5188: skipped: Unusable public key gpg: /tmp/test.txt: encryption failed: Unusable public key The owner of the public key insists that it is self-signed; but, our GPG cannot find the self-signature What am I missing? Please, advise. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Thu Apr 24 11:13:22 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 24 Apr 2014 11:13:22 +0200 Subject: UI terminology for calculated validities In-Reply-To: <535829F9.1010503@gmail.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> Message-ID: <5358D5B2.60705@digitalbrains.com> I think "authenticity" covers the overtones much better than "validity", now that you mention it. It even makes me wonder why it wasn't chosen in the first place :). You have convinced me that it is the better term to use. I'm not enthousiastic about "ownership", because it feels like a synonym to "User ID" in OpenPGP context. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From gpg at mdsresource.net Thu Apr 24 15:15:47 2014 From: gpg at mdsresource.net (helices) Date: Thu, 24 Apr 2014 08:15:47 -0500 Subject: GPG cannot import public key In-Reply-To: <030B5D79-04C4-480D-9063-72CEBF928FAC@jabberwocky.com> References: <030B5D79-04C4-480D-9063-72CEBF928FAC@jabberwocky.com> Message-ID: Thank you, for your response. [1] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: Encryption Desktop 10.3.0 (Build 8741) mQENBFE2VhMDCADMrztp76fxxpxtvbmPIEYqE+MAMhCn6guYS31S9DVZyz/qP1zu 9hp+XBj69W5L1P02I+Cvk9kKkuuC3Hz/xkJZQVFOLeHu0s6ipl8TME71STw+ADdq Hj+FvxfkhlSwIlpIQAhb8zySbTJptME4kwoM1xASs+IjSWaOVHh/PkjgciV1p0rH gSW/xP2P4UH2A+ER93ItQNgp/oGY3u5puwKY1eV8Oy9hbCexlYxWvo7VSTYDumtM BqpMLv7yXmJUAe1LN/bIJYo87+Nr0CxVY5A9CCqAIxZy2JEkbTdI6mHLm3zb1Pn6 FiC42TLskruKlg2Zt8EVxrjeAlapAMbi55OPABEBAAG0NUNvbmNlcnRvIFN1cHBv cnQgS2V5IDxjb25jZXJ0by5zdXBwb3J0QGltcGFjdC1wcy5jb20+iQEiBBADCAAM BQJRNlYTBQkDwmcAAAoJEIl+6bmEX1GI3TgIAMHQbQA9XKw2e7Fl2IcI/wkG57oQ ve0m5/uzMEoruR4vbtwSW12f3Q4/bpokWDp617WqK0cCeec3wvDglsvXLBqHJPlo eKE8xp12eiw9qlEIk8oGpQ9BU5Bbxh0ORuu9EBRTo5mmqBZdfzRoeRVKYzMPCqFq 8ocBVdJ4NutTvEL0+58XUPFg4FOm1GHgbcRq6D8dMLO3vYj3w7wqloq45TdyRX/t I+ftQFsMBF1u4oJpQpErtsn49rVC5nK8rAodQfVY8pDWZM8VjKXk70U9w+e9AqHy X06TeKmjT8/fp/5iOUF90wftRnANkJQ4TOHH/neHlh4AVjz/cvvqz62O7ia5AQ0E UTZWFAIIANEeS9a3vKIJNlxJY4euzRkHkw0IXXRoT2NvfmC20fyTCrEWIoBGY/Pf KIr0WtMnoNem6K69D30nMPvuK7NZIEcf3c5k2KvD/p6GHZZVwnM8da/qvRmW+tFb h/W2PlOMBQpZh5Zd0o2Y/XvNmGz/agxOM9qhPj3ZysaKzy/prdx2ncHSUrvImnSH L8AtTVc0YtiI6qnhZFTivHpvAexrPUZ0/J2Qi2CL9pXTv/W5Mua1ec0HtCPTmI0g QMHcXMAhMdyrg0AQ4jlcS83Rhw6JoUQNEEuJcuuRyo6A/S0kxJuT5iZ1Za8JNoVm qOFJtASFz5wAHaAtOTuLJQe6EMaZkVEAEQEAAYkBIgQYAwgADAUCUTZWFAUJA8Jn AAAKCRCJfum5hF9RiHZSCADJ19g1ZR6mOCeUS95+NTf9TtGmoqB4ims0s8HqPOPh ihRdEEUoX16t+x8Vv6B6gF5zaeAmbMz1Mka41TFXgdgs3Y9HahXsiVKCoXJkrpKj LZFz+1fU/txCBZxf3il0JnfqY60qjdfJ5iq7iI0y7ClnjPfIHAE5j8VgrTgM+qIU +mpagibiiI7rdXNJF9hk+R5PwQrMLVLnLHq22lYcU3riGJMbRqWqXJJm6eSwxs4K Bsf+CKafoSiEKM8NrJGA9Dnd9HyeTCZTtlk92zfRh2zC0e/NCxdTlk2xy12ICoFG oeBxDq9N/8+Jbb9tQoFaOg3akr8WBKUaIRySEOky3GQJ =3RTl -----END PGP PUBLIC KEY BLOCK----- [2] Interestingly enough, importing this key with "gpg (GnuPG) 1.4.5" is successful: # gpg --import /tmp/imps.asc gpg: key 845F5188: public key "Concerto Support Key < concerto.support at impact-ps.com>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) [3] After several attempts to export a usable public key, they created a NEW keypair using their Encryption Desktop 10.3.0, which is successful. Of course, since they claim to be using the original without incident with many other vendors, they want to "fix" their original keys. [4] Worse, they tried to export it again and we got this error: # gpg --import /tmp/imps.asc Ohhhh jeeee: ... this is a bug (sexp.c:1259:sexp_sscan) Aborted -----BEGIN PGP PUBLIC KEY BLOCK----- Version: Encryption Desktop 10.3.0 (Build 8741) mQENBFE2VhMDCADMrztp76fxxpxtvbmPIEYqE+MAMhCn6guYS31S9DVZyz/qP1zu 9hp+XBj69W5L1P02I+Cvk9kKkuuC3Hz/xkJZQVFOLeHu0s6ipl8TME71STw+ADdq Hj+FvxfkhlSwIlpIQAhb8zySbTJptME4kwoM1xASs+IjSWaOVHh/PkjgciV1p0rH gSW/xP2P4UH2A+ER93ItQNgp/oGY3u5puwKY1eV8Oy9hbCexlYxWvo7VSTYDumtM BqpMLv7yXmJUAe1LN/bIJYo87+Nr0CxVY5A9CCqAIxZy2JEkbTdI6mHLm3zb1Pn6 FiC42TLskruKlg2Zt8EVxrjeAlapAMbi55OPABEBAAG0NUNvbmNlcnRvIFN1cHBv cnQgS2V5IDxjb25jZXJ0by5zdXBwb3J0QGltcGFjdC1wcy5jb20+iQFpBBABCABT BQJTWBScBQkAAAAAMBSAAAAAACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0Bw Z3AuY29tcGdwbWltZQgLCQgHAwIBCgUeAQAAAAYVCAoJAgMACgkQiX7puYRfUYga iQf/ZJ1d7dY2RdRjDzhXfarf7pPXRCFzRG32T8/i0AKL4YUW9hlaQqatrWw5DPe8 2LBgCxFptJPgQ8N8nFJBWD6h/FVtUWa7k88we2MM/9oQn7d6v3pRaVxDUKfebCIn KqcR0k7ajdUMsGC3X+C6sjMh/Oy1/bI1EDUdFqcLq02kMcMSoDr5B2vpsRm8+tSs sSaoMujMmt17v4NkOzIyuOT8oyRPxFbeYszbaLpCjnZsbc1ktmpo3SkgNn8OBckt 0A6emPuIgy8tas+rxdmz+N3EWddt9FJz0r5DLCBAo9AUfzDBQnOrnGbvHuJuZH/t EFoJZyqTFgBa+RzkVYuPXVEbY7QnSm9zaCBNaWxsZXIgPGpvc2gubWlsbGVyQGlt cGFjdC1wcy5jb20+iQFpBBABAgBTBQJTWBScBQkAAAAAMBSAAAAAACAAB3ByZWZl cnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQgLCQgHAwIBCgUeAQAA AAYVCAoJAgMACgkQiX7puYRfUYid4Af/TzyXyapN59vqiyg7N0ejuQwcnM8Cp7HJ DyJtzw/KSK/6xrfEv5vRpW58OtNOy8sjpXGLHfzwh29DBOo/oe0djpz+G/arq6Bj JjcAAX9NaYB09rileHN/gw4X3W8FnIR4cZWbO/AwUpesSL75Sc8D/SbQ1i/Gstge hzo6d79SDJ6BFRURMDDe4n+kLOZSP3VtK9i3DQ+Bl+8tvzSjLGD+B/78VX+7QR57 +CzcRjNPQXQgvLdWkWGAYCXHzKZWx/RwTX6aFFFcIjm2s2zxZfunM+ajHt0sGZgT gnCtKmfRwTWTF7xlP6t2e1Zt9v+ykRmeMtYO5+IHjlwzjIDy5Ol+VrkBDQRRNlYU AggA0R5L1re8ogk2XEljh67NGQeTDQhddGhPY29+YLbR/JMKsRYigEZj898oivRa 0yeg16borr0PfScw++4rs1kgRx/dzmTYq8P+noYdllXCczx1r+q9GZb60VuH9bY+ U4wFClmHll3SjZj9e82YbP9qDE4z2qE+PdnKxorPL+mt3HadwdJSu8iadIcvwC1N VzRi2IjqqeFkVOK8em8B7Gs9RnT8nZCLYIv2ldO/9bky5rV5zQe0I9OYjSBAwdxc wCEx3KuDQBDiOVxLzdGHDomhRA0QS4ly65HKjoD9LSTEm5PmJnVlrwk2hWao4Um0 BIXPnAAdoC05O4slB7oQxpmRUQARAQABiQEiBBgBCAAMBQJTWBP7BQkAAAAAAAoJ EIl+6bmEX1GIsYEH/2IVbsvGGuSUSLU86sw0HhOxf/q3k8MG2JbrSwpCvdGkJcr4 jbDXwfUO1taDPx6pESZmB84OASIoJGt0e5KuxWdKa0YmsQA0qERp/Y9RJnGUUNsc KPVde6aw6KfR+QAEWH6gRoKBjTfjo101tVD1qCKIpDBDsS6Gg8ucGYTJcNU4AvoV +DgTfhzg7q/Whn97idP3biLG9EHyWznRgH00t1wl+yvlaZxY/K3a3X95cTA2zwh4 2R0tJy0OzDQDyRjSfe8cT4cfH1k7WIrFb8FdXRAt3M3dtGRMvsHUM+rxxjsLEqGZ lN5nnltQiLMHkNdV/tgHCvArBSSaiuVLRYRk5sI= =i1to -----END PGP PUBLIC KEY BLOCK----- [5] As this is a new vendor relationship with my employer, and since we have automated processes for encrypting dozens of files every day, my ultimate goal is to have a public key from this vendor that works automatically, just like the hundreds of others that we have. That is to say, a signed public key that we can sign and to which we can assign trust, and that we can use to automatically encrypt and sign files that will be sent to them on a regular basis. Secondly, I understand and respect this vendor's desire to use one (1) key pair with all of their vendors. Can their original key be "fixed?" Why does legacy GPG accept that public key? I welcome all comments, suggestions and review. Thank you ~ helices On Wed, Apr 23, 2014 at 10:25 PM, David Shaw wrote: > On Apr 23, 2014, at 11:14 PM, David Shaw wrote: > > > On Apr 23, 2014, at 3:24 PM, helices wrote: > > > >> No matter how I try, I cannot encrypt a file using that public key, > even using --edit-key to assign trust: > >> > >> gpg: 845F5188: skipped: Unusable public key > >> > >> gpg: /tmp/test.txt: encryption failed: Unusable public key > >> > >> > >> The owner of the public key insists that it is self-signed; but, our > GPG cannot find the self-signature > > > > It doesn't look like it's self-signed, but without looking at the key > itself, I couldn't say for sure. Is it posted anywhere on the net? > > > > In any event, you can override the check for encryption with the same > flag you used to override the check on import. So: > > > > gpg -r 845F5188 --allow-non-selfsigned-uid -e > the-file-i-am-encrypting-etc.txt > > I should add, though, that overriding these checks is something you should > do with suitable verification of the key. Don't override the check unless > you know what you're doing, and have assured yourself that the key you are > encrypting to is really owned by the person/group that you believe it is. > Those checks are there for a reason. > > David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at axtens.net Thu Apr 24 18:02:11 2014 From: daniel at axtens.net (Daniel Axtens) Date: Fri, 25 Apr 2014 02:02:11 +1000 Subject: GPG cannot import public key In-Reply-To: References: <030B5D79-04C4-480D-9063-72CEBF928FAC@jabberwocky.com> Message-ID: <23AB0733-EAA6-45BD-A483-4155DEA598BB@axtens.net> Hi, I've had a look at the various keys in a OpenPGP compatible client I'm writing at the moment. All OpenPGP messages (including keys) are represented as a set of packets, and my code has just reached the stage of deserializing the packets and verifying some kinds of signatures, so it's good timing. Here's what I discovered: -- Key 1 -- Key 1 has the following raw packets: Public Key Packet: "\EOTQ6V\DC3\ETX\b\NUL\204\175;i\239\167\241\198\156m\189\185\143 F*\DC3\227\NUL2\DLE\167\234\v"... (269 bytes), User ID Packet: "Concerto Support Key key binding you wanted. If you really wanted to, you could delete the second user id and signature after importing the key. Hope this helps, Daniel On 24/04/2014, at 11:15 PM, helices wrote: > Thank you, for your response. > > [1] > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: Encryption Desktop 10.3.0 (Build 8741) > > mQENBFE2VhMDCADMrztp76fxxpxtvbmPIEYqE+MAMhCn6guYS31S9DVZyz/qP1zu > 9hp+XBj69W5L1P02I+Cvk9kKkuuC3Hz/xkJZQVFOLeHu0s6ipl8TME71STw+ADdq > Hj+FvxfkhlSwIlpIQAhb8zySbTJptME4kwoM1xASs+IjSWaOVHh/PkjgciV1p0rH > gSW/xP2P4UH2A+ER93ItQNgp/oGY3u5puwKY1eV8Oy9hbCexlYxWvo7VSTYDumtM > BqpMLv7yXmJUAe1LN/bIJYo87+Nr0CxVY5A9CCqAIxZy2JEkbTdI6mHLm3zb1Pn6 > FiC42TLskruKlg2Zt8EVxrjeAlapAMbi55OPABEBAAG0NUNvbmNlcnRvIFN1cHBv > cnQgS2V5IDxjb25jZXJ0by5zdXBwb3J0QGltcGFjdC1wcy5jb20+iQEiBBADCAAM > BQJRNlYTBQkDwmcAAAoJEIl+6bmEX1GI3TgIAMHQbQA9XKw2e7Fl2IcI/wkG57oQ > ve0m5/uzMEoruR4vbtwSW12f3Q4/bpokWDp617WqK0cCeec3wvDglsvXLBqHJPlo > eKE8xp12eiw9qlEIk8oGpQ9BU5Bbxh0ORuu9EBRTo5mmqBZdfzRoeRVKYzMPCqFq > 8ocBVdJ4NutTvEL0+58XUPFg4FOm1GHgbcRq6D8dMLO3vYj3w7wqloq45TdyRX/t > I+ftQFsMBF1u4oJpQpErtsn49rVC5nK8rAodQfVY8pDWZM8VjKXk70U9w+e9AqHy > X06TeKmjT8/fp/5iOUF90wftRnANkJQ4TOHH/neHlh4AVjz/cvvqz62O7ia5AQ0E > UTZWFAIIANEeS9a3vKIJNlxJY4euzRkHkw0IXXRoT2NvfmC20fyTCrEWIoBGY/Pf > KIr0WtMnoNem6K69D30nMPvuK7NZIEcf3c5k2KvD/p6GHZZVwnM8da/qvRmW+tFb > h/W2PlOMBQpZh5Zd0o2Y/XvNmGz/agxOM9qhPj3ZysaKzy/prdx2ncHSUrvImnSH > L8AtTVc0YtiI6qnhZFTivHpvAexrPUZ0/J2Qi2CL9pXTv/W5Mua1ec0HtCPTmI0g > QMHcXMAhMdyrg0AQ4jlcS83Rhw6JoUQNEEuJcuuRyo6A/S0kxJuT5iZ1Za8JNoVm > qOFJtASFz5wAHaAtOTuLJQe6EMaZkVEAEQEAAYkBIgQYAwgADAUCUTZWFAUJA8Jn > AAAKCRCJfum5hF9RiHZSCADJ19g1ZR6mOCeUS95+NTf9TtGmoqB4ims0s8HqPOPh > ihRdEEUoX16t+x8Vv6B6gF5zaeAmbMz1Mka41TFXgdgs3Y9HahXsiVKCoXJkrpKj > LZFz+1fU/txCBZxf3il0JnfqY60qjdfJ5iq7iI0y7ClnjPfIHAE5j8VgrTgM+qIU > +mpagibiiI7rdXNJF9hk+R5PwQrMLVLnLHq22lYcU3riGJMbRqWqXJJm6eSwxs4K > Bsf+CKafoSiEKM8NrJGA9Dnd9HyeTCZTtlk92zfRh2zC0e/NCxdTlk2xy12ICoFG > oeBxDq9N/8+Jbb9tQoFaOg3akr8WBKUaIRySEOky3GQJ > =3RTl > -----END PGP PUBLIC KEY BLOCK----- > > [2] Interestingly enough, importing this key with "gpg (GnuPG) 1.4.5" is successful: > # gpg --import /tmp/imps.asc > gpg: key 845F5188: public key "Concerto Support Key " imported > gpg: Total number processed: 1 > gpg: imported: 1 (RSA: 1) > > [3] After several attempts to export a usable public key, they created a NEW keypair using their Encryption Desktop 10.3.0, which is successful. Of course, since they claim to be using the original without incident with many other vendors, they want to "fix" their original keys. > > [4] Worse, they tried to export it again and we got this error: > # gpg --import /tmp/imps.asc > Ohhhh jeeee: ... this is a bug (sexp.c:1259:sexp_sscan) > Aborted > > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: Encryption Desktop 10.3.0 (Build 8741) > > mQENBFE2VhMDCADMrztp76fxxpxtvbmPIEYqE+MAMhCn6guYS31S9DVZyz/qP1zu > 9hp+XBj69W5L1P02I+Cvk9kKkuuC3Hz/xkJZQVFOLeHu0s6ipl8TME71STw+ADdq > Hj+FvxfkhlSwIlpIQAhb8zySbTJptME4kwoM1xASs+IjSWaOVHh/PkjgciV1p0rH > gSW/xP2P4UH2A+ER93ItQNgp/oGY3u5puwKY1eV8Oy9hbCexlYxWvo7VSTYDumtM > BqpMLv7yXmJUAe1LN/bIJYo87+Nr0CxVY5A9CCqAIxZy2JEkbTdI6mHLm3zb1Pn6 > FiC42TLskruKlg2Zt8EVxrjeAlapAMbi55OPABEBAAG0NUNvbmNlcnRvIFN1cHBv > cnQgS2V5IDxjb25jZXJ0by5zdXBwb3J0QGltcGFjdC1wcy5jb20+iQFpBBABCABT > BQJTWBScBQkAAAAAMBSAAAAAACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0Bw > Z3AuY29tcGdwbWltZQgLCQgHAwIBCgUeAQAAAAYVCAoJAgMACgkQiX7puYRfUYga > iQf/ZJ1d7dY2RdRjDzhXfarf7pPXRCFzRG32T8/i0AKL4YUW9hlaQqatrWw5DPe8 > 2LBgCxFptJPgQ8N8nFJBWD6h/FVtUWa7k88we2MM/9oQn7d6v3pRaVxDUKfebCIn > KqcR0k7ajdUMsGC3X+C6sjMh/Oy1/bI1EDUdFqcLq02kMcMSoDr5B2vpsRm8+tSs > sSaoMujMmt17v4NkOzIyuOT8oyRPxFbeYszbaLpCjnZsbc1ktmpo3SkgNn8OBckt > 0A6emPuIgy8tas+rxdmz+N3EWddt9FJz0r5DLCBAo9AUfzDBQnOrnGbvHuJuZH/t > EFoJZyqTFgBa+RzkVYuPXVEbY7QnSm9zaCBNaWxsZXIgPGpvc2gubWlsbGVyQGlt > cGFjdC1wcy5jb20+iQFpBBABAgBTBQJTWBScBQkAAAAAMBSAAAAAACAAB3ByZWZl > cnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQgLCQgHAwIBCgUeAQAA > AAYVCAoJAgMACgkQiX7puYRfUYid4Af/TzyXyapN59vqiyg7N0ejuQwcnM8Cp7HJ > DyJtzw/KSK/6xrfEv5vRpW58OtNOy8sjpXGLHfzwh29DBOo/oe0djpz+G/arq6Bj > JjcAAX9NaYB09rileHN/gw4X3W8FnIR4cZWbO/AwUpesSL75Sc8D/SbQ1i/Gstge > hzo6d79SDJ6BFRURMDDe4n+kLOZSP3VtK9i3DQ+Bl+8tvzSjLGD+B/78VX+7QR57 > +CzcRjNPQXQgvLdWkWGAYCXHzKZWx/RwTX6aFFFcIjm2s2zxZfunM+ajHt0sGZgT > gnCtKmfRwTWTF7xlP6t2e1Zt9v+ykRmeMtYO5+IHjlwzjIDy5Ol+VrkBDQRRNlYU > AggA0R5L1re8ogk2XEljh67NGQeTDQhddGhPY29+YLbR/JMKsRYigEZj898oivRa > 0yeg16borr0PfScw++4rs1kgRx/dzmTYq8P+noYdllXCczx1r+q9GZb60VuH9bY+ > U4wFClmHll3SjZj9e82YbP9qDE4z2qE+PdnKxorPL+mt3HadwdJSu8iadIcvwC1N > VzRi2IjqqeFkVOK8em8B7Gs9RnT8nZCLYIv2ldO/9bky5rV5zQe0I9OYjSBAwdxc > wCEx3KuDQBDiOVxLzdGHDomhRA0QS4ly65HKjoD9LSTEm5PmJnVlrwk2hWao4Um0 > BIXPnAAdoC05O4slB7oQxpmRUQARAQABiQEiBBgBCAAMBQJTWBP7BQkAAAAAAAoJ > EIl+6bmEX1GIsYEH/2IVbsvGGuSUSLU86sw0HhOxf/q3k8MG2JbrSwpCvdGkJcr4 > jbDXwfUO1taDPx6pESZmB84OASIoJGt0e5KuxWdKa0YmsQA0qERp/Y9RJnGUUNsc > KPVde6aw6KfR+QAEWH6gRoKBjTfjo101tVD1qCKIpDBDsS6Gg8ucGYTJcNU4AvoV > +DgTfhzg7q/Whn97idP3biLG9EHyWznRgH00t1wl+yvlaZxY/K3a3X95cTA2zwh4 > 2R0tJy0OzDQDyRjSfe8cT4cfH1k7WIrFb8FdXRAt3M3dtGRMvsHUM+rxxjsLEqGZ > lN5nnltQiLMHkNdV/tgHCvArBSSaiuVLRYRk5sI= > =i1to > -----END PGP PUBLIC KEY BLOCK----- > > [5] As this is a new vendor relationship with my employer, and since we have automated processes for encrypting dozens of files every day, my ultimate goal is to have a public key from this vendor that works automatically, just like the hundreds of others that we have. That is to say, a signed public key that we can sign and to which we can assign trust, and that we can use to automatically encrypt and sign files that will be sent to them on a regular basis. Secondly, I understand and respect this vendor's desire to use one (1) key pair with all of their vendors. > > Can their original key be "fixed?" Why does legacy GPG accept that public key? > > I welcome all comments, suggestions and review. Thank you > > ~ helices > > > On Wed, Apr 23, 2014 at 10:25 PM, David Shaw wrote: > On Apr 23, 2014, at 11:14 PM, David Shaw wrote: > > > On Apr 23, 2014, at 3:24 PM, helices wrote: > > > >> No matter how I try, I cannot encrypt a file using that public key, even using --edit-key to assign trust: > >> > >> gpg: 845F5188: skipped: Unusable public key > >> > >> gpg: /tmp/test.txt: encryption failed: Unusable public key > >> > >> > >> The owner of the public key insists that it is self-signed; but, our GPG cannot find the self-signature > > > > It doesn't look like it's self-signed, but without looking at the key itself, I couldn't say for sure. Is it posted anywhere on the net? > > > > In any event, you can override the check for encryption with the same flag you used to override the check on import. So: > > > > gpg -r 845F5188 --allow-non-selfsigned-uid -e the-file-i-am-encrypting-etc.txt > > I should add, though, that overriding these checks is something you should do with suitable verification of the key. Don't override the check unless you know what you're doing, and have assured yourself that the key you are encrypting to is really owned by the person/group that you believe it is. Those checks are there for a reason. > > David > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From gpg at mdsresource.net Thu Apr 24 18:12:23 2014 From: gpg at mdsresource.net (helices) Date: Thu, 24 Apr 2014 11:12:23 -0500 Subject: GPG cannot import public key In-Reply-To: <23AB0733-EAA6-45BD-A483-4155DEA598BB@axtens.net> References: <030B5D79-04C4-480D-9063-72CEBF928FAC@jabberwocky.com> <23AB0733-EAA6-45BD-A483-4155DEA598BB@axtens.net> Message-ID: Hi, Daniel! No Please, re-read: [4] Worse, they tried to export it again and we got this error: # gpg --import /tmp/imps.asc Ohhhh jeeee: ... this is a bug (sexp.c:1259:sexp_sscan) Aborted Key #2 gives me that bizarre error on trying to import it. I do appreciate your analysis. I hope that a GPG developer can use it to advance gpg. On Thu, Apr 24, 2014 at 11:02 AM, Daniel Axtens wrote: > Hi, > > I've had a look at the various keys in a OpenPGP compatible client I'm > writing at the moment. All OpenPGP messages (including keys) are > represented as a set of packets, and my code has just reached the stage of > deserializing the packets and verifying some kinds of signatures, so it's > good timing. Here's what I discovered: > > -- Key 1 -- > > Key 1 has the following raw packets: > Public Key Packet: > "\EOTQ6V\DC3\ETX\b\NUL\204\175;i\239\167\241\198\156m\189\185\143 > F*\DC3\227\NUL2\DLE\167\234\v"... (269 bytes), > User ID Packet: "Concerto Support Key Signature Packet: > "\EOT\DLE\ETX\b\NUL\f\ENQ\STXQ6V\DC3\ENQ\t\ETX\194g\NUL\NUL\n\t\DLE\137~\233\185\132_Q\136\221\&8"... > (290 bytes), > Public Subkey Packet: > "\EOTQ6V\DC4\STX\b\NUL\209\RSK\214\183\188\162\t6\\Ic\135\174\205\EM\a\147\r\b]thO"... > (269 bytes), > Signature Packet: > "\EOT\CAN\ETX\b\NUL\f\ENQ\STXQ6V\DC4\ENQ\t\ETX\194g\NUL\NUL\n\t\DLE\137~\233\185\132_Q\136vR"... > (290 bytes) > > Processing the packets, the public key reads as: > Public Key: Created: Tue Mar 5 20:31:15 UTC 2013, RSA Sign Only, 2048 > bits, fingerprint: f6a721e7343193be840fc2ca897ee9b9845f5188 > > If I load the first signature, I see that it's a Version 4 Generic > Certification Signature, made with an RSA Sign Only key having key ID > 845f5188, and using a SHA256 hash. This is the signature that binds the > user id and the public key, and it's valid, at least as verified by my code. > > Therefore, as far as I can tell, the RSA self-signature binding the UID to > the public key is a valid signature. > > But that's not the end of the story. If you look at Section 9.1 of the > OpenPGP RFC (RFC 4880), you'll see: > > "Implementations SHOULD implement RSA keys (1). RSA > Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be > generated, but may be interpreted. See Section 13.5." > > Section 13.5 says: > > "There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only > keys. These types are deprecated. The "key flags" subpacket in a > signature is a much better way to express the same idea, and > generalizes it to all algorithms. An implementation SHOULD NOT > create such a key, but MAY interpret it." > > So ultimately, both GPG 2 and the creators of the original key are correct. > It is a valid key, but it should not have been generated and GPG 2 may > legitimately, and in full compliance with the RFC, refuse to recognise it. > I suspect the older version of GPG is more permissive and choses to accept > it, although not being familiar with the code of either version, that's > just speculation on my part. > > -- Key 2 -- > > Oddly, gpg2 crashes for me when trying to import this key. However, the > code I'm writing works fine. > > The raw packets are: > Public Key Packet: > "\EOTQ6V\DC3\ETX\b\NUL\204\175;i\239\167\241\198\156m\189\185\143 > F*\DC3\227\NUL2\DLE\167\234\v"... (269 bytes), > User ID Packet: "Concerto Support Key Signature Packet: > "\EOT\DLE\SOH\b\NULS\ENQ\STXSX\DC4\156\ENQ\t\NUL\NUL\NUL\NUL0\DC4\128\NUL\NUL\NUL\NUL > \NUL\apref"... (361 bytes), > User ID Packet: "Josh Miller Signature Packet: > "\EOT\DLE\SOH\STX\NULS\ENQ\STXSX\DC4\156\ENQ\t\NUL\NUL\NUL\NUL0\DC4\128\NUL\NUL\NUL\NUL > \NUL\apref"... (361 bytes), > Public Subkey Packet: > "\EOTQ6V\DC4\STX\b\NUL\209\RSK\214\183\188\162\t6\\Ic\135\174\205\EM\a\147\r\b]thO"... > (269 bytes), > Signature Packet: > "\EOT\CAN\SOH\b\NUL\f\ENQ\STXSX\DC3\251\ENQ\t\NUL\NUL\NUL\NUL\NUL\n\t\DLE\137~\233\185\132_Q\136\177\129"... > (290 bytes) > > The public key is, oddly, the same - so it's not a new key, just a > re-export of the old key: > Public Key: Created: Tue Mar 5 20:31:15 UTC 2013, RSA Sign Only, 2048 > bits, fingerprint: f6a721e7343193be840fc2ca897ee9b9845f5188 > > The user ID (Concerto Support Key) is again bound with a Version 4 Generic > Certification Signature. This time the signature claims to be made with RSA > *Encrypt Or Sign* key ID 845f5188, and hash algorithm SHA256. You'll notice > that's the same key ID as the public key - in other words, the signature > simply _claims_ that the key it's made with is an Encrypt or Sign key, even > though the Public Key itself claims to be a Sign Only key. > > The signature is valid according to my code. > > I suspect this is imported fine by your GPG 2 because GPG verifies the > signature without checking if the type of key the signature claims it's > made by matches the type of key found for that key ID. > (This works out fine in actual usage because RSA keys are all the same > anyway - the distinction between Encrypt & Sign/Encrypt Only/Sign Only > doesn't exist in the maths, it's added at the application level.) > > Interestingly, the key contains a binding between another user (Josh > Miller) and the public key. This signature again lies about the type of the > issuing key, although this one is made with SHA1 instead of SHA256. Again, > the signature seems valid. > > -- Further remarks -- > > I should reiterate that I'm not fluent in GPG's code, so I'm only > speculating as to the behaviour of GPG. > > You asked if it is possible to 'fix' the first key. As far as I can tell, > you should just be able to use the second key: they both publish the same > key and the user id <-> key binding you wanted. If you really wanted to, > you could delete the second user id and signature after importing the key. > > Hope this helps, > Daniel > > > On 24/04/2014, at 11:15 PM, helices wrote: > > > Thank you, for your response. > > > > [1] > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > Version: Encryption Desktop 10.3.0 (Build 8741) > > > > mQENBFE2VhMDCADMrztp76fxxpxtvbmPIEYqE+MAMhCn6guYS31S9DVZyz/qP1zu > > 9hp+XBj69W5L1P02I+Cvk9kKkuuC3Hz/xkJZQVFOLeHu0s6ipl8TME71STw+ADdq > > Hj+FvxfkhlSwIlpIQAhb8zySbTJptME4kwoM1xASs+IjSWaOVHh/PkjgciV1p0rH > > gSW/xP2P4UH2A+ER93ItQNgp/oGY3u5puwKY1eV8Oy9hbCexlYxWvo7VSTYDumtM > > BqpMLv7yXmJUAe1LN/bIJYo87+Nr0CxVY5A9CCqAIxZy2JEkbTdI6mHLm3zb1Pn6 > > FiC42TLskruKlg2Zt8EVxrjeAlapAMbi55OPABEBAAG0NUNvbmNlcnRvIFN1cHBv > > cnQgS2V5IDxjb25jZXJ0by5zdXBwb3J0QGltcGFjdC1wcy5jb20+iQEiBBADCAAM > > BQJRNlYTBQkDwmcAAAoJEIl+6bmEX1GI3TgIAMHQbQA9XKw2e7Fl2IcI/wkG57oQ > > ve0m5/uzMEoruR4vbtwSW12f3Q4/bpokWDp617WqK0cCeec3wvDglsvXLBqHJPlo > > eKE8xp12eiw9qlEIk8oGpQ9BU5Bbxh0ORuu9EBRTo5mmqBZdfzRoeRVKYzMPCqFq > > 8ocBVdJ4NutTvEL0+58XUPFg4FOm1GHgbcRq6D8dMLO3vYj3w7wqloq45TdyRX/t > > I+ftQFsMBF1u4oJpQpErtsn49rVC5nK8rAodQfVY8pDWZM8VjKXk70U9w+e9AqHy > > X06TeKmjT8/fp/5iOUF90wftRnANkJQ4TOHH/neHlh4AVjz/cvvqz62O7ia5AQ0E > > UTZWFAIIANEeS9a3vKIJNlxJY4euzRkHkw0IXXRoT2NvfmC20fyTCrEWIoBGY/Pf > > KIr0WtMnoNem6K69D30nMPvuK7NZIEcf3c5k2KvD/p6GHZZVwnM8da/qvRmW+tFb > > h/W2PlOMBQpZh5Zd0o2Y/XvNmGz/agxOM9qhPj3ZysaKzy/prdx2ncHSUrvImnSH > > L8AtTVc0YtiI6qnhZFTivHpvAexrPUZ0/J2Qi2CL9pXTv/W5Mua1ec0HtCPTmI0g > > QMHcXMAhMdyrg0AQ4jlcS83Rhw6JoUQNEEuJcuuRyo6A/S0kxJuT5iZ1Za8JNoVm > > qOFJtASFz5wAHaAtOTuLJQe6EMaZkVEAEQEAAYkBIgQYAwgADAUCUTZWFAUJA8Jn > > AAAKCRCJfum5hF9RiHZSCADJ19g1ZR6mOCeUS95+NTf9TtGmoqB4ims0s8HqPOPh > > ihRdEEUoX16t+x8Vv6B6gF5zaeAmbMz1Mka41TFXgdgs3Y9HahXsiVKCoXJkrpKj > > LZFz+1fU/txCBZxf3il0JnfqY60qjdfJ5iq7iI0y7ClnjPfIHAE5j8VgrTgM+qIU > > +mpagibiiI7rdXNJF9hk+R5PwQrMLVLnLHq22lYcU3riGJMbRqWqXJJm6eSwxs4K > > Bsf+CKafoSiEKM8NrJGA9Dnd9HyeTCZTtlk92zfRh2zC0e/NCxdTlk2xy12ICoFG > > oeBxDq9N/8+Jbb9tQoFaOg3akr8WBKUaIRySEOky3GQJ > > =3RTl > > -----END PGP PUBLIC KEY BLOCK----- > > > > [2] Interestingly enough, importing this key with "gpg (GnuPG) 1.4.5" is > successful: > > # gpg --import /tmp/imps.asc > > gpg: key 845F5188: public key "Concerto Support Key < > concerto.support at impact-ps.com>" imported > > gpg: Total number processed: 1 > > gpg: imported: 1 (RSA: 1) > > > > [3] After several attempts to export a usable public key, they created a > NEW keypair using their Encryption Desktop 10.3.0, which is successful. Of > course, since they claim to be using the original without incident with > many other vendors, they want to "fix" their original keys. > > > > [4] Worse, they tried to export it again and we got this error: > > # gpg --import /tmp/imps.asc > > Ohhhh jeeee: ... this is a bug (sexp.c:1259:sexp_sscan) > > Aborted > > > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > Version: Encryption Desktop 10.3.0 (Build 8741) > > > > mQENBFE2VhMDCADMrztp76fxxpxtvbmPIEYqE+MAMhCn6guYS31S9DVZyz/qP1zu > > 9hp+XBj69W5L1P02I+Cvk9kKkuuC3Hz/xkJZQVFOLeHu0s6ipl8TME71STw+ADdq > > Hj+FvxfkhlSwIlpIQAhb8zySbTJptME4kwoM1xASs+IjSWaOVHh/PkjgciV1p0rH > > gSW/xP2P4UH2A+ER93ItQNgp/oGY3u5puwKY1eV8Oy9hbCexlYxWvo7VSTYDumtM > > BqpMLv7yXmJUAe1LN/bIJYo87+Nr0CxVY5A9CCqAIxZy2JEkbTdI6mHLm3zb1Pn6 > > FiC42TLskruKlg2Zt8EVxrjeAlapAMbi55OPABEBAAG0NUNvbmNlcnRvIFN1cHBv > > cnQgS2V5IDxjb25jZXJ0by5zdXBwb3J0QGltcGFjdC1wcy5jb20+iQFpBBABCABT > > BQJTWBScBQkAAAAAMBSAAAAAACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0Bw > > Z3AuY29tcGdwbWltZQgLCQgHAwIBCgUeAQAAAAYVCAoJAgMACgkQiX7puYRfUYga > > iQf/ZJ1d7dY2RdRjDzhXfarf7pPXRCFzRG32T8/i0AKL4YUW9hlaQqatrWw5DPe8 > > 2LBgCxFptJPgQ8N8nFJBWD6h/FVtUWa7k88we2MM/9oQn7d6v3pRaVxDUKfebCIn > > KqcR0k7ajdUMsGC3X+C6sjMh/Oy1/bI1EDUdFqcLq02kMcMSoDr5B2vpsRm8+tSs > > sSaoMujMmt17v4NkOzIyuOT8oyRPxFbeYszbaLpCjnZsbc1ktmpo3SkgNn8OBckt > > 0A6emPuIgy8tas+rxdmz+N3EWddt9FJz0r5DLCBAo9AUfzDBQnOrnGbvHuJuZH/t > > EFoJZyqTFgBa+RzkVYuPXVEbY7QnSm9zaCBNaWxsZXIgPGpvc2gubWlsbGVyQGlt > > cGFjdC1wcy5jb20+iQFpBBABAgBTBQJTWBScBQkAAAAAMBSAAAAAACAAB3ByZWZl > > cnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQgLCQgHAwIBCgUeAQAA > > AAYVCAoJAgMACgkQiX7puYRfUYid4Af/TzyXyapN59vqiyg7N0ejuQwcnM8Cp7HJ > > DyJtzw/KSK/6xrfEv5vRpW58OtNOy8sjpXGLHfzwh29DBOo/oe0djpz+G/arq6Bj > > JjcAAX9NaYB09rileHN/gw4X3W8FnIR4cZWbO/AwUpesSL75Sc8D/SbQ1i/Gstge > > hzo6d79SDJ6BFRURMDDe4n+kLOZSP3VtK9i3DQ+Bl+8tvzSjLGD+B/78VX+7QR57 > > +CzcRjNPQXQgvLdWkWGAYCXHzKZWx/RwTX6aFFFcIjm2s2zxZfunM+ajHt0sGZgT > > gnCtKmfRwTWTF7xlP6t2e1Zt9v+ykRmeMtYO5+IHjlwzjIDy5Ol+VrkBDQRRNlYU > > AggA0R5L1re8ogk2XEljh67NGQeTDQhddGhPY29+YLbR/JMKsRYigEZj898oivRa > > 0yeg16borr0PfScw++4rs1kgRx/dzmTYq8P+noYdllXCczx1r+q9GZb60VuH9bY+ > > U4wFClmHll3SjZj9e82YbP9qDE4z2qE+PdnKxorPL+mt3HadwdJSu8iadIcvwC1N > > VzRi2IjqqeFkVOK8em8B7Gs9RnT8nZCLYIv2ldO/9bky5rV5zQe0I9OYjSBAwdxc > > wCEx3KuDQBDiOVxLzdGHDomhRA0QS4ly65HKjoD9LSTEm5PmJnVlrwk2hWao4Um0 > > BIXPnAAdoC05O4slB7oQxpmRUQARAQABiQEiBBgBCAAMBQJTWBP7BQkAAAAAAAoJ > > EIl+6bmEX1GIsYEH/2IVbsvGGuSUSLU86sw0HhOxf/q3k8MG2JbrSwpCvdGkJcr4 > > jbDXwfUO1taDPx6pESZmB84OASIoJGt0e5KuxWdKa0YmsQA0qERp/Y9RJnGUUNsc > > KPVde6aw6KfR+QAEWH6gRoKBjTfjo101tVD1qCKIpDBDsS6Gg8ucGYTJcNU4AvoV > > +DgTfhzg7q/Whn97idP3biLG9EHyWznRgH00t1wl+yvlaZxY/K3a3X95cTA2zwh4 > > 2R0tJy0OzDQDyRjSfe8cT4cfH1k7WIrFb8FdXRAt3M3dtGRMvsHUM+rxxjsLEqGZ > > lN5nnltQiLMHkNdV/tgHCvArBSSaiuVLRYRk5sI= > > =i1to > > -----END PGP PUBLIC KEY BLOCK----- > > > > [5] As this is a new vendor relationship with my employer, and since we > have automated processes for encrypting dozens of files every day, my > ultimate goal is to have a public key from this vendor that works > automatically, just like the hundreds of others that we have. That is to > say, a signed public key that we can sign and to which we can assign trust, > and that we can use to automatically encrypt and sign files that will be > sent to them on a regular basis. Secondly, I understand and respect this > vendor's desire to use one (1) key pair with all of their vendors. > > > > Can their original key be "fixed?" Why does legacy GPG accept that > public key? > > > > I welcome all comments, suggestions and review. Thank you > > > > ~ helices > > > > > > On Wed, Apr 23, 2014 at 10:25 PM, David Shaw > wrote: > > On Apr 23, 2014, at 11:14 PM, David Shaw wrote: > > > > > On Apr 23, 2014, at 3:24 PM, helices wrote: > > > > > >> No matter how I try, I cannot encrypt a file using that public key, > even using --edit-key to assign trust: > > >> > > >> gpg: 845F5188: skipped: Unusable public key > > >> > > >> gpg: /tmp/test.txt: encryption failed: Unusable public key > > >> > > >> > > >> The owner of the public key insists that it is self-signed; but, our > GPG cannot find the self-signature > > > > > > It doesn't look like it's self-signed, but without looking at the key > itself, I couldn't say for sure. Is it posted anywhere on the net? > > > > > > In any event, you can override the check for encryption with the same > flag you used to override the check on import. So: > > > > > > gpg -r 845F5188 --allow-non-selfsigned-uid -e > the-file-i-am-encrypting-etc.txt > > > > I should add, though, that overriding these checks is something you > should do with suitable verification of the key. Don't override the check > unless you know what you're doing, and have assured yourself that the key > you are encrypting to is really owned by the person/group that you believe > it is. Those checks are there for a reason. > > > > David > > > > > > _______________________________________________ > > Gnupg-users mailing list > > Gnupg-users at gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Thu Apr 24 19:55:07 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 24 Apr 2014 13:55:07 -0400 Subject: GPG cannot import public key In-Reply-To: References: <030B5D79-04C4-480D-9063-72CEBF928FAC@jabberwocky.com> Message-ID: <184B57B5-061B-46F0-818A-F69489568C33@jabberwocky.com> On Apr 24, 2014, at 9:15 AM, helices wrote: > Thank you, for your response. > > [1] > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: Encryption Desktop 10.3.0 (Build 8741) [..] > -----END PGP PUBLIC KEY BLOCK----- Interesting! This definitely has a selfsig, but the key itself is very odd. It's an RSA sign-only key, which is deprecated in OpenPGP. The subkey is similarly odd - a RSA encrypt-only key, also deprecated. The header says it came from "Encryption Desktop", which is a Symantec product (well, it is now). I don't know why that key is using deprecated key types, but certainly something is odd there. RFC-4880 (published back in 2007) says: RSA Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be generated, but may be interpreted. Weirder, the selfsig says it's a RSA signature (not RSA_S), so you have the odd situation of a key (RSA_S) and its self-sig (RSA) being from different algorithms. So, it's legal for GPG to not accept this key (using deprecated algorithms), though the error message you got seems misleading to me. > [2] Interestingly enough, importing this key with "gpg (GnuPG) 1.4.5" is successful: > # gpg --import /tmp/imps.asc > gpg: key 845F5188: public key "Concerto Support Key " imported > gpg: Total number processed: 1 > gpg: imported: 1 (RSA: 1) GPG 1.4.5 treats RSA_S and RSA_E as identical to RSA for existing keys, but does not allow generating them. This is legal as per the spec (i.e. don't generate them, but it's optional to use them). I'm afraid I don't have immediate access to the GPG 2.x code base to check, but I wonder if your problem is simply that 2.x doesn't accept RSA_S and RSA_E keys? David From dkg at fifthhorseman.net Thu Apr 24 20:18:09 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 24 Apr 2014 14:18:09 -0400 Subject: best practice for pgp mail service, revoking keys In-Reply-To: <0a33252a-4a50-4dd8-1850-084186b21f3d@piratemail.se> References: <0a33252a-4a50-4dd8-1850-084186b21f3d@piratemail.se> Message-ID: <53595561.2040705@fifthhorseman.net> On 04/23/2014 06:13 PM, tim at piratemail.se wrote: > This is a tiny bit philosophical. Perhaps a little off-topic. I think this is probably the best list to ask never-the-less. > > So I've been working on this pgp base web based mail service. > https://github.com/timprepscius/mv > > Here is the problem I hope eventually to be confronted with: > > 1. User registers name "decker at piratemail.se," user auto-magically generates a pgp pub/priv key. The pub key is registered on the pgp key servers. > 2. User goes away. Account is closed. > 3. User still has "decker at piratemail.se" registered on the pgp key servers. > 4. Another person wants to use "decker at piratemail.se." He would generate a brand new pgp key with a later creation date, but still that old one seems like a liability. > > What should I do? > > A few options I can see: > 1. email addresses are used only once. > 2. email addresses are used more than once, but with a warning, "there already exists an unrevoked pgp key for this address." > 3. user gives me a revocation certification when he generates his pgp key, I can revoke accounts which close. > 4. user generates pgp keys which expire after a year > 5. ? > > I would like to do #3. But perhaps this is not the way to go. I'm not sure if #4 is possible with the javascript pgp lib I'm using atm. > > Any thoughts? I'm glad you're thinking about these key and account lifecycle questions in your design. note that with expiring keys (option 4) you can always extend the expiration date if the account is still in use as the expiration date draws near. You could make each key with a 1-year expiration date, and if the account is in use with less than 3 months until the expiration, it could move the expiration out another year. Combine this with a policy that a terminated e-mail account's address can't be re-used within a year (this sort of "fallow" period is a good idea for other, non-crypto-related reasons too), and it would seem like you're in pretty good shape. Please also recognize that *anyone* can put a public key with a given User ID on the public keyservers. So while you're taking reasonable steps to try to limit the confusion that your own system causes for your users, you probably can't prevent other people from create a key with a matching User ID and uploading it anyway if they want. This is why your users ultimately want to rely on strong identity certifications, and not just the presence of a key on the public keyservers. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From gpg at mdsresource.net Thu Apr 24 20:59:22 2014 From: gpg at mdsresource.net (helices) Date: Thu, 24 Apr 2014 13:59:22 -0500 Subject: GPG cannot import public key In-Reply-To: <184B57B5-061B-46F0-818A-F69489568C33@jabberwocky.com> References: <030B5D79-04C4-480D-9063-72CEBF928FAC@jabberwocky.com> <184B57B5-061B-46F0-818A-F69489568C33@jabberwocky.com> Message-ID: Thank you, David For now, they have agreed to move forward with the new key pair that they created yesterday, using that same "Encryption Desktop 10.3.0 (Build 8741)" PGP is Symantec for several years now ... It is strange to me that the newly created public key breezed through our import processes without incident. I cannot be sure how their original key pair was originally created - they say that they have been using it for quite awhile. It would be nice - for them now and for me in the future - if their original key can be "fixed." Mostly, I'm not certain how much of this GPG and how much whatever is on their side. On Thu, Apr 24, 2014 at 12:55 PM, David Shaw wrote: > On Apr 24, 2014, at 9:15 AM, helices wrote: > > > Thank you, for your response. > > > > [1] > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > Version: Encryption Desktop 10.3.0 (Build 8741) > > [..] > > > -----END PGP PUBLIC KEY BLOCK----- > > Interesting! This definitely has a selfsig, but the key itself is very > odd. It's an RSA sign-only key, which is deprecated in OpenPGP. The > subkey is similarly odd - a RSA encrypt-only key, also deprecated. The > header says it came from "Encryption Desktop", which is a Symantec product > (well, it is now). I don't know why that key is using deprecated key > types, but certainly something is odd there. > > RFC-4880 (published back in 2007) says: > > RSA Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be > generated, but may be interpreted. > > Weirder, the selfsig says it's a RSA signature (not RSA_S), so you have > the odd situation of a key (RSA_S) and its self-sig (RSA) being from > different algorithms. > > So, it's legal for GPG to not accept this key (using deprecated > algorithms), though the error message you got seems misleading to me. > > > [2] Interestingly enough, importing this key with "gpg (GnuPG) 1.4.5" is > successful: > > # gpg --import /tmp/imps.asc > > gpg: key 845F5188: public key "Concerto Support Key < > concerto.support at impact-ps.com>" imported > > gpg: Total number processed: 1 > > gpg: imported: 1 (RSA: 1) > > GPG 1.4.5 treats RSA_S and RSA_E as identical to RSA for existing keys, > but does not allow generating them. This is legal as per the spec (i.e. > don't generate them, but it's optional to use them). > > I'm afraid I don't have immediate access to the GPG 2.x code base to > check, but I wonder if your problem is simply that 2.x doesn't accept RSA_S > and RSA_E keys? > > David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2014-667rhzu3dc-lists-groups at riseup.net Thu Apr 24 21:45:10 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 24 Apr 2014 20:45:10 +0100 Subject: UI terminology for calculated validities In-Reply-To: <535829F9.1010503@gmail.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> Message-ID: <1397259291.20140424204510@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 NotDashEscaped: You need GnuPG to verify this message Hi On Wednesday 23 April 2014 at 10:00:41 PM, in , Gabriel Niebler wrote: > The average layperson already has a concept of > "validity" from such things as credit cards ("valid > thru"), mass transit tickets ("not valid unless > stamped") and passports ("valid from ... until ...", > also made invalid when one gets a new one). These > pre-existing notions, which are impossible to rub out, > naturally translate to _expiration_ and _revocation_ of > keys, NOT to the question who the key really belongs > to. A key on my keyring is "valid" if it is not expired or revoked and it bears one signature from one of my keys, or several signatures from other keys to which I have granted marginal authority to validate keys. "Valid" in this context means that my copy of GnuPG will accept it as an encryption key. It is not necessarily related to the purported identity of the person or persons who are thought to have access to the corresponding private key. (I may, for example, locally sign a key that works for exchanging with a particular email address. That does not mean I have any clue who controls that key or that email address.) > Technically inclined people have a second > association with the word "valid", more akin to > "well-formed" ("is this valid XML?"), which naturally > translates to whether e.g. a given version and > implementation of OpenPGP can understand a given key > etc. and, again, does NOT translate to the question of > the key holder's true identity. Hence the confusion. What is somebody's "true" identity? Many (or even most) people have more than one identity, some long-lasting and others ephemeral. A professional versus a personal identity. Multiple social identities depending on context. A professional identity in each of several occupations, either simultaneously or changing over time. The name on their birth certificate versus the name by which they are actually known. Etc. > What makes it worse is that in the above examples, i.e. > the cases people are familiar with, validity can > usually be determined from the document itself (here > that would be the key), or at worst the system that > works with the document (here that would be GnuPG), but > neither is the case with key ownership. GnuPG *can* inspect the signatures present on a key to determine validity. Validity does not equate to ownership or identity. > Simply put, the word "validity" already means something > to most people, but it was taken and redefined to mean > something else in the context of asymmetric encryption > keys No it was not. The key is "valid" by virtue of the signatures it carries. It is a simple mechanism. > - it's a bit like making a calculator and using > the '+' sign for multiplication: it will do the correct > thing and it's all in the manual, but it's still > horribly confusing. Validity is just counting the relevant signatures. It only becomes confusing when you consider the meaning of those signatures. > Therefore, I propose that the word "validity" is not > chosen well for what it now means in GnuPG, because it > carries with it connotations that are quite different > from the intended meaning, which is confusing. And thus > a better, clearer word should be found and used in > future. Which word is obviously a matter for debate. I disagree. Validity in GnuPG is a perfectly clear descriptive name for a simple, mechanistic concept. > Ad (a): A user wants to know whether the key they > obtained is really _owned_ by the person whose > UserID(s) came with it. Once the user establishes the question of ownership/identity/control, they *could* then choose to validate the key by signing it. But the choice is theirs alone: simply knowing does not make their copy of GnuPG accept the key as "valid." > My government issued passport is authentic and I own > it, Mine says it remains the property of the government and may be withdrawn at any time. So whoever uses the passport when they travel, it is never the owner. -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net If at first you don't succeed, destroy all evidence that you tried. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNZadVXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pAKsD/RQojcO4e2sNaKt8ls/7RRq27EaOi8iJh5+O sxfv770hqEpDa9o4KrCW0Q4XscUwm/G73fNWLTVtQ4QrLlpdmlCdjPkTSUcIjkpH QVyb5HcuXRiWzeAx/MkdxASl4GpVyxnOa7CWOHaAgQngMGh9Qbg2vduCMnE2rhys 5pmjOiEM =CmSc -----END PGP SIGNATURE----- From privacyfirst at xmail.net Thu Apr 24 22:34:02 2014 From: privacyfirst at xmail.net (privacyfirst) Date: Thu, 24 Apr 2014 13:34:02 -0700 Subject: OpenPGP Smartcard: How to generated (non-exportable) keys on the card? Message-ID: <20140424203402.2244E2C4EE7E@www.xmail.net> (The first attempt to send this message failed - so I'm resending it.) Hello, one of the features of OpenPGP v2 Smartcards is "Key generation on card". From this I would expect a high degree of security as the key is only stored on the smartcard and *never* touches the disk and therefore should not be able to be stolen without stealing the physical smartcard. I wanted to test this property. My goal was to generate a key that can not be exported (gpg --export-secret-key should not be possible). This is how I generated my keys: gpg2 --card-edit > admin > generate Make off-card backup of encryption key? (Y/n) --> n After keys were successfully generated I tried to run gpg2 --export-secret-keys --armor to verify that it is not possible to export private keys generated on the smartcard, but to my surprise it was possible and I got the private PGP key block. Is this expected? (this even works after removing the cardreader, so I assume the key is on the disk) I did not choose the wrong keyid as there is only one. How can I generate a non-exportable key safely on the card? thanks! My environment: - Ubuntu 14.04 with gnupg2 v2.0.22 - Smartcard Reader: http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=119 ------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------ From pete at heypete.com Thu Apr 24 22:59:27 2014 From: pete at heypete.com (Pete Stephenson) Date: Thu, 24 Apr 2014 22:59:27 +0200 Subject: OpenPGP Smartcard: How to generated (non-exportable) keys on the card? In-Reply-To: <20140424203402.2244E2C4EE7E@www.xmail.net> References: <20140424203402.2244E2C4EE7E@www.xmail.net> Message-ID: On Apr 24, 2014 10:35 PM, "privacyfirst" wrote: > > > (The first attempt to send this message failed - so I'm resending it.) > > Hello, > > one of the features of OpenPGP v2 Smartcards is "Key generation on card". > > From this I would expect a high degree of security as the key is only stored on the smartcard and *never* touches the disk and therefore should not be able to be stolen without stealing the physical smartcard. > > I wanted to test this property. > My goal was to generate a key that can not be exported (gpg --export-secret-key should not be possible). > > This is how I generated my keys: > > gpg2 --card-edit > > admin > > generate > Make off-card backup of encryption key? (Y/n) --> n > > > After keys were successfully generated I tried to run > > gpg2 --export-secret-keys --armor > > to verify that it is not possible to export private keys generated on the smartcard, but to my surprise it was possible and I got the private PGP key block. > Is this expected? (this even works after removing the cardreader, so I > assume the key is on the disk) > I did not choose the wrong keyid as there is only one. > > How can I generate a non-exportable key safely on the card? You have done everything correctly: the "private" key block you're seeing is a "stub" that tells GnuPG that the actual private key resides on a smartcard with a specific serial number (to distinguish it from other smartcards you might use for other keys). It does not contain any private data. If you were to go to a different system, import your public key (say, from a keyserver), insert your smartcard, and run "gpg --card-status" then GnuPG will automatically generate a new private key stub on that system so you could use the card. Cheers! -Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From cspitzer at godaddy.com Fri Apr 25 00:07:31 2014 From: cspitzer at godaddy.com (Charles Spitzer) Date: Thu, 24 Apr 2014 22:07:31 +0000 Subject: C# .dll availability? Message-ID: <8efe69c121a14cceaed67276bfc72efb@BLUPR02MB066.namprd02.prod.outlook.com> Greetings Is there a GnuPGP project anywhere that does PGP encryption that is usable in a C# application? I know I can execute commands at a command line to do this, but that would require the plaintext to reside on disk somewhere and I'd like to avoid that. I'd also like to avoid having to roll my own, not being sure that I'd get it right. Regards, Charlie Spitzer -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabriel.niebler at gmail.com Fri Apr 25 00:13:32 2014 From: gabriel.niebler at gmail.com (Gabriel Niebler) Date: Fri, 25 Apr 2014 00:13:32 +0200 Subject: UI terminology for calculated validities In-Reply-To: <5358D5B2.60705@digitalbrains.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> Message-ID: <53598C8C.4010007@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 24.04.2014 11:13, schrieb Peter Lebbing: > I think "authenticity" covers the overtones much better than > "validity", now that you mention it. It even makes me wonder why it > wasn't chosen in the first place :). You have convinced me that it > is the better term to use. Thank you very much! > I'm not enthousiastic about "ownership", because it feels like a > synonym to "User ID" in OpenPGP context. Yes, I simply posted both options that had occurred to me, but thinking a bit more about it I agree that "authenticity" is the better term. The word "ownership" only works with another word (established, confirmed, ascertained), because it is not a property of the UserID itself. I can't say a UserID "has ownership", it's the other way around. And the question is not "Who owns this UserID?", but rather "Who owns this key? Is it the entity behind this UserID?" - that's not nearly as clear as "Is this UserID authentic (for this key)?". Finally, speaking of computed, fractional values of ownership sounds weird, too. So yes, "authenticity" gets the point across better and would also work as a drop-in replacement of "validity". Cheers gabe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTWYyEAAoJEO7XEikU4kSz4EsIAJ/nUGES7nLxOkJeyJCeB9s6 tg3dt0d7S32cqXSetttGAproFIDu17wwNHT1Fq+zBRI/kuATy+SkwzDh/j5GCVy2 h5wpgXGJWLQJgpVg5K/4Xe8pHBR4L+C+2q7mbXD12gGyAEOOQDU9LmijNH4eLFSH jYLp7ndd8d867VgBoiOG/GGLhi19SGRn+cH0fbMkGsFuSGy3pDMMSB6JRcAAkza8 1t6LmcqCbXHNoXCdXVJ0ia23wkyPenGOe7qY9wlZwHS/X+kZOG60uLmmWzTtNVi+ tJ0hU9tre+6aUS9wyB1pv2iH1zFOnRFOkV5+2wUKJcI2ZI0q5retZgXSl5v9lSw= =BCq0 -----END PGP SIGNATURE----- From gabriel.niebler at gmail.com Fri Apr 25 00:19:12 2014 From: gabriel.niebler at gmail.com (Gabriel Niebler) Date: Fri, 25 Apr 2014 00:19:12 +0200 Subject: UI terminology for calculated validities In-Reply-To: <1397259291.20140424204510@my_localhost> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> <1397259291.20140424204510@my_localhost> Message-ID: <53598DE0.2060301@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Peter Lebbing has thankfully pointed out that, out of my two suggestions, "authenticity" is the word that should be preferred. I agree with him on this, so I shall use that word here. > A key on my keyring is "valid" if it is not expired or revoked and > it bears one signature from one of my keys, or several signatures > from other keys to which I have granted marginal authority to > validate keys. Yes, this is understood. I believe, however, that the above statement would be easier to grasp for novices if it were modified thus: """ A key on my keyring is "valid" if it is not expired or revoked. It is "authentic" if it bears one signature from one of my keys, or several signatures from other keys to which I have granted marginal authority to authenticate keys. """ This way, the word "valid" in the first sentence - for which a clear technical definition is given - still means what a novice user would expect it to mean, based on common usage. The word "authentic" in the second sentence is also defined in clear, technical terms, its meaning is also pretty much what one would expect. > "Valid" in this context means that my copy of GnuPG will accept it > as an encryption key. It is not necessarily related to the > purported identity of the person or persons who are thought to have > access to the corresponding private key. (I may, for example, > locally sign a key that works for exchanging with a particular > email address. That does not mean I have any clue who controls that > key or that email address.) That is true, but one could also use the word "authentic" in this case. I can consider some given key with some pseudonymous UserID "authentic", because I know that it works to communicate with this email address, whether I know the real identity behind the address or not. I note this "authenticity" to myself by a local signature on the key. GnuPG will only accept encryption keys that are both "valid" and "authentic". It all works and the meaning is a little clearer, IMO. >> Technically inclined people have a second association with the >> word "valid", (...), which naturally translates to (...)and, >> again, does NOT translate to the question of the key holder's >> true identity. (...) "True identity" was perhaps not the best turn of phrase to use, while trying not to repeat myself. I should have written "does NOT translate to the question whether the entity/entities controlling the key is/are indeed the one(s) represented by the UserID(s)". And I maintain that this is true for the second common usage of the word "valid" (as in XML etc.) > What is somebody's "true" identity? Many (or even most) people > have more than one identity, some long-lasting and others > ephemeral. A professional versus a personal identity. Multiple > social identities depending on context. A professional identity in > each of several occupations, either simultaneously or changing over > time. The name on their birth certificate versus the name by which > they are actually known. Etc. As far as keys are concerned it all boils down to the association between private key and UserID. This is understood. >> What makes it worse is that in the above examples, i.e. the cases >> people are familiar with, validity can usually be determined from >> the document itself (here that would be the key), or at worst the >> system that works with the document (here that would be GnuPG), >> but neither is the case with key ownership. > > GnuPG *can* inspect the signatures present on a key to determine > validity. Yes, but only if the user has already begun to build their WoT. It has been pointed out by other people in this same thread, that a) this will usually never be the case for novice users (unless the first thing they do is to maximally trust e.g. pgpca at ct.heise.de and they may be better advised to start by comparing fingerprints off-band with acquaintances) and b) some, maybe many, perhaps even most users may never get to the point of having a WoT large enough to be useful for this calculation. So as it is now, a new user finds they must (basically always) establish a keys "validity" themselves, when the expectation is that GnuPG should know whether a given key is "valid". This may frustrate some. (Real life examples are described by other people in the thread) Instead, if we used "validity" for expiration/revocation status, then we can explain "GnuPG always knows whether a given key is 'valid'* - as you would expect. It (usually) can't tell whether the key is 'authentic', though. You need to check that and tell GnuPG by making a signature." This is very easy to explain and understand, because it gels with people's expectations. And once new users have grasped this, they can be told that "GnuPG *can* inspect the signatures present on a key to determine authenticity." (This sentence could start the very next paragraph, or could be under "advanced topics") And then we explain the whole concept of the WoT. > Validity does not equate to ownership or identity. And neither does authenticity. Terms used in GnuPG _are_ technical terms and connotations will only get one so far. But at least the connotations can get one thinking in the right direction. >> Simply put, the word "validity" already means something to most >> people, but it was taken and redefined to mean something else in >> the context of asymmetric encryption keys > > No it was not. The key is "valid" by virtue of the signatures it > carries. It is a simple mechanism. Yes, it is a simple mechanism and the aim is not to change it. But why not say "The key is 'authentic' by virtue of the signatures it carries. It is 'valid' if it has not expired or been revoked."? >> - it's a bit like making a calculator and using the '+' sign for >> multiplication: it will do the correct thing and it's all in the >> manual, but it's still horribly confusing. > > Validity is just counting the relevant signatures. It only becomes > confusing when you consider the meaning of those signatures. In normal life, it is "authenticity", not "validity" that is established by signatures. A passport is authentic if the information contained in it (the bearer's UserID, to to speak) is correct, as witnessed by the signature of some official. The passport is valid if it has not expired or been marked/stamped/made invalid (i.e. revoked). The analogy is very clear. The question of "the meaning of signatures" is a different kettle of fish altogether and - yes - may also give rise to (a different kind of) confusion. That's not the topic of debate here. >> Therefore, I propose that the word "validity" is not chosen well >> for what it now means in GnuPG, because it carries with it >> connotations that are quite different from the intended meaning, >> which is confusing. And thus a better, clearer word should be >> found and used in future. Which word is obviously a matter for >> debate. > > I disagree. Validity in GnuPG is a perfectly clear descriptive > name for a simple, mechanistic concept. And "Authenticity" is an equally clear and additionally _intuitive_ descriptive name for the same simple, mechanistic concept. "Validity" naturally lends itself to the combination of expiration/revokation status, and should be used for that (if at all). >> Ad (a): A user wants to know whether the key they obtained is >> really _owned_ by the person whose UserID(s) came with it. > > Once the user establishes the question of > ownership/identity/control, they *could* then choose to validate > the key by signing it. But the choice is theirs alone: simply > knowing does not make their copy of GnuPG accept the key as > "valid." Obviously, no argument here. My knowledge who really controls a key would not make it "authentic" to GnuPG any more than it makes it "valid" now. Signatures are still required, this is well understood. >> My government issued passport is authentic and I own it, > > Mine says it remains the property of the government and may be > withdrawn at any time. So whoever uses the passport when they > travel, it is never the owner. Yes, I know. That's why official jargon uses the word "bearer". This is a technicality, though, I "own" it in the sense that is _my_ passport. A thief who stole it from me does not "own" it even in that sense, they merely possess it. "Ownership" is not such a good replacement for "validity" anyway, as stated in the beginning, so this is somewhat off topic now. Best gabe * Yes, GnuPG's information for determining "validity" in terms of revocation/expiration may be out of date. The key may have been revoked - thus be invalid - and GnuPG hasn't downloaded the revocation certificate yet. Or the key's expiration date may have been set to a later date, so it's still valid, but my GnuPG does not know this. This is beside the point, though, the intuitive understanding of "validity" in this context is still correct. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTWY3fAAoJEO7XEikU4kSz1lEIAK+jnPGbbOcuIJ3qogHotcFs uI5e601Honfbo32TDmxYLRIZdZzGb4HtAQ8qS/oJKj47iYbaK6hDHlof6/HiJLrK zGWuew1f9DCT2pkdlvGrAA6B074s3sCOK9ZM/C/eb6+WrOqhcIrO1P2aJPtHFP2l /e46Df6RF40kEl14IFFl8lNhyfmpgwOdvMH8okIPjZ+vdHgpBUa7d4tfyxmFdL7D 1IQpicfv1lVf59Bjk5R7qF7bTpvxkuXPA2zYJx3CVC33Un58MpYIzn3MAARFJzqw oRR5i/cRygA5zygi1vYZ5hJD//j/vLWD5KkvQYvkApNria1NQTtcYzYotmTvcKE= =qchO -----END PGP SIGNATURE----- From dougb at dougbarton.us Fri Apr 25 00:22:20 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 24 Apr 2014 15:22:20 -0700 Subject: UI terminology for calculated validities In-Reply-To: <53598C8C.4010007@gmail.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <53598C8C.4010007@gmail.com> Message-ID: <53598E9C.1070800@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Isn't what you're talking about "verification?" I think the concept of "validity" in PGP sort of implies that you have verified that the key is valid for that particular user/e-mail address, but wouldn't it be better to just say that explicitly? And apologies to anyone for whom English is not their first language if it seems like we're spending a lot of time trying to differentiate things that are very similar ... Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJTWY6cAAoJEFzGhvEaGryEqO0H/1DsVOao7a4abN5Ntw6OJfjM zOT2SHUK8XTU3PTlI7eRw6C1xQvRaFMh0x43W1g5UAiwbTR4JSQH328WonW8Z5a4 ZcGaK/zJgt6u8meKPz5uHBxvbJtqr/vMALC+U5lsvVyuoXJQjstafOdpJdEbf6rc 3fYYSLsBVuvqcJ7BzbxAPR/ignQndakBaXEXrgAlniBlyaSb22tRZclG7F139q2u MIGqnUX8j4NMVRuGg5wyWg+M+O9JBdqFmgToTC/EzmK++A/cIysOp/gOCg1Yh7MR LiNGFgSp5KmWB80YP+O6Q+suqaoA7dQ77vd/+oH1wberyrSXSnKnTFEf+F/g3Ls= =aIuh -----END PGP SIGNATURE----- From gabriel.niebler at gmail.com Fri Apr 25 01:10:15 2014 From: gabriel.niebler at gmail.com (Gabriel Niebler) Date: Fri, 25 Apr 2014 01:10:15 +0200 Subject: UI terminology for calculated validities In-Reply-To: <53598E9C.1070800@dougbarton.us> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <53598C8C.4010007@gmail.com> <53598E9C.1070800@dougbarton.us> Message-ID: <535999D7.7060601@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 25.04.2014 00:22, schrieb Doug Barton: > Isn't what you're talking about "verification?" To my mind, "verification" is the _process_ whereby the _properties_ like "validity" and "authenticity" are established*. I see a difference there, but one could absolutely use the word "verified" and "verification", of course. > I think the concept of "validity" in PGP sort of implies that you > have verified that the key is valid for that particular user/e-mail > address, but wouldn't it be better to just say that explicitly? Yes, it would. That's pretty much my whole point. "Validity" is misleading, because it's commonly associated with dates (valid from ... until ...) or a some sort of stamp that (in)validates something. In terms of GnuPG keys, this would translate more readily to expiration dates and revocation, so "validity" could be used for that (if at all). So if a UserID or key is listed as "validity unknown", new users scratch their heads. If instead GnuPG lists a UserID as "not verified" or with "authenticity unknown", then even most new users should understand more-or-less intuitively that they need to verify or authenticate the key (and, hopefully, why). And it also works in the WoT model, one just says something like "GnuPG can compute authenticity/verification from a key's signatures..." or "GnuPG can authenticate/verify a key based on its signatures...". > And apologies to anyone for whom English is not their first > language if it seems like we're spending a lot of time trying to > differentiate things that are very similar ... I thought a bit about other languages and I believe the issue is similar there. In German, validity translates to G?ltigkeit, authenticity to Echtheit or Authentizit?t, verification to Best?tigung or Beglaubigung and the connotations are very much the same as in English. I'm fairly confident that it will be similar in a great many languages (probably almost all Indo-European ones, at least). So if a slight change in language would make things clearer to English speakers, the corresponding change translated should also help speakers of other languages. Best gabe *: Say I received a key with my friend's UserID bound to it. I call them to _verify_ that it's actually the same key they generated and sent me by comparing fingerprints. With the _verification_ done (which did not involve any fiddling with bits), I know validate/authenticate the key by signing it (bit fiddling). Now the key is "valid"/"authentic" to GnuPG. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTWZnHAAoJEO7XEikU4kSzq0IIALWSMNjKBt66TZO1HUB0Dm/0 71aAX0Y57xDivPqga+Wn+FbBZ+EUVDbbIe26SWvRSuv6+hfzXh0dn3ooTZjm5XEu F6MjXBR/JR3RDZh0TljbfpR3UAPkgm/mORaLlOvx36vs1TqcuWaJoitl1HQuP1SW CjZYiN7othfcoGtsPgzXQsgc7tiCGt0f7wLC+4hnms+UyE6gsKy5Yr5IKryFa/qx DGMFMutwdpHHPi2Rxb+TnFfgcdUSn0G/tVMkW3HO4oPa8EnsWG252dWPf/EoZQX/ AR+rOgP9sDeb4kvCUKe3yNAL6OU8DikiTEg/EEBuoYk1ZZ4/0x97nGyByiDpjAc= =r/0G -----END PGP SIGNATURE----- From daniel at axtens.net Fri Apr 25 01:57:00 2014 From: daniel at axtens.net (Daniel Axtens) Date: Fri, 25 Apr 2014 09:57:00 +1000 Subject: GPG cannot import public key In-Reply-To: References: <030B5D79-04C4-480D-9063-72CEBF928FAC@jabberwocky.com> <23AB0733-EAA6-45BD-A483-4155DEA598BB@axtens.net> Message-ID: <09B0FAB1-3BE2-46D9-80FD-9AB6274B9842@axtens.net> > Please, re-read: > [4] Worse, they tried to export it again and we got this error: > # gpg --import /tmp/imps.asc > Ohhhh jeeee: ... this is a bug (sexp.c:1259:sexp_sscan) > Aborted > > Key #2 gives me that bizarre error on trying to import it. > Ah, sorry - I misunderstood your earlier email. I'm trying to compile a local version of GnuPG to poke around at it, but I'm having some trouble. I'll let you know if I make any further progress. Daniel > I do appreciate your analysis. I hope that a GPG developer can use it to advance gpg. > > > On Thu, Apr 24, 2014 at 11:02 AM, Daniel Axtens wrote: > Hi, > > I've had a look at the various keys in a OpenPGP compatible client I'm writing at the moment. All OpenPGP messages (including keys) are represented as a set of packets, and my code has just reached the stage of deserializing the packets and verifying some kinds of signatures, so it's good timing. Here's what I discovered: > > -- Key 1 -- > > Key 1 has the following raw packets: > Public Key Packet: "\EOTQ6V\DC3\ETX\b\NUL\204\175;i\239\167\241\198\156m\189\185\143 F*\DC3\227\NUL2\DLE\167\234\v"... (269 bytes), > User ID Packet: "Concerto Support Key Signature Packet: "\EOT\DLE\ETX\b\NUL\f\ENQ\STXQ6V\DC3\ENQ\t\ETX\194g\NUL\NUL\n\t\DLE\137~\233\185\132_Q\136\221\&8"... (290 bytes), > Public Subkey Packet: "\EOTQ6V\DC4\STX\b\NUL\209\RSK\214\183\188\162\t6\\Ic\135\174\205\EM\a\147\r\b]thO"... (269 bytes), > Signature Packet: "\EOT\CAN\ETX\b\NUL\f\ENQ\STXQ6V\DC4\ENQ\t\ETX\194g\NUL\NUL\n\t\DLE\137~\233\185\132_Q\136vR"... (290 bytes) > > Processing the packets, the public key reads as: > Public Key: Created: Tue Mar 5 20:31:15 UTC 2013, RSA Sign Only, 2048 bits, fingerprint: f6a721e7343193be840fc2ca897ee9b9845f5188 > > If I load the first signature, I see that it's a Version 4 Generic Certification Signature, made with an RSA Sign Only key having key ID 845f5188, and using a SHA256 hash. This is the signature that binds the user id and the public key, and it's valid, at least as verified by my code. > > Therefore, as far as I can tell, the RSA self-signature binding the UID to the public key is a valid signature. > > But that's not the end of the story. If you look at Section 9.1 of the OpenPGP RFC (RFC 4880), you'll see: > > "Implementations SHOULD implement RSA keys (1). RSA > Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be > generated, but may be interpreted. See Section 13.5." > > Section 13.5 says: > > "There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only > keys. These types are deprecated. The "key flags" subpacket in a > signature is a much better way to express the same idea, and > generalizes it to all algorithms. An implementation SHOULD NOT > create such a key, but MAY interpret it." > > So ultimately, both GPG 2 and the creators of the original key are correct. > It is a valid key, but it should not have been generated and GPG 2 may legitimately, and in full compliance with the RFC, refuse to recognise it. > I suspect the older version of GPG is more permissive and choses to accept it, although not being familiar with the code of either version, that's just speculation on my part. > > -- Key 2 -- > > Oddly, gpg2 crashes for me when trying to import this key. However, the code I'm writing works fine. > > The raw packets are: > Public Key Packet: "\EOTQ6V\DC3\ETX\b\NUL\204\175;i\239\167\241\198\156m\189\185\143 F*\DC3\227\NUL2\DLE\167\234\v"... (269 bytes), > User ID Packet: "Concerto Support Key Signature Packet: "\EOT\DLE\SOH\b\NULS\ENQ\STXSX\DC4\156\ENQ\t\NUL\NUL\NUL\NUL0\DC4\128\NUL\NUL\NUL\NUL \NUL\apref"... (361 bytes), > User ID Packet: "Josh Miller Signature Packet: "\EOT\DLE\SOH\STX\NULS\ENQ\STXSX\DC4\156\ENQ\t\NUL\NUL\NUL\NUL0\DC4\128\NUL\NUL\NUL\NUL \NUL\apref"... (361 bytes), > Public Subkey Packet: "\EOTQ6V\DC4\STX\b\NUL\209\RSK\214\183\188\162\t6\\Ic\135\174\205\EM\a\147\r\b]thO"... (269 bytes), > Signature Packet: "\EOT\CAN\SOH\b\NUL\f\ENQ\STXSX\DC3\251\ENQ\t\NUL\NUL\NUL\NUL\NUL\n\t\DLE\137~\233\185\132_Q\136\177\129"... (290 bytes) > > The public key is, oddly, the same - so it's not a new key, just a re-export of the old key: > Public Key: Created: Tue Mar 5 20:31:15 UTC 2013, RSA Sign Only, 2048 bits, fingerprint: f6a721e7343193be840fc2ca897ee9b9845f5188 > > The user ID (Concerto Support Key) is again bound with a Version 4 Generic Certification Signature. This time the signature claims to be made with RSA *Encrypt Or Sign* key ID 845f5188, and hash algorithm SHA256. You'll notice that's the same key ID as the public key - in other words, the signature simply _claims_ that the key it's made with is an Encrypt or Sign key, even though the Public Key itself claims to be a Sign Only key. > > The signature is valid according to my code. > > I suspect this is imported fine by your GPG 2 because GPG verifies the signature without checking if the type of key the signature claims it's made by matches the type of key found for that key ID. > (This works out fine in actual usage because RSA keys are all the same anyway - the distinction between Encrypt & Sign/Encrypt Only/Sign Only doesn't exist in the maths, it's added at the application level.) > > Interestingly, the key contains a binding between another user (Josh Miller) and the public key. This signature again lies about the type of the issuing key, although this one is made with SHA1 instead of SHA256. Again, the signature seems valid. > > -- Further remarks -- > > I should reiterate that I'm not fluent in GPG's code, so I'm only speculating as to the behaviour of GPG. > > You asked if it is possible to 'fix' the first key. As far as I can tell, you should just be able to use the second key: they both publish the same key and the user id <-> key binding you wanted. If you really wanted to, you could delete the second user id and signature after importing the key. > > Hope this helps, > Daniel > > > On 24/04/2014, at 11:15 PM, helices wrote: > > > Thank you, for your response. > > > > [1] > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > Version: Encryption Desktop 10.3.0 (Build 8741) > > > > mQENBFE2VhMDCADMrztp76fxxpxtvbmPIEYqE+MAMhCn6guYS31S9DVZyz/qP1zu > > 9hp+XBj69W5L1P02I+Cvk9kKkuuC3Hz/xkJZQVFOLeHu0s6ipl8TME71STw+ADdq > > Hj+FvxfkhlSwIlpIQAhb8zySbTJptME4kwoM1xASs+IjSWaOVHh/PkjgciV1p0rH > > gSW/xP2P4UH2A+ER93ItQNgp/oGY3u5puwKY1eV8Oy9hbCexlYxWvo7VSTYDumtM > > BqpMLv7yXmJUAe1LN/bIJYo87+Nr0CxVY5A9CCqAIxZy2JEkbTdI6mHLm3zb1Pn6 > > FiC42TLskruKlg2Zt8EVxrjeAlapAMbi55OPABEBAAG0NUNvbmNlcnRvIFN1cHBv > > cnQgS2V5IDxjb25jZXJ0by5zdXBwb3J0QGltcGFjdC1wcy5jb20+iQEiBBADCAAM > > BQJRNlYTBQkDwmcAAAoJEIl+6bmEX1GI3TgIAMHQbQA9XKw2e7Fl2IcI/wkG57oQ > > ve0m5/uzMEoruR4vbtwSW12f3Q4/bpokWDp617WqK0cCeec3wvDglsvXLBqHJPlo > > eKE8xp12eiw9qlEIk8oGpQ9BU5Bbxh0ORuu9EBRTo5mmqBZdfzRoeRVKYzMPCqFq > > 8ocBVdJ4NutTvEL0+58XUPFg4FOm1GHgbcRq6D8dMLO3vYj3w7wqloq45TdyRX/t > > I+ftQFsMBF1u4oJpQpErtsn49rVC5nK8rAodQfVY8pDWZM8VjKXk70U9w+e9AqHy > > X06TeKmjT8/fp/5iOUF90wftRnANkJQ4TOHH/neHlh4AVjz/cvvqz62O7ia5AQ0E > > UTZWFAIIANEeS9a3vKIJNlxJY4euzRkHkw0IXXRoT2NvfmC20fyTCrEWIoBGY/Pf > > KIr0WtMnoNem6K69D30nMPvuK7NZIEcf3c5k2KvD/p6GHZZVwnM8da/qvRmW+tFb > > h/W2PlOMBQpZh5Zd0o2Y/XvNmGz/agxOM9qhPj3ZysaKzy/prdx2ncHSUrvImnSH > > L8AtTVc0YtiI6qnhZFTivHpvAexrPUZ0/J2Qi2CL9pXTv/W5Mua1ec0HtCPTmI0g > > QMHcXMAhMdyrg0AQ4jlcS83Rhw6JoUQNEEuJcuuRyo6A/S0kxJuT5iZ1Za8JNoVm > > qOFJtASFz5wAHaAtOTuLJQe6EMaZkVEAEQEAAYkBIgQYAwgADAUCUTZWFAUJA8Jn > > AAAKCRCJfum5hF9RiHZSCADJ19g1ZR6mOCeUS95+NTf9TtGmoqB4ims0s8HqPOPh > > ihRdEEUoX16t+x8Vv6B6gF5zaeAmbMz1Mka41TFXgdgs3Y9HahXsiVKCoXJkrpKj > > LZFz+1fU/txCBZxf3il0JnfqY60qjdfJ5iq7iI0y7ClnjPfIHAE5j8VgrTgM+qIU > > +mpagibiiI7rdXNJF9hk+R5PwQrMLVLnLHq22lYcU3riGJMbRqWqXJJm6eSwxs4K > > Bsf+CKafoSiEKM8NrJGA9Dnd9HyeTCZTtlk92zfRh2zC0e/NCxdTlk2xy12ICoFG > > oeBxDq9N/8+Jbb9tQoFaOg3akr8WBKUaIRySEOky3GQJ > > =3RTl > > -----END PGP PUBLIC KEY BLOCK----- > > > > [2] Interestingly enough, importing this key with "gpg (GnuPG) 1.4.5" is successful: > > # gpg --import /tmp/imps.asc > > gpg: key 845F5188: public key "Concerto Support Key " imported > > gpg: Total number processed: 1 > > gpg: imported: 1 (RSA: 1) > > > > [3] After several attempts to export a usable public key, they created a NEW keypair using their Encryption Desktop 10.3.0, which is successful. Of course, since they claim to be using the original without incident with many other vendors, they want to "fix" their original keys. > > > > [4] Worse, they tried to export it again and we got this error: > > # gpg --import /tmp/imps.asc > > Ohhhh jeeee: ... this is a bug (sexp.c:1259:sexp_sscan) > > Aborted > > > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > Version: Encryption Desktop 10.3.0 (Build 8741) > > > > mQENBFE2VhMDCADMrztp76fxxpxtvbmPIEYqE+MAMhCn6guYS31S9DVZyz/qP1zu > > 9hp+XBj69W5L1P02I+Cvk9kKkuuC3Hz/xkJZQVFOLeHu0s6ipl8TME71STw+ADdq > > Hj+FvxfkhlSwIlpIQAhb8zySbTJptME4kwoM1xASs+IjSWaOVHh/PkjgciV1p0rH > > gSW/xP2P4UH2A+ER93ItQNgp/oGY3u5puwKY1eV8Oy9hbCexlYxWvo7VSTYDumtM > > BqpMLv7yXmJUAe1LN/bIJYo87+Nr0CxVY5A9CCqAIxZy2JEkbTdI6mHLm3zb1Pn6 > > FiC42TLskruKlg2Zt8EVxrjeAlapAMbi55OPABEBAAG0NUNvbmNlcnRvIFN1cHBv > > cnQgS2V5IDxjb25jZXJ0by5zdXBwb3J0QGltcGFjdC1wcy5jb20+iQFpBBABCABT > > BQJTWBScBQkAAAAAMBSAAAAAACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0Bw > > Z3AuY29tcGdwbWltZQgLCQgHAwIBCgUeAQAAAAYVCAoJAgMACgkQiX7puYRfUYga > > iQf/ZJ1d7dY2RdRjDzhXfarf7pPXRCFzRG32T8/i0AKL4YUW9hlaQqatrWw5DPe8 > > 2LBgCxFptJPgQ8N8nFJBWD6h/FVtUWa7k88we2MM/9oQn7d6v3pRaVxDUKfebCIn > > KqcR0k7ajdUMsGC3X+C6sjMh/Oy1/bI1EDUdFqcLq02kMcMSoDr5B2vpsRm8+tSs > > sSaoMujMmt17v4NkOzIyuOT8oyRPxFbeYszbaLpCjnZsbc1ktmpo3SkgNn8OBckt > > 0A6emPuIgy8tas+rxdmz+N3EWddt9FJz0r5DLCBAo9AUfzDBQnOrnGbvHuJuZH/t > > EFoJZyqTFgBa+RzkVYuPXVEbY7QnSm9zaCBNaWxsZXIgPGpvc2gubWlsbGVyQGlt > > cGFjdC1wcy5jb20+iQFpBBABAgBTBQJTWBScBQkAAAAAMBSAAAAAACAAB3ByZWZl > > cnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQgLCQgHAwIBCgUeAQAA > > AAYVCAoJAgMACgkQiX7puYRfUYid4Af/TzyXyapN59vqiyg7N0ejuQwcnM8Cp7HJ > > DyJtzw/KSK/6xrfEv5vRpW58OtNOy8sjpXGLHfzwh29DBOo/oe0djpz+G/arq6Bj > > JjcAAX9NaYB09rileHN/gw4X3W8FnIR4cZWbO/AwUpesSL75Sc8D/SbQ1i/Gstge > > hzo6d79SDJ6BFRURMDDe4n+kLOZSP3VtK9i3DQ+Bl+8tvzSjLGD+B/78VX+7QR57 > > +CzcRjNPQXQgvLdWkWGAYCXHzKZWx/RwTX6aFFFcIjm2s2zxZfunM+ajHt0sGZgT > > gnCtKmfRwTWTF7xlP6t2e1Zt9v+ykRmeMtYO5+IHjlwzjIDy5Ol+VrkBDQRRNlYU > > AggA0R5L1re8ogk2XEljh67NGQeTDQhddGhPY29+YLbR/JMKsRYigEZj898oivRa > > 0yeg16borr0PfScw++4rs1kgRx/dzmTYq8P+noYdllXCczx1r+q9GZb60VuH9bY+ > > U4wFClmHll3SjZj9e82YbP9qDE4z2qE+PdnKxorPL+mt3HadwdJSu8iadIcvwC1N > > VzRi2IjqqeFkVOK8em8B7Gs9RnT8nZCLYIv2ldO/9bky5rV5zQe0I9OYjSBAwdxc > > wCEx3KuDQBDiOVxLzdGHDomhRA0QS4ly65HKjoD9LSTEm5PmJnVlrwk2hWao4Um0 > > BIXPnAAdoC05O4slB7oQxpmRUQARAQABiQEiBBgBCAAMBQJTWBP7BQkAAAAAAAoJ > > EIl+6bmEX1GIsYEH/2IVbsvGGuSUSLU86sw0HhOxf/q3k8MG2JbrSwpCvdGkJcr4 > > jbDXwfUO1taDPx6pESZmB84OASIoJGt0e5KuxWdKa0YmsQA0qERp/Y9RJnGUUNsc > > KPVde6aw6KfR+QAEWH6gRoKBjTfjo101tVD1qCKIpDBDsS6Gg8ucGYTJcNU4AvoV > > +DgTfhzg7q/Whn97idP3biLG9EHyWznRgH00t1wl+yvlaZxY/K3a3X95cTA2zwh4 > > 2R0tJy0OzDQDyRjSfe8cT4cfH1k7WIrFb8FdXRAt3M3dtGRMvsHUM+rxxjsLEqGZ > > lN5nnltQiLMHkNdV/tgHCvArBSSaiuVLRYRk5sI= > > =i1to > > -----END PGP PUBLIC KEY BLOCK----- > > > > [5] As this is a new vendor relationship with my employer, and since we have automated processes for encrypting dozens of files every day, my ultimate goal is to have a public key from this vendor that works automatically, just like the hundreds of others that we have. That is to say, a signed public key that we can sign and to which we can assign trust, and that we can use to automatically encrypt and sign files that will be sent to them on a regular basis. Secondly, I understand and respect this vendor's desire to use one (1) key pair with all of their vendors. > > > > Can their original key be "fixed?" Why does legacy GPG accept that public key? > > > > I welcome all comments, suggestions and review. Thank you > > > > ~ helices > > > > > > On Wed, Apr 23, 2014 at 10:25 PM, David Shaw wrote: > > On Apr 23, 2014, at 11:14 PM, David Shaw wrote: > > > > > On Apr 23, 2014, at 3:24 PM, helices wrote: > > > > > >> No matter how I try, I cannot encrypt a file using that public key, even using --edit-key to assign trust: > > >> > > >> gpg: 845F5188: skipped: Unusable public key > > >> > > >> gpg: /tmp/test.txt: encryption failed: Unusable public key > > >> > > >> > > >> The owner of the public key insists that it is self-signed; but, our GPG cannot find the self-signature > > > > > > It doesn't look like it's self-signed, but without looking at the key itself, I couldn't say for sure. Is it posted anywhere on the net? > > > > > > In any event, you can override the check for encryption with the same flag you used to override the check on import. So: > > > > > > gpg -r 845F5188 --allow-non-selfsigned-uid -e the-file-i-am-encrypting-etc.txt > > > > I should add, though, that overriding these checks is something you should do with suitable verification of the key. Don't override the check unless you know what you're doing, and have assured yourself that the key you are encrypting to is really owned by the person/group that you believe it is. Those checks are there for a reason. > > > > David > > > > > > _______________________________________________ > > Gnupg-users mailing list > > Gnupg-users at gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From 2014-667rhzu3dc-lists-groups at riseup.net Fri Apr 25 02:23:50 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 25 Apr 2014 01:23:50 +0100 Subject: UI terminology for calculated validities In-Reply-To: <53598DE0.2060301@gmail.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> <1397259291.20140424204510@my_localhost> <53598DE0.2060301@gmail.com> Message-ID: <282631548.20140425012350@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 NotDashEscaped: You need GnuPG to verify this message Hi On Thursday 24 April 2014 at 11:19:12 PM, in , Gabriel Niebler wrote: > Peter Lebbing has thankfully pointed out that, out of > my two suggestions, "authenticity" is the word that > should be preferred. I agree with him on this, so I > shall use that word here. I don't personally like "authenticity" or "authentic" here but no sensible alternative suggestion comes to mind. "Authenticated" would better fit my understanding. >> GnuPG *can* inspect the signatures present on a key to >> determine validity. > Yes, but only if the user has already begun to build > their WoT. The presence of my local signature on a key allows GnuPG to determine validity, but could not be said to indicate I have started to build a WoT. > So as it is now, a new user finds they must (basically > always) establish a keys "validity" themselves, when > the expectation is that GnuPG should know whether a > given key is "valid". OK. The key is "valid" because it is not expired or revoked. If it bears no WoT signatures (and no exportable signatures from any of my keys), it seems wrong to say it is "authenticated." If it is only accepted by GnuPG due to my local signature, maybe a better word is "activated." > In normal life, it is "authenticity", not "validity" > that is established by signatures. In my experience it is commonplace for signatures to indicate either, depending on context. You sign a statement to the Police to indicate its authenticity. You sign a bank card to confer validity. (At least where I come from, above the signature strip on most bank cards it still says "not valid unless signed.") -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Of course it's a good idea - it's mine! -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNZqyxXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pXJkD/RCAH3/onr0XYVwglfgpyEdV6P19CqdjqfFJ iGNhFyBCpDXSl1XbBwTO8GcXmGnoCJsFw0TW9uyevGnOSkNFN4zvPvQSKwkM6mGV gnCnjSuIrPVQvyLtRzKq4qromAR+zpc/bPsVrH1VWBgXT5irZS4HR0CxluGR0/9q 5Dz3YfR2 =x+Jj -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Fri Apr 25 02:51:23 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 24 Apr 2014 20:51:23 -0400 Subject: C# .dll availability? In-Reply-To: <8efe69c121a14cceaed67276bfc72efb@BLUPR02MB066.namprd02.prod.outlook.com> References: <8efe69c121a14cceaed67276bfc72efb@BLUPR02MB066.namprd02.prod.outlook.com> Message-ID: <5359B18B.4090508@sixdemonbag.org> > Is there a GnuPGP project anywhere that does PGP encryption that is > usable in a C# application? Yes; gpgme-sharp. However, since it P/Invokes out to native code it's limited to 32-bit only. This may be a problem if your code has to run in a 64-bit .NET environment. From tim at piratemail.se Fri Apr 25 03:07:54 2014 From: tim at piratemail.se (tim at piratemail.se) Date: Thu, 24 Apr 2014 21:07:54 -0400 (EDT) Subject: best practice for pgp mail service, revoking keys Message-ID: <504f0a1d-8a03-ab33-4ad6-1fd7d275ffd8@piratemail.se> Thank you for your responses. I'm still mulling over what to do. Your input has been revealing. I think I'm leaning towards the 1 year key, with a 1 year "fallow" time. For the reasons implied by Daniel, (which I interpolated). I would not want another user grabbing an e-mail account and posing as a previous user. But at the same time, when a user renews a key, will the existing WoT signatures become invalid? If they do, perhaps it would be better to instead have the designated revoker (me) as described by David. If the co-signers don't become invalid, this seems strange to me. -- I have also been thinking about how this works into the WoT. Because, as Daniel and one other expressed, anyone can upload a key for a user. How to differentiate. I'm thinking to do this: 1. User registers, automagically creates pub/priv key. Tells me about pub key. I sign the pub key with the site key. All keys from the e-mail site will be self-signed and as well have the signature of the e-mail site key. 2. Users can "trust", or "be-friend" another email+key. When this happens they will sign the other's key, and will also mark that key as the prefered encryption key. Maybe that e-mail address will as well be placed on a white list of some sort. 3. The algorithm which picks the "best & default encryption key" for an address, will, instead of picking the key with the latest date (which it does now), will pick the key with the most number of co-signers. (and of course which isn't revoked, or expired) Does this sound about right? In existing gpg mail programs, when evaluating the trust level a key, does gpg see if there is a path between yourself and that key, "I didn't sign it, but this other key which I already trust, signed this other key, which signed the key I'm looking at." Or do you count signatures. Or both? -tim From robertc at broadcom.com Fri Apr 25 03:11:13 2014 From: robertc at broadcom.com (Bob (Robert) Cavanaugh) Date: Fri, 25 Apr 2014 01:11:13 +0000 Subject: UI terminology for calculated validities In-Reply-To: <535999D7.7060601@gmail.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <53598C8C.4010007@gmail.com> <53598E9C.1070800@dougbarton.us> <535999D7.7060601@gmail.com> Message-ID: <8F0B09FC6339FA439524099BFCABC11F2D311B1D@IRVEXCHMB11.corp.ad.broadcom.com> Hi, My vote is to adopt Gabe's convention. I think it makes a great deal of sense. Thanks, Bob Cavanaugh -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Gabriel Niebler Sent: Thursday, April 24, 2014 4:10 PM To: Doug Barton; Peter Lebbing; gnupg-users at gnupg.org Subject: Re: UI terminology for calculated validities * PGP Signed by an unknown key Am 25.04.2014 00:22, schrieb Doug Barton: > Isn't what you're talking about "verification?" To my mind, "verification" is the _process_ whereby the _properties_ like "validity" and "authenticity" are established*. I see a difference there, but one could absolutely use the word "verified" and "verification", of course. > I think the concept of "validity" in PGP sort of implies that you > have verified that the key is valid for that particular user/e-mail > address, but wouldn't it be better to just say that explicitly? Yes, it would. That's pretty much my whole point. "Validity" is misleading, because it's commonly associated with dates (valid from ... until ...) or a some sort of stamp that (in)validates something. In terms of GnuPG keys, this would translate more readily to expiration dates and revocation, so "validity" could be used for that (if at all). So if a UserID or key is listed as "validity unknown", new users scratch their heads. If instead GnuPG lists a UserID as "not verified" or with "authenticity unknown", then even most new users should understand more-or-less intuitively that they need to verify or authenticate the key (and, hopefully, why). And it also works in the WoT model, one just says something like "GnuPG can compute authenticity/verification from a key's signatures..." or "GnuPG can authenticate/verify a key based on its signatures...". > And apologies to anyone for whom English is not their first > language if it seems like we're spending a lot of time trying to > differentiate things that are very similar ... I thought a bit about other languages and I believe the issue is similar there. In German, validity translates to G?ltigkeit, authenticity to Echtheit or Authentizit?t, verification to Best?tigung or Beglaubigung and the connotations are very much the same as in English. I'm fairly confident that it will be similar in a great many languages (probably almost all Indo-European ones, at least). So if a slight change in language would make things clearer to English speakers, the corresponding change translated should also help speakers of other languages. Best gabe *: Say I received a key with my friend's UserID bound to it. I call them to _verify_ that it's actually the same key they generated and sent me by comparing fingerprints. With the _verification_ done (which did not involve any fiddling with bits), I know validate/authenticate the key by signing it (bit fiddling). Now the key is "valid"/"authentic" to GnuPG. * Unknown Key * 0x14E244B3(L) _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From mailinglisten at hauke-laging.de Fri Apr 25 04:49:30 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 25 Apr 2014 04:49:30 +0200 Subject: UI terminology for calculated validities In-Reply-To: <5358D5B2.60705@digitalbrains.com> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> Message-ID: <1691426.OzBBnA61Yg@inno> Am Do 24.04.2014, 11:13:22 schrieb Peter Lebbing: > I think "authenticity" covers the overtones much better than > "validity", now that you mention it. It even makes me wonder why it > wasn't chosen in the first place :). You have convinced me that it is > the better term to use. > > I'm not enthousiastic about "ownership", because it feels like a > synonym to "User ID" in OpenPGP context. I second that. "Ownership" is much to close to "ownertrust". But I would also point out that "authenticity" sound very much like "this key is authentic" which is a problem for at least two reasons: a) Many keys are certified without being verified. This is IMHO not so much a problem if this is transparent. Think of --ask-cert-level. BTW: I really don't like the --min-cert-level default to be 2 because this forces the users to either ignore this level (setting 0) or to "lie" which also reduces the "authenticity". b) There are user IDs with which it becomes strange to speak of "authenticity". E.g. if it is only an email address (sevgseuiuzh at example.org). Certifying a key (especially if locally only) is more a technical decision than a proof of "authenticity. But I doubt that "validity" vs. "authenticity" makes a difference in this regard. The German term for valid does not sound like that to me. Thus I would like to offer "accepted" as a possible alternative. I guess that shows the user decision. Maybe even as a combination: "authenticity accepted". Another point: Is it a good idea to use the same terms for both the key itself and user IDs? The terminology should make sense to non-technical people especially from the perspective that a "valid" key (certificate) can contain "invalid" user IDs. As different keys (especially fake ones) can contain exactly the same user ID it seems strange to me to apply the term "authenticity" to a user ID. The key is authentic for this user ID (in contrast to other keys which may have the same). Even worse: Even an invalid (but formerly valid) key is still "authentic". At least from my understanding of language. "Accepted" does not have this problem (neither "valid"). We could say: An accepted user ID makes a key valid. Certain additional steps during accepting (certifying) ? like --ask-cert-level or (yet to be defined) signature notations ? MAY make the key not only "valid" (technical part) but also "authentic" (organizational part). In order to help people use crypto right the terminology should help the people become aware of important differences ? like validity and authenticity. Speaking of "authenticity" only may support the creation of an illusion of security. Maybe we are not even the right group to discuss that. Maybe that should be discussed by new users after being told about the technical and organizational states which the language shall easily understandably represent. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From dougb at dougbarton.us Fri Apr 25 06:19:28 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 24 Apr 2014 21:19:28 -0700 Subject: UI terminology for calculated validities In-Reply-To: <1691426.OzBBnA61Yg@inno> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> Message-ID: <5359E250.8090809@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/24/2014 07:49 PM, Hauke Laging wrote: | Thus I would like to offer "accepted" as a possible alternative. I guess | that shows the user decision. Maybe even as a combination: "authenticity | accepted". Did you not like my suggestion of "verified?" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJTWeJQAAoJEFzGhvEaGryEhWQH/im5o2UG9Go+FvdvexpvADa/ 5tz0LZ6JVYzUNc0698c6QyoXYHvYonfCBznj5khmV9R89TxHujkDUuUZ9CiaYCOh Ls1Qa0yxNrhfdW/whfIRvdED+iCAfljLnMEJyY0PgqqnRVNj36qixC4ZqVa0277P R12rMIeO5ieQ2kO7r4MDIm4fd/boUY1HDHKNtAbIpJ4hjyIVnxmWi/gP1ZhWw7bt 0XNAEhaop9resyA1I0KAgTtL9Wx5JA3uVPnaTrsoJkQXsgDOAS0Glcd/sM0h6bnv 0E6JBHmEHlpWsM5JhGxZodRXlfD0GV8gdMS6D7RC3FHmeVgsbT8oZxhPHtliqXs= =9ind -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Fri Apr 25 06:38:15 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 25 Apr 2014 06:38:15 +0200 Subject: UI terminology for calculated validities In-Reply-To: <1132800573.20140423203227@my_localhost> References: <53564380.10000@josuttis.de> <5356EF6C.30201@fifthhorseman.net> <1132800573.20140423203227@my_localhost> Message-ID: <1619717.pObFgkP320@inno> Am Mi 23.04.2014, 20:32:27 schrieb MFPA: > Say a user has two keys, 0x0123456789abcdef and 0xfedcba9876543210. I > propose each key could sign the other with a signature notation > something like:- > siblings-0x0123456789abcdef-0xfedcba9876543210 at example.org. a) You always want to use fingerprints instead. b) You do not need any reference to a key anyway because it is absolutely clear which keys this statement refers to if one key signs another. c) I would like to handle that with an generic notation. I see a strong need for an expression about the relation of the signer to the owner of the signed key. It makes a big difference whether I say "This is some foreigner which has shown me some ID (see separate notation for details)" or "This is my sister". Thus I would like to have a notation "relation@" which would in this case have a value like "identity" or "self", maybe with some additional information like "self: business". Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Fri Apr 25 06:43:27 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 25 Apr 2014 06:43:27 +0200 Subject: UI terminology for calculated validities In-Reply-To: <53598E9C.1070800@dougbarton.us> References: <53564380.10000@josuttis.de> <53598C8C.4010007@gmail.com> <53598E9C.1070800@dougbarton.us> Message-ID: <2950043.2nq8QHs4Oz@inno> Am Do 24.04.2014, 15:22:20 schrieb Doug Barton: > Isn't what you're talking about "verification?" I think the concept of > "validity" in PGP sort of implies that you have verified that the key > is valid for that particular user/e-mail address, but wouldn't it be > better to just say that explicitly? That's exactly the problem: If you say something explicitly which is not always the case then you must not make this explicit statement the only possible one. Many keys get signed without being verified. IMHO this forbids calling valid keys "verified keys". Verification is a subset of accepting. I would really like to make "verification" part of this terminology but only as an optional part, clearly telling "accepted keys" and "accepted and verified keys" apart. Otherwise we just create the next problem. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From vmaatta at asatiifm.net Fri Apr 25 00:42:53 2014 From: vmaatta at asatiifm.net (=?iso-8859-1?Q?Ville_M=E4=E4tt=E4?=) Date: Fri, 25 Apr 2014 01:42:53 +0300 Subject: C# .dll availability? In-Reply-To: <8efe69c121a14cceaed67276bfc72efb@BLUPR02MB066.namprd02.prod.outlook.com> References: <8efe69c121a14cceaed67276bfc72efb@BLUPR02MB066.namprd02.prod.outlook.com> Message-ID: <60F2492E-0CD0-4348-847A-34488EE876AD@asatiifm.net> Howdy, Likely something GPGME (http://www.gnupg.org/related_software/gpgme). Signs point to gpgme-sharp, although it seems a bit inactive, someone more knowledgeable correct me if there?s a better option. https://github.com/danm-de/gpgme-sharp http://stackoverflow.com/questions/4156819/using-the-gpgme-library-from-net -- Ville M??tt? On 25 Apr 2014, at 01:07, Charles Spitzer wrote: > Greetings > > Is there a GnuPGP project anywhere that does PGP encryption that is usable in a C# application? I know I can execute commands at a command line to do this, but that would require the plaintext to reside on disk somewhere and I?d like to avoid that. I?d also like to avoid having to roll my own, not being sure that I?d get it right. > > Regards, > Charlie Spitzer > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailtosara at hotmail.com Fri Apr 25 08:41:26 2014 From: mailtosara at hotmail.com (Saravana S) Date: Fri, 25 Apr 2014 06:41:26 +0000 Subject: GPGSM with x.509 Certificate Message-ID: Hello, I have created a self signed certificate(x.509) from the site http://www.cert-depot.com/ and imported it to GnuPG. Then I tried to encrypt a file using the imported x.509 certificate, I got an error "Line too long". Couldn't get much details from forums. Please share your ideas/suggestions on this. Thanks, Saravanan S -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Fri Apr 25 11:15:40 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 25 Apr 2014 11:15:40 +0200 Subject: UI terminology for calculated validities In-Reply-To: <53598DE0.2060301@gmail.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> <1397259291.20140424204510@my_localhost> <53598DE0.2060301@gmail.com> Message-ID: <535A27BC.40602@digitalbrains.com> On 25/04/14 00:19, Gabriel Niebler wrote: > And "Authenticity" is an equally clear and additionally _intuitive_ > descriptive name for the same simple, mechanistic concept. > "Validity" naturally lends itself to the combination of > expiration/revokation status, and should be used for that (if at all). I don't think a UI should use both "authentic*" (~ated, ~ity, etc) and "valid*", because this might not be confusing to newcomers, it would definitely be for people who already know what "valid" means in OpenPGP context. I think it's preferable to replace "valid" by "authentic" because it conveys the meaning better, but you definitely shouldn't then call /something else/ "validity". HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Fri Apr 25 11:20:08 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 25 Apr 2014 11:20:08 +0200 Subject: UI terminology for calculated validities In-Reply-To: <1691426.OzBBnA61Yg@inno> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> Message-ID: <535A28C8.8050104@digitalbrains.com> On 25/04/14 04:49, Hauke Laging wrote: > Another point: > Is it a good idea to use the same terms for both the key itself and user > IDs? What do you mean? Validity (and it's proposed new form, authenticity) refers to the coupling of a key and a User ID. It doesn't refer to either thing by itself. Does it? Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Fri Apr 25 11:57:09 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Apr 2014 11:57:09 +0200 Subject: GPG cannot import public key In-Reply-To: <184B57B5-061B-46F0-818A-F69489568C33@jabberwocky.com> (David Shaw's message of "Thu, 24 Apr 2014 13:55:07 -0400") References: <030B5D79-04C4-480D-9063-72CEBF928FAC@jabberwocky.com> <184B57B5-061B-46F0-818A-F69489568C33@jabberwocky.com> Message-ID: <877g6dohoq.fsf@vigenere.g10code.de> On Thu, 24 Apr 2014 19:55, dshaw at jabberwocky.com said: > I'm afraid I don't have immediate access to the GPG 2.x code base to check, but I wonder if your problem is simply that 2.x doesn't accept RSA_S and RSA_E keys? There is indeed a bug related to the use of RSA_S and RSA_E if GnuPG 2.0 is used with Libgcrypt 1.6. It is fixed in the repos and I consider to do a new libgcrypt release soon (we can fix it at both places). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lionel at mamane.lu Fri Apr 25 12:16:25 2014 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Fri, 25 Apr 2014 12:16:25 +0200 Subject: C# .dll availability? In-Reply-To: <8efe69c121a14cceaed67276bfc72efb@BLUPR02MB066.namprd02.prod.outlook.com> References: <8efe69c121a14cceaed67276bfc72efb@BLUPR02MB066.namprd02.prod.outlook.com> Message-ID: <20140425101625.GA9857@capsaicin.mamane.lu> On Thu, Apr 24, 2014 at 10:07:31PM +0000, Charles Spitzer wrote: > Is there a GnuPGP project anywhere that does PGP encryption that is > usable in a C# application? I know I can execute commands at a > command line to do this, but that would require the plaintext to > reside on disk somewhere and I'd like to avoid that. I'd also like > to avoid having to roll my own, not being sure that I'd get it > right. Assuming C# can call (use) a C library, there is http://www.gnupg.org/related_software/gpgme/ -- Lionel From schalox at gmail.com Fri Apr 25 13:21:31 2014 From: schalox at gmail.com (schalox) Date: Fri, 25 Apr 2014 14:21:31 +0300 Subject: List file's encryption keys with --with-colons? Message-ID: <20140425112130.GA6324@hoth> Hi, When using --list-keys, you can do this: gpg --list-keys --with-colons "${GPG_RECIPIENTS[@]}" | grep '^sub:' | cut -d ':' -f 5 | sort -u Can you do the same with --list-only to get the (long versions of) encryption keys in a colon-separated output? Currently we're using this: gpg -v --list-only --keyid-format long "$file" 2>&1 | cut -d ' ' -f 5 | sort -u We know of FAQ's method[0], but we'd like to know if there's a better way to do this. [0] http://www.gnupg.org/faq/GnuPG-FAQ.html#how-can-i-get-list-of-key-ids-used-to-encrypt-a-message From schalox at gmail.com Fri Apr 25 14:28:22 2014 From: schalox at gmail.com (schalox) Date: Fri, 25 Apr 2014 15:28:22 +0300 Subject: List file's encryption keys with --with-colons? Message-ID: <20140425122822.GA11957@hoth> Hi, When using --list-keys, you can do this: gpg --list-keys --with-colons "${GPG_RECIPIENTS[@]}" | grep '^sub:' | cut -d ':' -f 5 | sort -u Can you do the same with --list-only to get the (long versions of) encryption keys in a colon-separated output? Currently we're using this: gpg -v --list-only --keyid-format long "$file" 2>&1 | cut -d ' ' -f 5 | sort -u We know of FAQ's method[0], but we'd like to know if there's a better way to do this. [0] http://www.gnupg.org/faq/GnuPG-FAQ.html#how-can-i-get-list-of-key-ids-used-to-encrypt-a-message From mwood at IUPUI.Edu Fri Apr 25 15:12:00 2014 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Fri, 25 Apr 2014 09:12:00 -0400 Subject: UI terminology for calculated validities In-Reply-To: <535999D7.7060601@gmail.com> References: <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <53598C8C.4010007@gmail.com> <53598E9C.1070800@dougbarton.us> <535999D7.7060601@gmail.com> Message-ID: <20140425131200.GA22122@IUPUI.Edu> German and English have been closely related for many centuries. But I've been trying to make sense of the terms using the *other* half of English, since so many of these words seem to have Latin roots. Valid: having value; acceptable for certain transactions. A bank draft is valid if it identifies an actual bank, identifies an actual account at that bank, is signed in the appropriate place by an appropriate person, is not too old, and has other correct corroborating information. Verified: tested and found truthful. A bank draft is verified if you ask the purported issuer and he agrees that he issued it, or trusted records show that he did, for that account and in that amount and to that payee. Authentic: properly associated with the entity which it claims; genuine. A bank draft is authentic if it was issued by the person named in the signature and other marks. It is typically authenticated by comparing the signature sample on the draft to a trusted signature sample, either already on file or executed by the named person in the presence of the authenticator. (Apparently Latin borrowed this one from Greek.) Is that of any help at all? -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Machines should not be friendly. Machines should be obedient. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mwood at IUPUI.Edu Fri Apr 25 15:23:54 2014 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Fri, 25 Apr 2014 09:23:54 -0400 Subject: UI terminology for calculated validities In-Reply-To: <535A28C8.8050104@digitalbrains.com> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> <535A28C8.8050104@digitalbrains.com> Message-ID: <20140425132354.GB22122@IUPUI.Edu> What about abandoning terms of art and just saying things more simply: "This message was signed by key AAAAAAAA. You have indicated that you trust that key." -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Machines should not be friendly. Machines should be obedient. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Fri Apr 25 18:47:46 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 25 Apr 2014 12:47:46 -0400 Subject: UI terminology for calculated validities In-Reply-To: <1619717.pObFgkP320@inno> References: <53564380.10000@josuttis.de> <5356EF6C.30201@fifthhorseman.net> <1132800573.20140423203227@my_localhost> <1619717.pObFgkP320@inno> Message-ID: <535A91B2.90602@fifthhorseman.net> On 04/25/2014 12:38 AM, Hauke Laging wrote: > Am Mi 23.04.2014, 20:32:27 schrieb MFPA: > >> Say a user has two keys, 0x0123456789abcdef and 0xfedcba9876543210. I >> propose each key could sign the other with a signature notation >> something like:- >> siblings-0x0123456789abcdef-0xfedcba9876543210 at example.org. > > a) You always want to use fingerprints instead. > > b) You do not need any reference to a key anyway because it is > absolutely clear which keys this statement refers to if one key signs > another. > > c) I would like to handle that with an generic notation. I see a strong > need for an expression about the relation of the signer to the owner of > the signed key. It makes a big difference whether I say "This is some > foreigner which has shown me some ID (see separate notation for > details)" or "This is my sister". Thus I would like to have a notation > "relation@" which would in this case have a value like "identity" or > "self", maybe with some additional information like "self: business". with the possible exception of "self" indications, which i can see as useful for key transitions and multi-key-holding individuals, i don't want to see any of these other relationships embedded in the network of identity certifications which are published. The social graph exposed by the public keyservers is rich enough to be useful for networked identity certifications, but no richer. it should stay that way, since rich published social graphs can be used against their participants, and it's not clear how to use the additional relationship information in an effective way. There are many other ways that people can decide how and whether to publish their relationships with other people. I don't think folding this additional complexity into OpenPGP identity certifications is going to make the identity certifications any easier to use or understand. let's keep it simple, and minimize the amount of social graph leakage. --dkg PS MFPA's original idea of using a notation to link two primary keys is interesting, and i see how it could be useful, but i don't think it belongs in the public keyservers either. Perhaps something like that (using full fingerprints, as hauke suggests) could be made by a non-exportable certification directly on the primary key itself (not over User IDs). But this should only be done if there is an algorithm in place to make use of this information. Anyone implementing this kind of cleanup should probably start simpler and just handle the identical-valid-user-id case first. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Apr 25 18:58:03 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 25 Apr 2014 12:58:03 -0400 Subject: UI terminology for calculated validities In-Reply-To: <1691426.OzBBnA61Yg@inno> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> Message-ID: <535A941B.60807@fifthhorseman.net> On 04/24/2014 10:49 PM, Hauke Laging wrote: > a) Many keys are certified without being verified. This is IMHO not so > much a problem if this is transparent. Think of --ask-cert-level. BTW: I > really don't like the --min-cert-level default to be 2 because this > forces the users to either ignore this level (setting 0) or to "lie" > which also reduces the "authenticity". yes, users *should* ignore --ask-cert-level: https://www.debian-administration.org/users/dkg/weblog/98 > b) There are user IDs with which it becomes strange to speak of > "authenticity". E.g. if it is only an email address > (sevgseuiuzh at example.org). why is this strange? a certificate that binds a key to an e-mail address is authentic iff the owner of that e-mail account controls that key. > Thus I would like to offer "accepted" as a possible alternative. I guess > that shows the user decision. Maybe even as a combination: "authenticity > accepted". Accepted implies that there is someone doing the accepting. "Acceptable" might be better, but it still leaves me asking "acceptable to whom?" and "acceptable for what?" -- if it's in a context where it's obvious that the answer is "acceptable for me to encrypt messages to it, or to verify message signatures from it" then that might not be too bad. > Another point: > Is it a good idea to use the same terms for both the key itself and user > IDs? The terminology should make sense to non-technical people > especially from the perspective that a "valid" key (certificate) can > contain "invalid" user IDs. i agree that this is confusing. It also confuses people that we continue to call certificates "keys", and then sometimes we actually want to talk about the keys themselves, and also call those "keys" > As different keys (especially fake ones) can contain exactly the same > user ID it seems strange to me to apply the term "authenticity" to a > user ID. The key is authentic for this user ID (in contrast to other > keys which may have the same). the term would need to apply to the combination, not to the userid in isolation. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Apr 25 19:02:05 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 25 Apr 2014 13:02:05 -0400 Subject: UI terminology for calculated validities In-Reply-To: <20140425132354.GB22122@IUPUI.Edu> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> <535A28C8.8050104@digitalbrains.com> <20140425132354.GB22122@IUPUI.Edu> Message-ID: <535A950D.3060604@fifthhorseman.net> On 04/25/2014 09:23 AM, Mark H. Wood wrote: > What about abandoning terms of art and just saying things more simply: > "This message was signed by key AAAAAAAA. You have indicated that you > trust that key." trust that key to do what? to belong to some mystery person? to make valid OpenPGP signatures? to send you good stock tips? to be a reliable source of cryptographically-signed tasty noodle casserole recipes? to be controlled in an operationally secure fashion? to have been created on the date it claims to have been created? we're all aiming for clarity and simplicity here, but using a simple ambiguous term when we need to distinguish at least two very specific cases from each other and from many other meanings of the word "trust" seems like a recipe for failure (instead of noodle casserole). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Apr 25 21:07:23 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 25 Apr 2014 15:07:23 -0400 Subject: UI terminology for calculated validities In-Reply-To: <53598DE0.2060301@gmail.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> <1397259291.20140424204510@my_localhost> <53598DE0.2060301@gmail.com> Message-ID: <535AB26B.2060804@fifthhorseman.net> On 04/24/2014 06:19 PM, Gabriel Niebler wrote: > """ > A key on my keyring is "valid" if it is not expired or revoked. > It is "authentic" if it bears one signature from one of my keys, or > several signatures from other keys to which I have granted marginal > authority to authenticate keys. > """ I can see that "authenticity" is in some ways more appealing as a term than "validity". But i agree with Peter that trying to redefine "validity" to then mean something else is likely to be asking for trouble, given the existing established terminology. I also wonder what term you would propose using as the opposite of "authentic". "valid" can be opposed cleanly with "invalid". Would you say "inauthentic" or "unauthenticated"? I prefer the latter term, but in that case, perhaps the positive version should be "authenticated" rather than "authentic". Also, i think it is a problem to say a key is valid or authentic. It is not the key that is valid or authentic, it is the combination of the key and a given user ID. An OpenPGP certificate as a whole contains one master key and one or more User IDs. So the certificate itself may contain some valid/authentic combinations, and some invalid/unauthenticated combinations. In some scenarios, you want to talk about the certificate as a whole, and sometimes people want to make assertions about the validity or authenticity of the certificate itself, even though it may be in this mixed state. For example, when a user applies ownertrust to a given certification-capable master key, GnuPG still only relies on certifications made by that key if the certificate containing the key has at least one valid combination. So in some sense, GnuPG considers a certificate as a whole (and by implication, its primary key) as though it it has a validity by taking the maximum of the validity of all of the certificate's user IDs. I'm not proposing that we expose this detail to the end user, though, just laying out to the detail-oriented people on this list so that we have a common understanding. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From ei8fdb at ei8fdb.org Fri Apr 25 19:43:53 2014 From: ei8fdb at ei8fdb.org (Bernard Tyers) Date: Fri, 25 Apr 2014 18:43:53 +0100 Subject: UI terminology for calculated validities In-Reply-To: <535A950D.3060604@fifthhorseman.net> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> <535A28C8.8050104@digitalbrains.com> <20140425132354.GB22122@IUPUI.Edu> <535A950D.3060604@fifthhorseman.net> Message-ID: <535A9ED9.4010101@ei8fdb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/04/2014 18:02, Daniel Kahn Gillmor wrote: > On 04/25/2014 09:23 AM, Mark H. Wood wrote: >> What about abandoning terms of art and just saying things more >> simply: "This message was signed by key AAAAAAAA. You have >> indicated that you trust that key." > > trust that key to do what? to belong to some mystery person? to > make valid OpenPGP signatures? to send you good stock tips? to be > a reliable source of cryptographically-signed tasty noodle > casserole recipes? to be controlled in an operationally secure > fashion? to have been created on the date it claims to have been > created? > > we're all aiming for clarity and simplicity here, but using a > simple ambiguous term when we need to distinguish at least two very > specific cases from each other and from many other meanings of the > word "trust" seems like a recipe for failure (instead of noodle > casserole). > > --dkg Hi all, Nicolai: I am very glad you've started this thread. At the risk of being flamed, can I suggest asking the users what they think? Nicolai, by the look of it you've carried out some user research. I guess so by the "real world" discussion you posted in a message. If you did can I ask what you focused on? Did you look for suggestions from users? I have read some HCI research into non-expert user understanding of PGP. If there wasn't user research done, can I suggest doing some? With the utmost respect to the list members, you (we) are not non-expert users, and so our opinions really don't matter. The focus of Nicolai's question is *non-expert*, so we need to get their opinions. Suggestions? Arguments? Bernard -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTWp7YAAoJELXSUVrcWJJg5YgP/0OnnyWh4oG04skYeCEulrKE DOTg6vtiIU6JY32Wlg+uVQsvwVNcBBQ8xG6qGgivALKk4iF/GD1C0vonLC2tmx2m +GQq1daRV+hVF5k8njTyPFQlHjOFQvEc/QcdSfBSi4UZ0BF5BIySNRh75uptxVmd 1c9mdMLhqHjAHUIIKVh0ZUb4BhDB4TwF1GLifXq6mLdXb2ovXkFCfJHSgKHWKlHD IeNcckNANqBNPg0t3fLX+DvWPnd5mW3v5qXL5Kwb0lFpf2RSDwz2unioqB9yt0bC eIUKcMxZcaSl/UWglIqziv/I7WODC41RKf5hBf2MchPD+6ja+ClwU1vxd0FzbBst drOCx9R18vB814s/DIlCeyEZLyuJTwoFOph6SKHCR1ZQ1esELAwwQuFqQ+yNFCv3 qsmws6wCAG3I/GcGhvaYudVM06mtzodwQZge2QPSz31/rGsQ4n9hb7uJLZlHeEGM zIG0doQSmCj8XSMroitrD9GhVonBj0X9tuvxHfk/CQd8dmqsgiGgb1DvayL5u3pM bfcqx4FFv7J2CHuwnCXys9Z+mVCJJyMCh9XI6CtUtdWKAQNS4zZjuv82lCWLceh0 ISda562n5U6iFpi0US3hT8pB+iecadgMefux2MwiAaUhClTlVIaA1qJteMtrht7B 6WPLQXZriPGr/SzUdadY =SHCp -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Fri Apr 25 21:14:49 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 25 Apr 2014 15:14:49 -0400 Subject: UI terminology for calculated validities In-Reply-To: <5356F230.3010608@josuttis.de> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> Message-ID: <535AB429.1050008@fifthhorseman.net> On 04/22/2014 06:50 PM, Nicolai Josuttis wrote: > me: you either can sign the key > or trust somebody else who signed the key > (such as pgpca at ct.heise.de) > he: Oh, I even registered my email/key there > but what else is missing? > me: load the key for pgpca at ct.heise.de > he: done, but trust is still missing > me: oh, yes, you also have to express trust for this key/owner > Then it worked ... did he understand the other consequences of setting ownertrust for pgpca at ct.heise.de? It's one thing to say "it worked!" but he may not understand that whoever controls the pgpca at ct.heise.de can now trick him into believing any OpenPGP identities that they want. > That's a summary of learning step by step what has to be done > to benefit from the web-of-trust > (and BTW "he" was even an IT guy). > > BTW, the dialog would have been different > if I would have used "valid" instead of "trusted". > E.g. as follows: > me: oh, but you need valid(!) keys > he: but they are! Look, neither expired or revoked! > me: no, no, valid in the sense that you can trust them > he ah, I need to trust the keys ... Or, you could have said "you need to validate the certificates" -- i don't know exactly how the conversation would have followed from there, but you wouldn't have led him to trust a key that he is not willing to rely on for certifications. > The essence, we have to teach is: > - create a key > - and then either > - exchange the key > - and sign then key you got > (after validating the fingerprint) > or > - load the key for pgpca at ct.heise.de > or other central "trust agencies" > - AND express trust for that key/owner > > Thus, I am really surprised that you suggest to teach "validity" > instead of "trust". i don't see how the surprise follows from the ideas above. trusting a certificate-signing authority is distinct from validating a certificate. > And I agree that "owner" make things unnecessary complicated. > I am more and more convinced that we simply always should > talk about trust: > - If I trust the key/owner that/who signs other keys, > I can trust these keys and safely use them But these are distinct concepts. conflating them by using the same word does people a disservice. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From daniel at axtens.net Sat Apr 26 03:06:34 2014 From: daniel at axtens.net (Daniel Axtens) Date: Sat, 26 Apr 2014 11:06:34 +1000 Subject: GPG cannot import public key In-Reply-To: <877g6dohoq.fsf@vigenere.g10code.de> References: <030B5D79-04C4-480D-9063-72CEBF928FAC@jabberwocky.com> <184B57B5-061B-46F0-818A-F69489568C33@jabberwocky.com> <877g6dohoq.fsf@vigenere.g10code.de> Message-ID: I can confirm that - I compiled GnuPG against the latest version of libgcrypt in git, and it imported the second key fine. gpg2 --version gpg (GnuPG) 2.0.22 libgcrypt 1.7.0-beta61 Daniel On 25/04/2014, at 7:57 PM, Werner Koch wrote: > On Thu, 24 Apr 2014 19:55, dshaw at jabberwocky.com said: > >> I'm afraid I don't have immediate access to the GPG 2.x code base to check, but I wonder if your problem is simply that 2.x doesn't accept RSA_S and RSA_E keys? > > There is indeed a bug related to the use of RSA_S and RSA_E if GnuPG 2.0 > is used with Libgcrypt 1.6. It is fixed in the repos and I consider to > do a new libgcrypt release soon (we can fix it at both places). > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nico at josuttis.de Sat Apr 26 10:17:21 2014 From: nico at josuttis.de (Nicolai Josuttis) Date: Sat, 26 Apr 2014 10:17:21 +0200 Subject: UI terminology for calculated validities In-Reply-To: <535AB429.1050008@fifthhorseman.net> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535AB429.1050008@fifthhorseman.net> Message-ID: <535B6B91.6060200@josuttis.de> Being off for some days and after reading all these emails (very happy that there is progress!), some thoughts: First of all, MFPA raised: > "Valid" in this context means that my copy of GnuPG will accept it > as an encryption key. For some reason, this for the first time gave "valid" a useful intuitive meaning for me, saying something like "good enough for GPG to send encrypted emails" So I wonder whether some confusion can be avoided by saying: The key is valid for encryption instead of just saying The key is valid But still we'd have to distinguish between marginally valid for encryption fully/complete valid for encryption ultimate valid for encryption Among all the alternatives suggested, "authenticated" seemed to count most compelling. This term is close to trust but different, so it goes into my original direction (and is probably even better). So, we could use "authenticated" or "authenticity" in (G)UI's, while using the technical term "valid" in details such as tooltips. So, let's phrase some sentences with it for UI's: Column: "Key authentication" (instead of "Key Validity") would have the following values: ultimate, full, marginal hmmm, what shall we use for "not valid" ('n')? Regarding option --trust-level always: Either: > Accepted keys to send encrypted: - All keys authenticated according > to the web of trust - All except disabled/expired/revoked keys or: > For a given e-mail address, encrypt messages to: * all keys > authenticated for that e-mail address * all usable keys that claim > to belong to that e-mail address ("valid" instead of "usable" or skipping "usable at all). > Option "automatically send encrypted" a) "never (except according to recipient rules)" b) "if we have authenticated keys for all email addresses" with tooltip "auto send encrypted if all keys for all email addresses are technically valid" Does it sound useful/intuitive? I will probably provide a new test version of enigmail with the option "auto send encrypted", where I can use this new wording for test purposes. -- Nico -- Nicolai M. Josuttis www.josuttis.de From 2014-667rhzu3dc-lists-groups at riseup.net Sat Apr 26 13:03:14 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 26 Apr 2014 12:03:14 +0100 Subject: UI terminology for calculated validities In-Reply-To: <1619717.pObFgkP320@inno> References: <53564380.10000@josuttis.de> <5356EF6C.30201@fifthhorseman.net> <1132800573.20140423203227@my_localhost> <1619717.pObFgkP320@inno> Message-ID: <1593349045.20140426120314@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 NotDashEscaped: You need GnuPG to verify this message Hi On Friday 25 April 2014 at 5:38:15 AM, in , Hauke Laging wrote: > a) You always want to use fingerprints instead. Fair enough. > b) You do not need any reference to a key anyway > because it is absolutely clear which keys this > statement refers to if one key signs another. I take your point, but would prefer such a fundamental statement about shared genesis of multiple keys to reference those keys directly. After all, as well as claiming "this other key is also mine" (corroborated by cross-signing), you would also be indicating your intention that your set of keys should be treated as one key for the purpose of trust calculations. It needs to be as deliberate and explicit as reasonably possible, with room for error minimised. > c) I would like to handle that with an generic > notation. I see a strong need for an expression about > the relation of the signer to the owner of the signed > key. It makes a big difference whether I say "This is > some foreigner which has shown me some ID (see > separate notation for details)" or "This is my > sister". I can see the point of differentiating between a certification on the key of somebody you actually know and on the key of somebody you don't know but checked id. But I agree with DKG that "This is my sister/neighbour/work-colleague/friend-since-childhood" etc is too much information that could backfire on people. -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net There is no snooze button for a cat that wants breakfast -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNbkn9XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p3nYD/1EZP3ffXzw0XbvzCn4JGa0yd/AUTBdHALl1 AfsdQliUE0hbwwny2K1pWW24OZb+YmmQHfMsq6qpvjRC/0z3yagB4Kq/iPIdrTD/ ATANuX9Ej91IjU1dWEgN9U6PYmTZ4wFY0YFEFmGD50i1uiEKZUp7aH29qghZYHLK jh0CAOWw =oeGc -----END PGP SIGNATURE----- From kloecker at kde.org Sat Apr 26 14:08:00 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 26 Apr 2014 14:08:00 +0200 Subject: best practice for pgp mail service, revoking keys In-Reply-To: <504f0a1d-8a03-ab33-4ad6-1fd7d275ffd8@piratemail.se> References: <504f0a1d-8a03-ab33-4ad6-1fd7d275ffd8@piratemail.se> Message-ID: <1593097.9ayQSDS7g0@thufir.ingo-kloecker.de> On Thursday 24 April 2014 21:07:54 tim at piratemail.se wrote: > Thank you for your responses. I'm still mulling over what to do. Your > input has been revealing. > > I think I'm leaning towards the 1 year key, with a 1 year "fallow" > time. For the reasons implied by Daniel, (which I interpolated). I > would not want another user grabbing an e-mail account and posing as > a previous user. I would not allow re-usage of email addresses because even a 1 year "fallow" time might be too short, e.g. for some services you might get an invoice once a year and, since you are obviously concerned about privacy, you surely wouldn't want this message to be sent to the wrong person. IMHO used email addresses are burned for all eternity (unless, some time in the future, there will be other mechanisms, e.g. ubiquitous end-to-end encryption, that prevent the disclosure of private information in emails that have gone astray). > But at the same time, when a user renews a key, will the existing WoT > signatures become invalid? No. Each signature has an individual expiration date (or none). When you sign a user id which has an expiration date then gpg proposes to use the same expiration date for your signature, but you are free to set another expiration date (including no expiration) for your signature. > If they do, perhaps it would be better to > instead have the designated revoker (me) as described by David. If > the co-signers don't become invalid, this seems strange to me. > > -- > > I have also been thinking about how this works into the WoT. Because, > as Daniel and one other expressed, anyone can upload a key for a > user. How to differentiate. > > I'm thinking to do this: > 1. User registers, automagically creates pub/priv key. > Tells me about pub key. > I sign the pub key with the site key. > All keys from the e-mail site will be self-signed and as well have the > signature of the e-mail site key. As mentioned above you could use a 1-year-expiration for the certification of the user's key with the site key. > 2. Users can "trust", or "be-friend" another email+key. > When this happens they will sign the other's key, and will also mark > that key as the prefered encryption key. Maybe that e-mail address > will as well be placed on a white list of some sort. Definitely makes sense. > 3. The algorithm which picks the "best & default encryption key" for > an address, will, instead of picking the key with the latest date > (which it does now), will pick the key with the most number of > co-signers. (and of course which isn't revoked, or expired) Given 2. you should always take the prefered key first. If there's no prefered key, then I'd follow gpg's practise and take the newest valid key (and ask the user whether he is okay with the choice). > Does this sound about right? > > > In existing gpg mail programs, when evaluating the trust level a key, > does gpg see if there is a path between yourself and that key, "I > didn't sign it, but this other key which I already trust, signed this > other key, which signed the key I'm looking at." Or do you count > signatures. Or both? KMail relies on gpg to make the best choice. I suggest to do the same. I see no reason to invent a new trust-scheme. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From 2014-667rhzu3dc-lists-groups at riseup.net Sat Apr 26 14:20:40 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 26 Apr 2014 13:20:40 +0100 Subject: UI terminology for calculated validities In-Reply-To: <535A91B2.90602@fifthhorseman.net> References: <53564380.10000@josuttis.de> <5356EF6C.30201@fifthhorseman.net> <1132800573.20140423203227@my_localhost> <1619717.pObFgkP320@inno> <535A91B2.90602@fifthhorseman.net> Message-ID: <1143089782.20140426132040@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 NotDashEscaped: You need GnuPG to verify this message Hi On Friday 25 April 2014 at 5:47:46 PM, in , Daniel Kahn Gillmor wrote: > PS MFPA's original idea of using a notation to link two > primary keys is interesting, and i see how it could be > useful, but i don't think it belongs in the public > keyservers either. Interesting. Why not? > Perhaps something like that (using > full fingerprints, as hauke suggests) could be made by > a non-exportable certification directly on the primary > key itself (not over User IDs). Why non-exportable? If I were making such a declaration about the relationship between my multiple keys, I would want to declare it to others. This could be useful for key transitions, but also for an individual who chooses to use different keys with different email addresses (so may not have a "identical-valid-user-id" across different keys). Or do you envisage somebody else with my public keys on their keyring would make that non-exportable certification themselves, in order to clean up their own WoT calculations? Actually, on thinking about it, that option also would be useful. A certification directly on the primary key itself would make sense, because it is a statement about the key itself, not just the key and it's current set of UIDs. But having it over the UIDs, so requiring a re-certification from my other key to cover any new user-ids, maybe adds a certain amount of security. How do you make a certification directly on the primary key itself. > But this should only be done if there is an algorithm in > place to make use of this information. Isn't that kind of a "chicken and egg" statement? Would it not be an idea to discuss a standardised notation, so that if anybody chooses to put the information out there, it could be interpreted by an algorithm that might get written in the future. > Anyone implementing this kind of > cleanup should probably start simpler and just handle > the identical-valid-user-id case first. Maybe "identical" should be expanded to cover such things as different capitalisation, etc. -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Wait. You think I'm right? -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNbpKZXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5poy8D/iBRy/gc7I+DMsiazPQ/504twN9MT8wO96wG rEEV5P3r6lqT5zVfjNXSz4IuWR6xy3iflMDpTpyzZrmz067Rr8PcLZXrYt9CmuSf Jm9wYX8Z5hCiIRBtkYh6VJ6Jeut5sPEq+mRi3RQOHDFgy8Fs2AKUAYq97DmXqT9P vvEQ4CDo =cgbe -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sat Apr 26 14:27:06 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 26 Apr 2014 13:27:06 +0100 Subject: UI terminology for calculated validities In-Reply-To: <2950043.2nq8QHs4Oz@inno> References: <53564380.10000@josuttis.de> <53598C8C.4010007@gmail.com> <53598E9C.1070800@dougbarton.us> <2950043.2nq8QHs4Oz@inno> Message-ID: <1436573586.20140426132706@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 NotDashEscaped: You need GnuPG to verify this message Hi On Friday 25 April 2014 at 5:43:27 AM, in , Hauke Laging wrote: > Many keys get signed without being verified. Especially with non-exportable signatures added to make the keys valid. -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Always borrow money from a pessimist - they don't expect it back -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNbpiBXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5prg8EALR42JNZ2wQtbo/sb5p3iGtNAdrdb7eM3vk/ Sma2a7Yoq54DuVuFm27NQQKJxN99YV8T7f7o70UwTuM8FLTV8CFPsBhYZPeJ9C5Z fcQN8UWSmZzrGADvAoAk5opAz5SHNkaC5j9iR4wHU8o1ydqGgrnV46iOaId3Ja4O 3BH3eukf =Iz2y -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sat Apr 26 14:43:32 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 26 Apr 2014 13:43:32 +0100 Subject: UI terminology for calculated validities In-Reply-To: <1691426.OzBBnA61Yg@inno> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> Message-ID: <926791071.20140426134332@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 NotDashEscaped: You need GnuPG to verify this message Hi On Friday 25 April 2014 at 3:49:30 AM, in , Hauke Laging wrote: > Thus I would like to offer "accepted" as a possible > alternative. I guess that shows the user decision. > Maybe even as a combination: "authenticity accepted". In the case of a non-exportable signature made simply to allow me to encrypt to a key, I am not "accepting" or "authenticating" or "validating" or "verifying" that key. All I am doing is "activating" it for use. -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Greater than being great is being grateful. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNbqflXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pY4QD/3OOZN2e5POCEdnWYMPSaXEBbzJf3ITEvr/v 8mVloI6caUoVdsTmg/nqi0HYNX0SDN0Z9/5w9Dqchaj0oxbVSJbKUMt0mMOVyRRZ e7U4buLTfbei4hTZODWQn4GghT+KrmSTIopQE+Gz4ENf17hhK2ODzOpjyygf4EjQ 7QAebfSM =Aayn -----END PGP SIGNATURE----- From dougb at dougbarton.us Sat Apr 26 19:14:07 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 26 Apr 2014 10:14:07 -0700 Subject: UI terminology for calculated validities In-Reply-To: <926791071.20140426134332@my_localhost> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> Message-ID: <535BE95F.1040601@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/26/2014 05:43 AM, MFPA wrote: | Hi | | | On Friday 25 April 2014 at 3:49:30 AM, in | , Hauke Laging wrote: | | |> Thus I would like to offer "accepted" as a possible |> alternative. I guess that shows the user decision. |> Maybe even as a combination: "authenticity accepted". | | In the case of a non-exportable signature made simply to allow me to | encrypt to a key, I am not "accepting" or "authenticating" or | "validating" or "verifying" that key. All I am doing is "activating" | it for use. But there are other mechanisms besides signatures that will allow you to use the key, so I'm not sure that word captures the essence of the activity adequately. I have a variety of local signatures for keys that I have verified belong to a certain user, but for a variety of reasons I don't wish to export those signatures. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJTW+lfAAoJEFzGhvEaGryEknsH/j5oxv/nKRIA/v2hO0X2zkpX NzvHkG8kjiQXcuMrQI/xZ6DngT4dF+zVg41+HM/YfB278JllrAciOld+K57B63V7 wFf9Bj+WTw6U0zNN7oPmytZ7nnHRQyb8dHxKN28mdSLxemgpE0moQf2zYINwceIs uo2ioz2oD5GSmqvitxGP+DOEFuZaNQSEuOJ7Z3zzE0g92tbw0d+yciTpe9D/SCOf wDIjhbMScAsCAnjp/SQILvj13bawBWwPn9Nlue/8+nA/S6mZakgLFkJPtIsVWPuD anxfVdeqDXRNZSO5V5foIHhZTiRu7ubgwXwHVqSi9hn8zVZnYFZxFIa0WhD6xXk= =APgc -----END PGP SIGNATURE----- From doark at mail.com Sat Apr 26 20:41:08 2014 From: doark at mail.com (frank ernest) Date: Sat, 26 Apr 2014 14:41:08 -0400 Subject: A few newbie Qs Message-ID: <20140426184108.28260@gmx.com> Hello, These first two may be kinda a preferences thing, but I'm no expert in the field and I could not read the math even if I wanted to, so try to be easy on me. Which algorithm is most secure/is there more non-college-math info on the web somewhere (no wikipedia please)? IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 What are the "?" mark values? "Pubkey: RSA, ELG, DSA, ?, ?" And similar to the above question, what is the hardest to break (I understand that there is no chance of a brute force attack, see the question below for a better idea of the attack I'm concerned about)(no wikipedia please)? How sensitive is an email to assumption based deciphering? For instance: Normal people start their emails with "Hello", "To whom it may concern", "Dear so-and-so" and people generally end their emails with "Thanks", "Sincerely, name", "Yours truly, name". Now, "name" and "so-and-so" can easily be determined by the public key of the person to whom you are sending data and your name can also be determined based on which email address you sent the message from so that gives crackers and the feds respectivly: Hello ? ? ? ? ? ? ? ? ? ?5 To whom it may concern ?23 Dear + name, ? ? ? ? ? ?10+ Thanks ? ? ? ? ? ? ? ? ? 6 Sincerely, + name ? ? ? 16+ Yours truly, + name ? ? 20+ chars of preknown text (not to mention that most messages in english contain a large amount of "e"s,) to work with. So, how hard is it, knowing some of the message, to discover the whole thing and/or the private key of the user? Is it polite to post saying that you want to sign keys with somebody on a random mailing list? I can't decide, for though it is a recommended practice in the "keysigning howto" guide, I've never seen anybody do it and it is off topic on most lists. This, is of course, ignoring the fact that a "web of trust" can't be built unless people try to reach out to one another and sign there respective keys. The main reson I'm asking is, because I live out in a rural area and am unlikly to meet anybody who knows more about a computer then that you can't juice it, pick it, or mate it.... Is there a way to tell gpg2 to encrypt the body of a message with something other then AES? (I've read that it uses AES for the body and ?I've read that AES is a fast, but not very good method of encryption.) If my key expires, is using the same passpharse on another key a safe/ok thing to do? Is there a limit practical or imposed on the lenght of a passpharse? I'm thinking of a 740 char passphrase that, though containing sentences and, therefore, making sense, (though perhaps only to some sick people like me,) and also containing repetitions of words 4+ chars long, is really easy for me to remember. Do you think that it would be a good passphrase? Is exporting a public key a great way to announce that you can't wait to be spammed? (Your email is included in the output, as is your name.) If multiple people sign a cert and return it to me how do I merge all the signatures back into my key on my computer? From tim at piratemail.se Sat Apr 26 22:23:26 2014 From: tim at piratemail.se (tim at piratemail.se) Date: Sat, 26 Apr 2014 16:23:26 -0400 (EDT) Subject: A few newbie Qs Message-ID: <19225048-8889-8c48-1016-dab4aa88861e@piratemail.se> -- Oops replied off list. -- Your question about AES reminds me of a similar question I previously asked to a different mailing list. I found Falko's explanations credible and insightful. Maybe this is what you were looking for. ;-) http://lists.randombit.net/pipermail/botan-devel/2013-February/001748.html -tim From gabriel.niebler at gmail.com Sun Apr 27 00:01:15 2014 From: gabriel.niebler at gmail.com (Gabriel Niebler) Date: Sun, 27 Apr 2014 00:01:15 +0200 Subject: UI terminology for calculated validities In-Reply-To: <535AB26B.2060804@fifthhorseman.net> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> <1397259291.20140424204510@my_localhost> <53598DE0.2060301@gmail.com> <535AB26B.2060804@fifthhorseman.net> Message-ID: <535C2CAB.8000303@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> A key on my keyring is "valid" if it is not expired or revoked. >> It is "authentic" if it bears one signature from one of my keys, >> or several signatures from other keys to which I have granted >> marginal authority to authenticate keys. """ > > I can see that "authenticity" is in some ways more appealing as a > term than "validity". Thank you. That was the whole point, really. > But i agree with Peter that trying to redefine "validity" to then > mean something else is likely to be asking for trouble, given the > existing established terminology. You and Peter are quite right and thanks for pointing this out. Having a word, with an established meaning in GnuPG, and then suddenly changing its meaning would cause far more confusion than its worth. If one were to rename "validity" to "authenticity", then from that point on, the word "validity" should not be used anymore, at all, in the context of OpenPGP keys (or certificates, as I should probably say). That's a shame, as "validity" is a good word with useful connotations for some things, but it couldn't be helped. > I also wonder what term you would propose using as the opposite of > "authentic". "valid" can be opposed cleanly with "invalid". Would > you say "inauthentic" or "unauthenticated"? I prefer the latter > term, but in that case, perhaps the positive version should be > "authenticated" rather than "authentic". Hmm, well as far as GPG is concerned, the question does not really come up, because it shows the "validity"/"authenticity" _levels_ and the words for those (ultimate, full, marginal, unknown) don't need to be changed. But this discussion is mainly about other UIs and it's relevant there. I agree that 'inauthentic', the natural opposite of 'authentic', is saying too much. The software doesn't know whether the given ID is authentic or not, so it shouldn't pretend to know that it isn't. I came up with the following pairs of (functional) antonyms: 1) 'authentic' - 'unknown' 2) 'authentic' - 'possibly fake' 3) 'authenticated' - 'unauthenticated' 4) 'authenticated' - 'not authenticated' ... or one can adopt the GnuPG CLI convention: 5) 'authenticity': 'unknown'/'marginal'/'full'/'ultimate' And some other suggestions were made, too: 6) 'verified' - 'unverified' 7) 'verified' - 'not verified' 8) 'verification': 'unknown'/'marginal'/'full'/'ultimate' 9) 'accepted' - 'not accepted' 10) 'usable' - 'unusable' 11) 'usable' - 'not usable' There may have been others I'm forgetting. > Also, i think it is a problem to say a key is valid or authentic. > It is not the key that is valid or authentic, it is the combination > of the key and a given user ID. Ah, yes ... you're right, of course. I glossed over that, since I believe that most certificates simply consist of a master signing key (an encryption subkey, which we can ignore here) and one UserID. But there may be other UserIDs and - for that matter - different certificates with the same UserID and the question is always only "Is this UserID valid/authentic/verified/usable/accepted/whatever with this key?". It's good to state this clearly here. > An OpenPGP certificate as a whole contains one master key and one > or more User IDs. So the certificate itself may contain some > valid/authentic combinations, and some > invalid/unauthenticated combinations. > > In some scenarios, you want to talk about the certificate as a > whole, and sometimes people want to make assertions about the > validity or authenticity of the certificate itself, even though it > may be in this mixed state. For example, when a user applies > ownertrust to a given certification-capable master key, GnuPG still > only relies on certifications made by that key if the certificate > containing the key has at least one valid combination. > So in some sense, GnuPG considers a certificate as a whole (and by > implication, its primary key) as though it it has a validity by > taking the maximum of the validity of all of the certificate's user > IDs. > > I'm not proposing that we expose this detail to the end user, > though, just laying out to the detail-oriented people on this list > so that we have a common understanding. GnuPG will also allow me to encrypt some text to (an encryption subkey of) such a mixed-case certificate (I think), because it cannot possibly know the intended recipient, so checking validity/authenticity/... of that specific UserID is up to me. That's as it should be, so also here, I can talk of the validity/authenticity/... of the certificate as a whole. Some higher level software, however, may _know_ who I want to write to and not allow me to use a given key, because validity/authenticity/... of THAT UserID on THAT certificate with THAT master key has not been established. When that happens, such software should inform me of this in a way that's helpful and as understandable as possible even to new users. And it's at this point that the detail will have to exposed to the user. I trust, though, that such mixed-case certifcates will be found very rarely in people's public keyrings and almost never in those of new users (after all, when signing a key, the signature is ausually applied to all UserIDs by default), so I think it's perfectly acceptable to hide a bit of the complexity by simply showing a _certificate's_ validity/authenticity/... and to only go into details when necessary. Best gabe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTXCyjAAoJEO7XEikU4kSzxh8H/jDgNa2F1kPzWKyqSEbayYsM dSVLH7GPUsb934d9LGTj/xOlLpt2dhVSdtBpFCk0/Lt+NqLiu8yaBuA1A6H/bvgh jOszkSyCffLb5pbNi9wGwY0u93COVa9Ob743NtTjkPNd0kJ6gnjXiOSDN7l1lIzv R4ZRWU3w62HJOcj8Ul/0ujg7CqnS1dYr3ylQoqvHskQw45I+UQSw9hyUVg+hOQ19 Qgu+XyM9MSlSE35qHI7h71UDCj74uJpNN7R0FHMKpG6EybZ7qjoPrYdK0ueMYvGY BkjW5qMcSbqNNpA9SpxzgsCJTyDEVKtDW+Fr7hosbT2rWDQu+KME2VyW77d4v0s= =fuKk -----END PGP SIGNATURE----- From jsockwell at kbsp.com Sun Apr 27 00:21:42 2014 From: jsockwell at kbsp.com (John Sockwell) Date: Sat, 26 Apr 2014 22:21:42 +0000 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: Message-ID: I?m looking for best practices in creating and managing multiple subkeys and uids. In my scenario, I have a personal computer and personal email address. In addition, I have an employer provided computer and employer email address. I?d like to create a key architecture where if I?m ever compelled to compromise, revoke, or lose access to the signing and encryption keys on my work computer, the security and integrity of my personal files are preserved. The easiest solution seems to be generating separate primary keys for both identities. However, I believe this would undermine the WoT when I move to a new employer by not having all signing and encryption keys originating from the same primary key. Is it possible to assign an encryption and signing sub key to a specific uid so I can separate the keys used? Is there a better way to achieve this goal through other signing techniques? -------------------------------------------------------- This e-mail transmission (and/or documents attached) contains confidential information. The information is intended only for the use of the individual or entity to whom this e-mail is directed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please delete same immediately. This e-mail may not be forwarded without the sender's express permission. -------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun Apr 27 03:36:26 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 26 Apr 2014 21:36:26 -0400 Subject: A few newbie Qs In-Reply-To: <20140426184108.28260@gmx.com> References: <20140426184108.28260@gmx.com> Message-ID: <535C5F1A.20304@sixdemonbag.org> > Which algorithm is most secure/is there more non-college-math info > on the web somewhere (no wikipedia please)? IDEA, 3DES, CAST5, > BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, > CAMELLIA256 It's kind of like asking whether King Kong or Godzilla is the best at urban demolition. There are no clear answers here, and all rankings will be hotly contentious. Just discussing the different facets of the problem requires college-level math: one might be slightly superior in its resistance to differential cryptanalysis, another in impossible-differentials, and so on. The good news: all the ciphers in GnuPG are believed strong even in the face of well-funded and highly-skilled adversaries. > How sensitive is an email to assumption based deciphering? These are called "known-plaintext attacks." All the ciphers in GnuPG are believed to provide strong protection against known-plaintext attacks. > So, how hard is it, knowing some of the message, to discover the > whole thing and/or the private key of the user? Really, really hard. Like, "it would make the earth uninhabitable." http://www.gnupg.org/faq/gnupg-faq.html#brute_force > Is it polite to post saying that you want to sign keys with somebody > on a random mailing list? Depends a lot on the mailing list. I wish I could give clearer advice than that. > Is there a way to tell gpg2 to encrypt the body of a message with > something other then AES? (I've read that it uses AES for the body > and I've read that AES is a fast, but not very good method of > encryption.) Sure. --personal-cipher-preferences will do this. That said, you read wrong: AES is considered one of the gold standards of strong cryptography. It's fast and believed highly resistant against cryptanalysis. > If my key expires, is using the same passpharse on another key a > safe/ok thing to do? So long as you're confident your passphrase is still a secret, yes. > Is there a limit practical or imposed on the lenght of a passpharse? > I'm thinking of a 740 char passphrase that, though containing > sentences and, therefore, making sense, (though perhaps only to some > sick people like me,) and also containing repetitions of words 4+ > chars long, is really easy for me to remember. Do you think that it > would be a good passphrase? No. English has about 1.5 bits of entropy per glyph. Past about 384 letters you're not making things any harder to guess. Long passphrases also silently encourage users to do risky things like cut-and-paste them. (It's very easy for malware to look at the contents of your clipboard buffer.) > Is exporting a public key a great way to announce that you can't > wait to be spammed? (Your email is included in the output, as is > your name.) No. That's a 1995-2000 model of how spammers work. Email address harvesting got replaced by Markov models about 15 years ago. > If multiple people sign a cert and return it to me how do I merge > all the signatures back into my key on my computer? GnuPG will do it automatically. Just import the certs. From rjh at sixdemonbag.org Sun Apr 27 04:02:11 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 26 Apr 2014 22:02:11 -0400 Subject: Fwd: Re: Re: A few newbie Qs In-Reply-To: <20140427014627.5138418EE3@mx1.mailingbuddies.com> References: <20140427014627.5138418EE3@mx1.mailingbuddies.com> Message-ID: <535C6523.8010502@sixdemonbag.org> Is anyone else getting spam like this the instant they post to the list? It seems as if one listmember might have a compromised PC which is sending out spam in response to anything that comes in. (The full message headers have been trimmed, as they're not particularly useful. If a list maintainer wants, though, I'll be happy to send the full headers.) -------- Original Message -------- Subject: Re: Re: A few newbie Qs Date: Sun, 27 Apr 2014 01:46:27 +0000 (UTC) From: Alyssa Reply-To: brighteyes26 at mailingbuddies.com To: robert j hansen Hey cool you wrote back :) Wasn't sure if you were real or not it's hard to tell sometimes lol. Can you send me a recent pic to this email? Also you are looking for something really casual right? You need to know I'm not looking for a boyfriend I just got out of a relationship. I need some fun and a one night stand or whatever the heck its called. I suppose if you were good enough we could meet again it depends how it feels lol. See how it goes? I'll send you my pic now, yours is already good enough for me. Maybe send one more. Did you wanna make a plan or something? [[ attachment of type image/jpeg removed ]] From mailinglisten at hauke-laging.de Sun Apr 27 04:07:31 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 27 Apr 2014 04:07:31 +0200 Subject: Fwd: Re: Re: A few newbie Qs In-Reply-To: <535C6523.8010502@sixdemonbag.org> References: <20140427014627.5138418EE3@mx1.mailingbuddies.com> <535C6523.8010502@sixdemonbag.org> Message-ID: <2063569.4zBehgiDvq@inno> Am Sa 26.04.2014, 22:02:11 schrieb Robert J. Hansen: > Is anyone else getting spam like this the instant they post to the > list? At least I do. This has already been discussed recently. > It seems as if one listmember might have a compromised PC which > is sending out spam in response to anything that comes in. That's a possibility, too. I thought that spammers might actively subscribe to mailinglists for this reason. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From ged at slindgren.se Sun Apr 27 08:54:02 2014 From: ged at slindgren.se (Sten Lindgren) Date: Sun, 27 Apr 2014 08:54:02 +0200 Subject: C# .dll availability? In-Reply-To: <8efe69c121a14cceaed67276bfc72efb@BLUPR02MB066.namprd02.prod.outlook.com> References: <8efe69c121a14cceaed67276bfc72efb@BLUPR02MB066.namprd02.prod.outlook.com> Message-ID: <535CA98A.3060207@slindgren.se> On 2014-04-25 00:07, Charles Spitzer wrote: > Is there a GnuPGP project anywhere that does PGP encryption that is > usable in a C# application? Bouncy Castle handles OpenPGP for C# (and Java) you can get it at http://www.bouncycastle.org/csharp/ . It uses its own license so its not GPL licensed nor part of GnuPG. It still might be useful. From peter at digitalbrains.com Sun Apr 27 11:41:27 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 27 Apr 2014 11:41:27 +0200 Subject: A few newbie Qs In-Reply-To: <535C5F1A.20304@sixdemonbag.org> References: <20140426184108.28260@gmx.com> <535C5F1A.20304@sixdemonbag.org> Message-ID: <535CD0C7.7080500@digitalbrains.com> On 27/04/14 03:36, Robert J. Hansen wrote: > Long passphrases also silently encourage users to do risky things like > cut-and-paste them. (It's very easy for malware to look at the contents of > your clipboard buffer.) Is this really a useful criterium? Sure, by not using the clipboard you might stop some non-specific malware that simply does data trawling by sending all likely clipboard contents to a server so a hacker can see if it sees any passphrases in there. But since the malware is already in the position to execute arbitrary code with your credentials, you should simply consider your GnuPG installation compromised whether you use the clipboard or not. It can simply catch all calls to gpg2 or gpg-agent and prompt you for your passphrase. If you're talking about a malicious site being open in the browser, I'd very much like to hear about known, unfixed vulnerabilities that allow server-supplied code to get at your clipboard. That would be quite a vulnerability in my eyes. I use Keepass2 under Debian GNU/Linux to keep all the passphrases I use on this machine (but my OpenPGP keys are on a smartcard, they're not protected by a password but by a PIN). Since I'm not aware that there exists a plugin for Linux integrating Keepass2 and Firefox, I copy-paste all my web passwords, including high-profile stuff like PayPal. Also, there are some things that will never have integrated Keepass2 support, like command line tools, which require me to copy-paste. If I need to check which /other/ websites I have open at the same time (or rather: close all open websites) whenever I use Keepass2, I'd very much like to know. Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From gnupg at lists.grepular.com Sun Apr 27 12:11:00 2014 From: gnupg at lists.grepular.com (Mike Cardwell) Date: Sun, 27 Apr 2014 11:11:00 +0100 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: References: Message-ID: <20140427101100.GA24409@glue.grepular.com> * on the Sat, Apr 26, 2014 at 10:21:42PM +0000, John Sockwell wrote: > I'm looking for best practices in creating and managing multiple > subkeys and uids. > > In my scenario, I have a personal computer and personal email address. > In addition, I have an employer provided computer and employer > email address. > > I'd like to create a key architecture where if I'm ever compelled to > compromise, revoke, or lose access to the signing and encryption keys > on my work computer, the security and integrity of my personal files > are preserved. The easiest solution seems to be generating separate > primary keys for both identities. However, I believe this would > undermine the WoT when I move to a new employer by not having all > signing and encryption keys originating from the same primary key. > > Is it possible to assign an encryption and signing sub key to a > specific uid so I can separate the keys used? I don't believe that is possible no. > Is there a better way to achieve this goal through other signing > techniques? I solve this problem using an OpenPGP smart card. My PGP key never touches my work machine, so I never have to worry about it being compromised. When I left my previous job, I revoked the UID containing the email address assigned by that company, and then added the new UID for the new company. -- Mike Cardwell https://grepular.com https://emailprivacytester.com OpenPGP Key 35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 598 bytes Desc: Digital signature URL: From rjh at sixdemonbag.org Sun Apr 27 12:34:07 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 27 Apr 2014 20:34:07 +1000 Subject: A few newbie Qs In-Reply-To: <535CD0C7.7080500@digitalbrains.com> References: <20140426184108.28260@gmx.com> <535C5F1A.20304@sixdemonbag.org> <535CD0C7.7080500@digitalbrains.com> Message-ID: <535CDD1F.6000806@sixdemonbag.org> > Is this really a useful criterium? I think so, but I'm well-known for being barking mad. Hornswoop me bungo pony, dogsled on ice (red and black, it's their color scheme). By the silverfish imperetrix whose incorrupted eye sees through the charms of doctors and their wives... (At some point it's really hard to distinguish random Blue Oyster Cult lyrics from a full-on psychotic episode.) > execute arbitrary code with your credentials, you should simply > consider your GnuPG installation compromised whether you use the > clipboard or not. C&P is a time machine. If I enter a passphrase normally on Monday and my machine is compromised on a Tuesday, I can be confident my certificate is still secure because I never entered my passphrase on a compromised machine. If I enter a passphrase via C&P on Monday and my machine is compromised on a Tuesday, I suddenly have to worry: was my passphrase still in my C&P buffer? Did I remember to wipe the C&P buffer? Did the C&P buffer get wiped securely? Did I... Generally speaking, it is suboptimal to enter passphrases via C&P. It makes it possible for a compromise tomorrow to discover the passphrase you entered today. I don't doubt there are situations where it makes sense to use C&P. I've yet to find one, though. From nico at josuttis.de Sun Apr 27 13:11:35 2014 From: nico at josuttis.de (Nicolai Josuttis) Date: Sun, 27 Apr 2014 13:11:35 +0200 Subject: UI terminology for calculated validities In-Reply-To: <535A9ED9.4010101@ei8fdb.org> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> <535A28C8.8050104@digitalbrains.com> <20140425132354.GB22122@IUPUI.Edu> <535A950D.3060604@fifthhorseman.net> <535A9ED9.4010101@ei8fdb.org> Message-ID: <535CE5E7.6030701@josuttis.de> Am 25.04.2014 19:43, Bernard Tyers schrieb/wrote: > At the risk of being flamed, can I suggest asking the users what > they think? > > Nicolai, by the look of it you've carried out some user research. > I guess so by the "real world" discussion you posted in a message. > Well, the "users" I asked were just ordinary people in my family (typical smart phone users). The funny thing is, today I discussed this again with one. The outcome was surprisingly a renaissance of the term "valid" but in a slightly different sense. Valid meaning "validated by me or other people I trust". And the result was to provide three "trust model" options in a mailer: -------------------------------------------------------------- To send encrypted, accept a) only keys validated/signed by me personally b) only keys validated/signed by my or others I trust c) all keys that are neither disabled nor expired nor revoked --------------------------------------------------------------- With the following tooltips: a) only keys validated/signed by me personally Tooltip: This option is provided to deal with the danger of faked keys, not trusting anybody else. Validated keys are keys either signed by you or signed by other people you trust. b) only keys validated/signed by my or others I trust Tooltip: This option is provided to deal with the danger of faked keys, trusting other people you categorized as trustworthy. Validated keys are keys either signed by you or signed by other people you trust. c) all keys that are neither disabled nor expired nor revoked Tooltip: This option forces encryption whenever you have a key that is not disabled by you or revoked/expired by the owner. Because these keys are not necessarily validated by you or people you trust, there is a risk that you use faked keys so that others than the requested receivers can read the content of the encrypted email. Some of these policies would then be supported by GPG directly, but I might have to implement one or two in enigmail directly: a) This would allow only keys where the user locally signed the key with at least casual checking - Is there an option I can use to have this policy? b) This would allow keys valid according to the WoT. As the current implementation seems only to check the first key for an email address, the workaround would have to be implemented in enigmail directly. c) b) but also allow unknown. This would match --trust-model always And: We might even split option a) in: a1) allow keys where I personally signed with casual verification a2) allow keys where I personally signed with extensive verification -- Nico From peter at digitalbrains.com Sun Apr 27 13:35:29 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 27 Apr 2014 13:35:29 +0200 Subject: C&P'ing passphrases (was Re: A few newbie Qs) In-Reply-To: <535CDD1F.6000806@sixdemonbag.org> References: <20140426184108.28260@gmx.com> <535C5F1A.20304@sixdemonbag.org> <535CD0C7.7080500@digitalbrains.com> <535CDD1F.6000806@sixdemonbag.org> Message-ID: <535CEB81.9000601@digitalbrains.com> On 27/04/14 12:34, Robert J. Hansen wrote: > I think so, but I'm well-known for being barking mad. "Woof" back at you. > Generally speaking, it is suboptimal to enter passphrases via C&P. It > makes it possible for a compromise tomorrow to discover the passphrase > you entered today. But I will just enter the same passphrase again tomorrow. Even if I notice I've been compromised, it is unlikely that I notice this on the day of the compromise. Even if I knew when the compromise happened, I wouldn't rely on my memory to remember which passphrases I entered since. So, in conclusion, when I notice my machine is compromised, I need to consider everything I access through a passphrase using that machine as compromised, replace all those passphrases and contemplate what the attacker could have done with the compromised services. I don't think the risks I ran and the actions I need to take when my machine is compromised are any different whether I use C&P or enter them directly, for the common case that I regularly use the passphrase. > I don't doubt there are situations where it makes sense to use C&P. > I've yet to find one, though. Well, you can't integrate your password manager with everything you need passphrases for. And I highly prefer the more than hundred randomly-generated passphrases[1] in my KeePass over trying to think of more than a hundred good passphrases and remember them. I consider that waaaayyyy beyond my capabilities. That word needs even more vowels, but it would make it hard to read ;). Still, if there is a real risk that websites see my clipboard, I definitely want to know. Cheers, Peter. [1] By the way, the best part of those passphrases aren't protected on my system; they are in my browser's unencrypted credentials database and the password for the KeePass database is a single lowercase "a" because you have to enter something. They are just accounts on websites. Passphrases I do consider important are in another well-protected KeePass database (and are copy-pasted). I recently moved Amazon to the protected database because I noticed you can order and pay stuff without re-entering your credit card number. It will be shipped to one of your pre-existing addresses, but I still did not appreciate it, so I changed the passphrase and moved it to my protected database. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Sun Apr 27 13:51:42 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 27 Apr 2014 13:51:42 +0200 Subject: UI terminology for calculated validities In-Reply-To: <535CE5E7.6030701@josuttis.de> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> <535A28C8.8050104@digitalbrains.com> <20140425132354.GB22122@IUPUI.Edu> <535A950D.3060604@fifthhorseman.net> <535A9ED9.4010101@ei8fdb.org> <535CE5E7.6030701@josuttis.de> Message-ID: <535CEF4E.3030309@digitalbrains.com> On 27/04/14 13:11, Nicolai Josuttis wrote: > Well, the "users" I asked were just ordinary people in my family > (typical smart phone users). Would those be smart users of a phone, or users of a smart phone? Where does the intelligence reside? ;) I'm reminded of a nice quote I saw in an e-mail signature. "I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone" -- Bjarne Stroustrup > Some of these policies would then be supported by GPG directly, > but I might have to implement one or two in enigmail directly: > a) This would allow only keys where the user locally signed the key > with at least casual checking > - Is there an option I can use to have this policy? It's just b) without assigning trust to any key. I don't think there is a trust model where you drop all assigned trust, but you can of course empty the trust database (perhaps back it up, and restore it once the user selects a different trust model). > And: > We might even split option a) in: > a1) allow keys where I personally signed with casual verification > a2) allow keys where I personally signed with extensive verification Doesn't sound like a "let's make this less confusing for non-expert users" thing. Also, making it configurable seems to imply to me that users would want to switch back and forth. Otherwise, they would just use the verification effort they feel comfortable with, and sign keys as "0x10 Generic certification" rather than using "casual" and "positive" certifications. Without ever seeing those descriptions, by the way, no need to burden them with those. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From simon+gnupg at bleah.co.uk Sun Apr 27 15:04:11 2014 From: simon+gnupg at bleah.co.uk (Simon Ward) Date: Sun, 27 Apr 2014 14:04:11 +0100 Subject: A few newbie Qs In-Reply-To: <535CDD1F.6000806@sixdemonbag.org> References: <20140426184108.28260@gmx.com> <535C5F1A.20304@sixdemonbag.org> <535CD0C7.7080500@digitalbrains.com> <535CDD1F.6000806@sixdemonbag.org> Message-ID: <6a65f4ec-9a51-4b14-b077-a98d37b9aa9d@email.android.com> On 27 April 2014 11:34:07 BST, "Robert J. Hansen" wrote: >>execute arbitrary code with your credentials, you should simply >> consider your GnuPG installation compromised whether you use the >> clipboard or not. > >C&P is a time machine. > >If I enter a passphrase normally on Monday and my machine is >compromised >on a Tuesday, I can be confident my certificate is still secure because >I never entered my passphrase on a compromised machine. If I enter a >passphrase via C&P on Monday and my machine is compromised on a >Tuesday, >I suddenly have to worry: was my passphrase still in my C&P buffer? >Did >I remember to wipe the C&P buffer? Did the C&P buffer get wiped >securely? Did I... The password manager should clear or overwrite the clipboard after a short time, which should help. Keepass includes "timed clipboard clearing" in its feature list. Of course, there is still the question of whether it does (or can*) do it securely. (*It's possible to clear the X clipboard, but I'm not sure if it remains in memory) Simon -- Sent from Kaiten Mail. Please excuse my brevity. From Old_Professor at comcast.net Sun Apr 27 17:55:12 2014 From: Old_Professor at comcast.net (Old_Professor) Date: Sun, 27 Apr 2014 11:55:12 -0400 Subject: Trustworthy Android implementation ? Message-ID: <4be0676f-b828-4fce-9805-e187eee8edd2@IMCCAS02.MITRE.ORG> I'm looking for a trustworthy and user-friendly encryption product to use on my Android smart phone. I found four implementations of GPG. I don't know anything about the competence or trustworthiness of the implementers. I'm concerned that if the phone is lost or stolen, how much resistance will the GPG implementation have to exposing my passphrase or private key. I found: APG - Thialfihar Gnu Privacy Guard -The Guardian Project OpenKeychain - Dominik Sch?rmann PGP SMS lite - woodkick From mirimir at riseup.net Sun Apr 27 22:17:00 2014 From: mirimir at riseup.net (Mirimir) Date: Sun, 27 Apr 2014 14:17:00 -0600 Subject: Trustworthy Android implementation ? In-Reply-To: <4be0676f-b828-4fce-9805-e187eee8edd2@IMCCAS02.MITRE.ORG> References: <4be0676f-b828-4fce-9805-e187eee8edd2@IMCCAS02.MITRE.ORG> Message-ID: <535D65BC.2040300@riseup.net> On 04/27/2014 09:55 AM, Old_Professor wrote: > I'm looking for a trustworthy and user-friendly encryption product to > use on my Android smart phone. I found four implementations of GPG. I > don't know anything about the competence or trustworthiness of the > implementers. > > I'm concerned that if the phone is lost or stolen, how much resistance > will the GPG implementation have to exposing my passphrase or private key. > > I found: > > APG - Thialfihar > Gnu Privacy Guard -The Guardian Project > OpenKeychain - Dominik Sch?rmann > PGP SMS lite - woodkick Better perhaps would be full-"disk" encryption. Some implementations can wipe storage after N authentication failures. I know Guardian Rom the best . There's also Mike Perry's . From mirimir at riseup.net Sun Apr 27 22:40:45 2014 From: mirimir at riseup.net (Mirimir) Date: Sun, 27 Apr 2014 14:40:45 -0600 Subject: Trustworthy Android implementation ? In-Reply-To: References: Message-ID: <535D6B4D.30506@riseup.net> Somebody doesn't like me :( -------- Original Message -------- Subject: Re: Re: Trustworthy Android implementation ? Date: Sun, 27 Apr 2014 13:20:35 -0700 From: [REDACTED] Reply-To: [REDACTED] To: mirimir hi Mirimir I'm [REDACTED], I'm 24 and here're two photos of myself. Just got your msg back about my ad, I think am not late to reply :( :( ... -------- Original Message -------- Subject: Re: Re: Trustworthy Android implementation ? Date: Sun, 27 Apr 2014 20:27:00 +0000 (UTC) From: [REDACTED] Reply-To: [REDACTED] To: mirimir Hey cool you wrote back :) Wasn't sure if you were real or not it's hard to tell sometimes lol. Can you send me a recent pic to this email? Also you are looking for something really casual right? ... From peter at digitalbrains.com Sun Apr 27 22:48:56 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 27 Apr 2014 22:48:56 +0200 Subject: Trustworthy Android implementation ? In-Reply-To: <535D6B4D.30506@riseup.net> References: <535D6B4D.30506@riseup.net> Message-ID: <535D6D38.6080403@digitalbrains.com> On 27/04/14 22:40, Mirimir wrote: > Somebody doesn't like me :( It's just a spam issue here at the mailing list currently. Every message I write, I get at least one, but more commonly two mails from so-called bachelor ladies, usually with a picture taken by a girl in the bathroom mirror. NSFW. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From mirimir at riseup.net Sun Apr 27 23:54:38 2014 From: mirimir at riseup.net (Mirimir) Date: Sun, 27 Apr 2014 15:54:38 -0600 Subject: Trustworthy Android implementation ? In-Reply-To: <535D6D38.6080403@digitalbrains.com> References: <535D6B4D.30506@riseup.net> <535D6D38.6080403@digitalbrains.com> Message-ID: <535D7C9E.8030201@riseup.net> On 04/27/2014 02:48 PM, Peter Lebbing wrote: > On 27/04/14 22:40, Mirimir wrote: >> Somebody doesn't like me :( > > It's just a spam issue here at the mailing list currently. Every message I > write, I get at least one, but more commonly two mails from so-called bachelor > ladies, usually with a picture taken by a girl in the bathroom mirror. NSFW. > > Peter. Well, I don't mind free soft porn :) But maybe it's from someone who's subscribed. So hey, I invite y'all to send me complete headers for all that you get. Maybe they slip up sometimes, and we can have some fun ;) From mirimir at riseup.net Mon Apr 28 00:28:24 2014 From: mirimir at riseup.net (Mirimir) Date: Sun, 27 Apr 2014 16:28:24 -0600 Subject: Trustworthy Android implementation ? In-Reply-To: <535D6D38.6080403@digitalbrains.com> References: <535D6B4D.30506@riseup.net> <535D6D38.6080403@digitalbrains.com> Message-ID: <535D8488.7090605@riseup.net> On 04/27/2014 02:48 PM, Peter Lebbing wrote: > On 27/04/14 22:40, Mirimir wrote: >> Somebody doesn't like me :( > > It's just a spam issue here at the mailing list currently. Every message I > write, I get at least one, but more commonly two mails from so-called bachelor > ladies, usually with a picture taken by a girl in the bathroom mirror. NSFW. > > Peter. Well, I've received several now from "Clara Anne". All feature the same woman, and were apparently shot in the same session. Also, there's a list on the counter, with some entries crossed out. I'm guessing that she was filling an order ;) And her face seems dead, so maybe she's a junkie. Very sad, altogether :( From 2014-667rhzu3dc-lists-groups at riseup.net Mon Apr 28 15:07:15 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 28 Apr 2014 14:07:15 +0100 Subject: UI terminology for calculated validities In-Reply-To: <535BE95F.1040601@dougbarton.us> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <535BE95F.1040601@dougbarton.us> Message-ID: <717019216.20140428140715@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 26 April 2014 at 6:14:07 PM, in , Doug Barton wrote: > But there are other mechanisms besides signatures that > will allow you to use the key, Such as? Without signatures or "trust-model always" my email app throws an error message and will not encrypt to that key, or even display a message signed by it. > so I'm not sure that > word captures the essence of the activity adequately. > I have a variety of local signatures for keys that I > have verified belong to a certain user, but for a > variety of reasons I don't wish to export those > signatures. Fair enough. A local signature has *potential* meaning beyond simply allowing you to use the key. But I feel "activating" fully captures the essence when the local signature is made with the default "(0) I will not answer." in response to "How carefully have you verified the key you are about to sign actually belongs to the person named above?" - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Wise men learn many things from their enemies. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNeUolXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p8ZQD/1pPOfkLiTL7FRowHKUhRkvLALobGAAzmx/k UQhh6mHwoR6dIgEvEZ/sbm6DY37kWKxSuT15wNrOXeEjNuePz+UJXRNKOQHEgnOb xp1FEbZprc6/mjYQObHl4QTjyWvzWC/lzeoe6apH6s3vfo24yTlw+ruN1ivT334Y h/Jc90oc =UdcR -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Mon Apr 28 15:26:32 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 28 Apr 2014 14:26:32 +0100 Subject: UI terminology for calculated validities In-Reply-To: <535C2CAB.8000303@gmail.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356E622.5000001@fifthhorseman.net> <5356E90A.90600@digitalbrains.com> <5356F230.3010608@josuttis.de> <535829F9.1010503@gmail.com> <1397259291.20140424204510@my_localhost> <53598DE0.2060301@gmail.com> <535AB26B.2060804@fifthhorseman.net> <535C2CAB.8000303@gmail.com> Message-ID: <469930147.20140428142632@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 26 April 2014 at 11:01:15 PM, in , Gabriel Niebler wrote: > I trust, though, that such mixed-case certifcates will > be found very rarely in people's public keyrings Why? If people re-upload their keys to servers to publish additional UIDs and certifications, I see no reason why this should be rare at all. Plenty of people change email addresses frequently, or use several. If they have added an email address since some certifications were obtained on their key, that user-id will bear fewer certifications so will likely appear "valid" to fewer users. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net No matter where you go, there you are. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNeVw1XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p7uQD/28Td02dzUmuuJWkWvcdP7dBIsk86pnyhOEP oCMFZgO8iBcUYCeKV91ZVn1AgA/ap+6xK1ixPXps93tvjc8yHPKYs5J1vGvtFoXe e47tNtij6B/vqQf+LuYdIDamTQIVv9ZIur7y48IEFAr3hcOyY6ekbCZGNWTb4eEc 3DbpWjw9 =IlAE -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Mon Apr 28 15:40:29 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 28 Apr 2014 14:40:29 +0100 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <20140427101100.GA24409@glue.grepular.com> References: <20140427101100.GA24409@glue.grepular.com> Message-ID: <1854412117.20140428144029@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 27 April 2014 at 11:11:00 AM, in , Mike Cardwell wrote: > I solve this problem using an OpenPGP smart card. My > PGP key never touches my work machine, so I never have > to worry about it being compromised. Many employers would not allow you to plug in hardware, so you couldn't use an OpenPGP smart card reader. And many would not allow GnuPG at all if it was not something they generally used. Or if they did use it, many would insist on key escrow or additional decryption key, or using a key they generated for you. > When I left my > previous job, I revoked the UID containing the email > address assigned by that company, and then added the > new UID for the new company. How did the previous employer feel about not having access to any of your archived messages/documents? - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net An idealist is a person who helps other people to be prosperous -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNeWlNXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pC3QD/1K7EUpy/39SeqisqPZKxILagneYBwSsiKVn 2zoXLpIJAVl2usP0TR55A2M70HPMru31vkChVagzPPXr0MLujg950AAERcROVuyY rL2yCzEsuOz0M/C+ioadjivrQRxUcWKLv4qY71uXj7orm5uiK/IcJ3HwNmbkt8vU F77LGp4L =wl0O -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Mon Apr 28 15:47:07 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 28 Apr 2014 14:47:07 +0100 Subject: Fwd: Re: Re: A few newbie Qs In-Reply-To: <535C6523.8010502@sixdemonbag.org> References: <20140427014627.5138418EE3@mx1.mailingbuddies.com> <535C6523.8010502@sixdemonbag.org> Message-ID: <1897852466.20140428144707@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 27 April 2014 at 3:02:11 AM, in , Robert J. Hansen wrote: > Is anyone else getting spam like this the instant they > post to the list? Last week, in response to one of my postings to GnuPG-Users, I got a series of five such messages spread over three days. So far that is the only time I've encountered it. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net People who throw kisses are hopelessly lazy. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNeW+JXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p4JAEAKdc+55XWB4tv1wRf6QjRmwVu8kbSMPKuCaS hQZQqExCXKpXozfCpUKQjjaG8NaxFQCfDvk8mf6vRRKr6EvGf7xBYNznE+ARkMh8 Rmbj5STu23ZgI+dweau1JMwMp1O0SL4EhCRpIUoxfnsd/4/FIfLv0C3htLBIQeCK BVqQ9fN5 =gsl0 -----END PGP SIGNATURE----- From gnupg at lists.grepular.com Mon Apr 28 17:10:31 2014 From: gnupg at lists.grepular.com (Mike Cardwell) Date: Mon, 28 Apr 2014 16:10:31 +0100 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <1854412117.20140428144029@my_localhost> References: <20140427101100.GA24409@glue.grepular.com> <1854412117.20140428144029@my_localhost> Message-ID: <20140428151031.GA22198@glue.grepular.com> * on the Mon, Apr 28, 2014 at 02:40:29PM +0100, MFPA wrote: >> I solve this problem using an OpenPGP smart card. My >> PGP key never touches my work machine, so I never have >> to worry about it being compromised. > > Many employers would not allow you to plug in hardware, so you > couldn't use an OpenPGP smart card reader. And many would not allow > GnuPG at all if it was not something they generally used. Or if they > did use it, many would insist on key escrow or additional decryption > key, or using a key they generated for you. Many companies also make you wear a suit and tie and use Internet Explorer 7. I do not work for these companies. >> When I left my previous job, I revoked the UID containing the email >> address assigned by that company, and then added the new UID for >> the new company. > > How did the previous employer feel about not having access to any > of your archived messages/documents? This is what we call a loaded question. I did not make any data that belonged to the company, unavailable to the company, via any methods, be that encryption, or deletion. My use of OpenPGP was well known, and at no point was it discouraged. Several of my colleagues also used OpenPGP, although I don't believe any of them used a smart card. -- Mike Cardwell https://grepular.com https://emailprivacytester.com OpenPGP Key 35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 598 bytes Desc: Digital signature URL: From 2014-667rhzu3dc-lists-groups at riseup.net Mon Apr 28 18:43:57 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 28 Apr 2014 17:43:57 +0100 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <20140428151031.GA22198@glue.grepular.com> References: <20140427101100.GA24409@glue.grepular.com> <1854412117.20140428144029@my_localhost> <20140428151031.GA22198@glue.grepular.com> Message-ID: <684928040.20140428174357@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 28 April 2014 at 4:10:31 PM, in , Mike Cardwell wrote: > Many companies also make you wear a suit and tie and > use Internet Explorer 7. I do not work for these > companies. Fair enough. I was just pointing out to the OP that the solution that has worked for you would be unavailable to a lot of people. > I did not make any data that belonged to the company, > unavailable to the company, via any methods, be that > encryption, or deletion. Sorry, I was assuming encryption of emails, which you didn't actually say you practised. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Another person's secret is like another person's money: you are not as careful with it as you are with your own -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNehV5XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p5ocEAI4WqInvC1sQrVq5jdA3viv3YNEvMQmidKMl qcHruQwQ/6h0VH8x/SMZjhwdhAB5DdCUskae3j+NVmFvgX+mUIyeN5pAwIiShEkr 25RG7gdpgY2rEZHDcp80LlA7KIot/0UDNCbnUq35IT5RDepjgC4zeLwkUFk3WOLw AdrzWk1I =nCc+ -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Mon Apr 28 20:35:34 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 28 Apr 2014 14:35:34 -0400 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: References: Message-ID: <535E9F76.8090106@fifthhorseman.net> On 04/26/2014 06:21 PM, John Sockwell wrote: > I?m looking for best practices in creating and managing multiple subkeys and uids. > > In my scenario, I have a personal computer and personal email address. In addition, I have an employer provided computer and employer email address. > > I?d like to create a key architecture where if I?m ever compelled to compromise, revoke, or lose access to the signing and encryption keys on my work computer, the security and integrity of my personal files are preserved. The easiest solution seems to be generating separate primary keys for both identities. However, I believe this would undermine the WoT when I move to a new employer by not having all signing and encryption keys originating from the same primary key. > > Is it possible to assign an encryption and signing sub key to a specific uid so I can separate the keys used? No, i think you need to use separate primary keys if you want to be able to separate encrypted work messages from encrypted personal messages. But I also want to point out that some employers may have a legitimate need (even a legal compulsion) to be able to decrypt communications coming to your work-related e-mail. One reasonable solution to this is to provide them an escrowed copy of your encryption-capable subkey, perhaps locked in a way that you would need to be informed (or perhaps deceased?) that they were making use of the escrow. However, i see *no* legitimate need for any employer to be able to forge data signatures or identity certifications from your work-related key. escrow only make sense for encryption-capable keys in limited contexts. If you are in a situation where you are forced by employment to engage in key escrow, you should take steps to ensure that only your work-related encryption subkey is escrowed, and not your primary key, or any signing or certification-capable subkey. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From jwoffpg at gmail.com Mon Apr 28 18:49:30 2014 From: jwoffpg at gmail.com (John Wofford) Date: Mon, 28 Apr 2014 16:49:30 +0000 Subject: hash email addresses / directory privacy enhancement Message-ID: I apologize if this has been discussed before, but wouldn't it make sense to run email addresses through a one-way hash before uploading them to a keyserver? It seems trivial for spammers to scrape all uploaded keys for addresses at this point in time. For example, I upload key associated with address john.smith at example.com to an SKS keyserver. Rather than having the key associated "john.smith at example.com", I think it would make more sense to associate and be searchable by hash XYZ. Therefore, public keys are all still accessible and public, but a user would need to have the knowledge of email address "john.smith at example.com" before using the key (rather than just "browsing" a dump). From mailinglisten at hauke-laging.de Mon Apr 28 21:15:30 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 28 Apr 2014 21:15:30 +0200 Subject: hash email addresses / directory privacy enhancement In-Reply-To: References: Message-ID: <3310477.fchXynacGN@inno> Am Mo 28.04.2014, 16:49:30 schrieb John Wofford: > I apologize if this has been discussed before, Yeah, I was the last one. > sense to run email addresses through a one-way hash before uploading > them to a keyserver? Short answer: It would not work with typical email addresses because their "key space" is too small, enumeration and hash checking would be possible. The real weapon against spammers would be a "transport web of trust" i.e. a "transport signature" by a key which is considered valid for delivering email. But that is ten years from now. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Mon Apr 28 21:22:44 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 28 Apr 2014 21:22:44 +0200 Subject: UI terminology for calculated validities In-Reply-To: <717019216.20140428140715@my_localhost> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <535BE95F.1040601@dougbarton.us> <717019216.20140428140715@my_localhost> Message-ID: <535EAA84.9010803@digitalbrains.com> On 28/04/14 15:07, MFPA wrote: > Such as? Without signatures or "trust-model always" my email app > throws an error message and will not encrypt to that key, or even > display a message signed by it. I was wondering the same thing, but I can think of two more ways: - trust-model direct (and then set validity with "trust" command) - trust: ultimate (note: don't do this!) Still, I doubt Doug meant either of those, so I don't know. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dougb at dougbarton.us Mon Apr 28 21:47:50 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 28 Apr 2014 12:47:50 -0700 Subject: UI terminology for calculated validities In-Reply-To: <535EAA84.9010803@digitalbrains.com> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <535BE95F.1040601@dougbarton.us> <717019216.20140428140715@my_localhost> <535EAA84.9010803@digitalbrains.com> Message-ID: <535EB066.8040907@dougbarton.us> On 04/28/2014 12:22 PM, Peter Lebbing wrote: > On 28/04/14 15:07, MFPA wrote: >> Such as? Without signatures or "trust-model always" my email app >> throws an error message and will not encrypt to that key, or even >> display a message signed by it. > > I was wondering the same thing, but I can think of two more ways: > > - trust-model direct (and then set validity with "trust" command) > - trust: ultimate (note: don't do this!) > > Still, I doubt Doug meant either of those ... or all of them. :) My point was simply that signatures don't "activate" keys. ... and I'm not necessarily trying to sway anyone on "verify" vs. "authenticate" either. I would be sort of Ok with "authenticate," although one could argue that the common usage of that word carries connotations that are unattractive for this use case. One of the origins of this topic was actually regarding Enigmail's knob that is titled "Always trust ..." for sending encrypted mail to keys you haven't signed. I was thinking through how I would like to phrase that, and I came up with "Allow encryption to keys you have not verified" and thought that verified/verification was a good general purpose term to replace the idea of "validity" and differentiate it completely from "trust." Doug From doark at mail.com Mon Apr 28 21:48:04 2014 From: doark at mail.com (frank ernest) Date: Mon, 28 Apr 2014 15:48:04 -0400 Subject: A few newbie Qs Message-ID: <20140428194804.158020@gmx.com> The fact that you can't use the plain text and the cipher text to recover the private key is simply AMAZING. You really should mention that fact in the faq. >> Is it polite to post saying that you want to sign keys with somebody >> on a random mailing list? > > Depends a lot on the mailing list. ?I wish I could give clearer advice > than that. Ok, how about this one? I also fequent the nano and curl mailing lists. >> Is there a limit practical or imposed on the lenght of a passpharse? >> ?I'm thinking of a 740 char passphrase that, though containing >> sentences and, therefore, making sense, (though perhaps only to some >> sick people like me,) and also containing repetitions of words 4+ >> chars long, is really easy for me to remember. Do you think that it >> would be a good passphrase? > > No. > > English has about 1.5 bits of entropy per glyph. ?Past about 384 letters > you're not making things any harder to guess. ?Long passphrases also > silently encourage users to do risky things like cut-and-paste them. > (It's very easy for malware to look at the contents of your clipboard > buffer.) So, what you are saying is that past 384 chars, a longer passpharse ceases to be worth the effort? Did your figuring take into accout the fact that I'm using puntuation marks too (max 68+26*2 chars of entropy?) Another worthwile Q, do people audit the gnupg source code for bugs? If so how often? (I'm thinking as I write this of an idiotic but in the openssl package. (The C in C is soft for S as in SANITIZE, not like K for KILL yourself.)) Yes, I could audit the source, but not for logical errors as I would not understand the algorithms involved. From 2014-667rhzu3dc-lists-groups at riseup.net Mon Apr 28 22:44:19 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 28 Apr 2014 21:44:19 +0100 Subject: UI terminology for calculated validities In-Reply-To: <535EB066.8040907@dougbarton.us> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <535BE95F.1040601@dougbarton.us> <717019216.20140428140715@my_localhost> <535EAA84.9010803@digitalbrains.com> <535EB066.8040907@dougbarton.us> Message-ID: <564735350.20140428214419@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 28 April 2014 at 8:47:50 PM, in , Doug Barton wrote: > My point was simply that signatures don't "activate" > keys. I guess "activate" is a bit too close for comfort to "enable," which doesn't involve signatures. > One of the origins of this topic was actually regarding > Enigmail's knob that is titled "Always trust ..." for > sending encrypted mail to keys you haven't signed. I > was thinking through how I would like to phrase that, "Always trust ..." has the advantage of being similar to GnuPG's own "trust-model always." - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net After all is said and done, a lot more will be said than done. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNevbVXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p8/kEAMY7ug7TUxGu3cwQ/z0LCpXrwjbSaKDcE9/h ybmeE0ypfZVzmRM9hkZEDT4jRuLZeJzc3ffMw+H08CDklcJ8gB+J+DtlqpRvG2Xo +e7C2AsoKWa9Z2XnTOKCdZs2p1Pnuc8XbhYMUiprlumjeMJfy8bDGPa3jPkshjhE 2brdri9H =D5O6 -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Tue Apr 29 01:17:30 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 29 Apr 2014 00:17:30 +0100 Subject: hash email addresses / directory privacy enhancement In-Reply-To: References: Message-ID: <127577464.20140429001730@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 28 April 2014 at 5:49:30 PM, in , John Wofford wrote: > I apologize if this has been discussed before, I have taken part in such discussions before. A quick search suggests to look in the list archives for around July 2010, Feb/March 2011, and January 2012. > but > wouldn't it make sense to run email addresses through a > one-way hash before uploading them to a keyserver? I would love to do this for both email addresses and names, for privacy reasons. > It > seems trivial for spammers to scrape all uploaded keys > for addresses at this point in time. Probably quicker and easier for spammers to just randomly generate addresses. And there will be so many out-of-date email addresses on the keyservers that it would not be worth the effort to scrape them. I have a key on the servers for just over four years now with a valid address that has been used for no other purpose and has not received a single email. OK, not a statistically valid experiment but I'm sure plenty of others have done similar. > For example, I upload key associated with address > john.smith at example.com to an SKS keyserver. Rather than > having the key associated "john.smith at example.com", I > think it would make more sense to associate and be > searchable by hash XYZ. In previous discussion, knowledgeable people tell me they see little-to-no merit in the suggestion. > Therefore, public keys are all > still accessible and public, but a user would need to > have the knowledge of email address > "john.smith at example.com" before using the key (rather > than just "browsing" a dump). There is little or no evidence of this type of spam. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net To know what we know, and know what we do not know, is wisdom. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNe4ZNXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p27sD/Ard/Mx55WfbPNnjIfM1D2mhvuVIKpwwzvPE FP0HBET0bXYRnGpxmxY8+vQyJDucELCfcITSb9e5KpR/dLq0lwznS/4fI2znBUq+ VRL25WA6WKBHEKT9qOtECSk6I2dah+BnJWB+B/+T/7FsnSO3S9bByZ+95NJRDfk+ EkEKCQCQ =DA3e -----END PGP SIGNATURE----- From peter at digitalbrains.com Tue Apr 29 10:51:35 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 29 Apr 2014 10:51:35 +0200 Subject: hash email addresses / directory privacy enhancement In-Reply-To: <127577464.20140429001730@my_localhost> References: <127577464.20140429001730@my_localhost> Message-ID: <535F6817.8070706@digitalbrains.com> On 29/04/14 01:17, MFPA wrote: > I have a key on the servers for just over four years now with a valid > address that has been used for no other purpose and has not received a > single email. OK, not a statistically valid experiment but I'm sure > plenty of others have done similar. I have a key on the keyservers for the singular purpose of seeing how much spam that address gets. I only get 419 scams, for some reason. These are more manual processes than usual spamming, so maybe they are also the only ones to do the extra work of scanning the keyservers? Pure conjecture. But it hardly ever happens. 22 attempted scams in 3 years, and they arrive in batches. 7 batches to be precise; 7 distinct moments in time that scams arrived on that address. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From mailinglisten at hauke-laging.de Tue Apr 29 11:13:46 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 29 Apr 2014 11:13:46 +0200 Subject: hash email addresses / directory privacy enhancement In-Reply-To: <535F6817.8070706@digitalbrains.com> References: <127577464.20140429001730@my_localhost> <535F6817.8070706@digitalbrains.com> Message-ID: <1841886.cxNgcJmSGr@inno> Am Di 29.04.2014, 10:51:35 schrieb Peter Lebbing: > But it hardly ever happens. 22 attempted scams in 3 years, and they > arrive in batches. 7 batches to be precise; 7 distinct moments in > time that scams arrived on that address. That is interesting but if it is supposed to be an answer then I guess from the perspective of the "average" user it answers the wrong question. The answered question is: "Does uploading my certificate to a public key server cause a spam problem for me TODAY?" This answer is no. But the reason is not that keyservers are kind of spam-safe but that this address source is not interesting enough for spammers (maybe they ? non-crypto users ? are not even aware of it) due to its limited size and the kind of users you may expect behind these addresses. But: Those of us who do not like to regularly throw their email addresses away will usually be more interested in the answer to a slightly different question: "Will uploading my certificate to a public key server cause a spam problem for me someday (not in the far future)?" Nobody knows. Especially as you don't get the addresses off of the keyservers. We wish for the success of crypto (in usage share). But if it ever comes (I am working hard on it...) then it will have unpleasant side effects. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Tue Apr 29 11:59:21 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 29 Apr 2014 11:59:21 +0200 Subject: hash email addresses / directory privacy enhancement In-Reply-To: <1841886.cxNgcJmSGr@inno> References: <127577464.20140429001730@my_localhost> <535F6817.8070706@digitalbrains.com> <1841886.cxNgcJmSGr@inno> Message-ID: <535F77F9.8070700@digitalbrains.com> On 29/04/14 11:13, Hauke Laging wrote: > if it is supposed to be an answer then I guess from the perspective of the > "average" user it answers the wrong question. It wasn't. It was an elaboration on one particular aspect of the answer MFPA gave. > "Will uploading my certificate to a public key server cause a spam problem > for me someday (not in the far future)?" Nobody knows. Especially as you > don't get the addresses off of the keyservers. The problem with keeping an e-mail address secret is you need to keep it secret all of the time, while it only needs to leak to spammers once. Those are overwhelming odds. If just one of your correspondents is infected by a virus that harvests their addressbook or their mail folders, you've lost the battle. Th?t is an answer. Not a new one, though. It's been said multiple times and can be found in the mailing list archives. The latest version of the sample-size-of-one statistics of my experiment, on the other hand, were a new addition. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From martijn.list at gmail.com Tue Apr 29 11:11:23 2014 From: martijn.list at gmail.com (martijn.list) Date: Tue, 29 Apr 2014 11:11:23 +0200 Subject: Validation of User ID with invalid (non UTF-8) encoding Message-ID: <535F6CBB.1000400@gmail.com> Hi, Some keys stored on the public key servers have User IDs which seem to be encoded with a different encoding than UTF-8. For example the key with key ID 0xA8364AC589C44886 shows an invalid character when viewed online: http://pgp.mit.edu/pks/lookup?search=0xA8364AC589C44886 gpg is able to validate the User ID $ gpg --check-sigs 0xA8364AC589C44886 pub 1024D/89C44886 1999-09-30 uid Lasse M\xberkedahl Larsen sig! 89C44886 1999-09-30 Lasse M\xberkedahl Larsen sub 2048g/0CA36EF9 1999-09-30 sig! 89C44886 1999-09-30 Lasse M\xberkedahl Larsen My own Java based tool however fails to validate this User ID, i.e., the calculated hash always returns a different value. Also PGP desktop reports that the signature is incorrect. Any idea why this User ID validates correctly with gpg but not with other tools? Does gpg handle non-UTF-8 encoded User IDs differently? Kind regards, Martijn Brinkers From labrani at gmail.com Tue Apr 29 10:41:42 2014 From: labrani at gmail.com (labrani) Date: Tue, 29 Apr 2014 10:41:42 +0200 Subject: hkps ssl problem Message-ID: <09484176-1F67-4B33-A756-C56F2C9AE686@gmail.com> Hello I'm having some problem while trying to use an hkps pool server as keyserver. i am using gpg2 client version on a mac os x maverick os. i have download the cacert file from the site and i verify that i have the good one while testing with curl. here is the configuration of my client : keyserver hkps://hkps.pool.sks-keyservers.net keyserver-options ca-cert-file=/pathto/.gnupg/sks-keyservers.netCA.pem keyserver-options no-honor-keyserver-url keyserver-options debug keyserver-options verbose keyserver-options verbose auto-key-locate keyserver fixed-list-mode keyid-format 0xlong verify-options show-uid-validity list-options show-uid-validity default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed personal-digest-preferences SHA512 cert-digest-algo SHA512 no-emit-version and here is the error i have : gpg2 --recv-keys 0xD9B53384 gpg: requesting key 0xD9B53384 from hkps server hkps.pool.sks-keyservers.net gpgkeys: curl version = libcurl/7.30.0 SecureTransport zlib/1.2.5 Host: hkps.pool.sks-keyservers.net Command: GET * Adding handle: conn: 0x1184800 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x1184800) send_pipe: 1, recv_pipe: 0 * About to connect() to hkps.pool.sks-keyservers.net port 443 (#0) * Trying 80.239.156.219... * Connected to hkps.pool.sks-keyservers.net (80.239.156.219) port 443 (#0) * SSL certificate problem: Invalid certificate chain * Closing connection 0 gpgkeys: HTTP fetch error 60: SSL certificate problem: Invalid certificate chain gpg: no valid OpenPGP data found. gpg: Total number processed: 0 thxs for your help -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Apr 29 14:08:58 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Apr 2014 14:08:58 +0200 Subject: Validation of User ID with invalid (non UTF-8) encoding In-Reply-To: <535F6CBB.1000400@gmail.com> (martijn list's message of "Tue, 29 Apr 2014 11:11:23 +0200") References: <535F6CBB.1000400@gmail.com> Message-ID: <87r44gibhh.fsf@vigenere.g10code.de> On Tue, 29 Apr 2014 11:11, martijn.list at gmail.com said: > Some keys stored on the public key servers have User IDs which seem to > be encoded with a different encoding than UTF-8. Right. Old PGP versions didn't care about the requirement for utf-8 and used whatever the terminal was configured to (i.e. Latin-1). But that should only be a display problem. See below for the code GPA uses to detect and fix the display problem. > $ gpg --check-sigs 0xA8364AC589C44886 > pub 1024D/89C44886 1999-09-30 > uid Lasse M\xberkedahl Larsen > sig! 89C44886 1999-09-30 Lasse M\xberkedahl Larsen > sub 2048g/0CA36EF9 1999-09-30 > sig! 89C44886 1999-09-30 Lasse M\xberkedahl Larsen > > My own Java based tool however fails to validate this User ID, i.e., the > calculated hash always returns a different value. Also PGP desktop Note that the above output is for humans and has been sanitized to inhibit attacks using ANSI control sequences. To check the signature you need to use the bare OpenPGP packets and not some gpg output. I am not aware of any PGP problems with user ids - the verification uses the data verbatim and is transparent to the encoding. Shalom-Salam, Werner ==== /* Return the user ID, making sure it is properly UTF-8 encoded. Allocates a new string, which must be freed with g_free (). */ static gchar * string_to_utf8 (const gchar *string) { const char *s; if (!string) return NULL; /* Due to a bug in old and not so old PGP versions user IDs have been copied verbatim into the key. Thus many users with Umlauts et al. in their name will see their names garbled. Although this is not an issue for me (;-)), I have a couple of friends with Umlauts in their name, so let's try to make their life easier by detecting invalid encodings and convert that to Latin-1. We use this even for X.509 because it may make things even better given all the invalid encodings often found in X.509 certificates. */ for (s = string; *s && !(*s & 0x80); s++) ; if (*s && ((s[1] & 0xc0) == 0x80) && ( ((*s & 0xe0) == 0xc0) || ((*s & 0xf0) == 0xe0) || ((*s & 0xf8) == 0xf0) || ((*s & 0xfc) == 0xf8) || ((*s & 0xfe) == 0xfc)) ) { /* Possible utf-8 character followed by continuation byte. Although this might still be Latin-1 we better assume that it is valid utf-8. */ return g_strdup (string); } else if (*s && !strchr (string, 0xc3)) { /* No 0xC3 character in the string; assume that it is Latin-1. */ return g_convert (string, -1, "UTF-8", "ISO-8859-1", NULL, NULL, NULL); } else { /* Everything else is assumed to be UTF-8. We do this even that we know the encoding is not valid. However as we only test the first non-ascii character, valid encodings might follow. */ return g_strdup (string); } } -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mwood at IUPUI.Edu Tue Apr 29 16:23:10 2014 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Tue, 29 Apr 2014 10:23:10 -0400 Subject: hash email addresses / directory privacy enhancement In-Reply-To: <1841886.cxNgcJmSGr@inno> References: <127577464.20140429001730@my_localhost> <535F6817.8070706@digitalbrains.com> <1841886.cxNgcJmSGr@inno> Message-ID: <20140429142310.GE14693@IUPUI.Edu> Eh, I consider the possibility of address harvesting an opportunity for a bit of sport. I enjoy occasionally crafting a new regular expression to make maildrop automatically toss a new strain of UCE. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Machines should not be friendly. Machines should be obedient. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From 2014-667rhzu3dc-lists-groups at riseup.net Tue Apr 29 19:46:30 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 29 Apr 2014 18:46:30 +0100 Subject: hash email addresses / directory privacy enhancement In-Reply-To: <20140429142310.GE14693@IUPUI.Edu> References: <127577464.20140429001730@my_localhost> <535F6817.8070706@digitalbrains.com> <1841886.cxNgcJmSGr@inno> <20140429142310.GE14693@IUPUI.Edu> Message-ID: <1014993850.20140429184630@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 29 April 2014 at 3:23:10 PM, in , Mark H. Wood wrote: > Eh, I consider the possibility of address harvesting an > opportunity for a bit of sport. I enjoy occasionally > crafting a new regular expression to make maildrop > automatically toss a new strain of UCE. Does "toss" in this context mean "send, "delete," or "reject?" - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Gypsy Dwarf Escapes Prison: Small Medium at large -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNf5YlXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p+2kEAJz+1J5tyXCQhtBqO+sAt7ndmZC/5TyAZlXT Ys9xyK+8zt0xjc/ijzGwABbdyJs8698BbYQRBrSv5GHkAyFWXjbcfjXWAcn0IaTB XyeqR8uYu+YRB/5hXV2zTHOu/yhGl5H/E/t5TTv+AITuVlWmSYFEwYIZ3N3igiGW iErCmtRX =uBbF -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Tue Apr 29 20:18:01 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 29 Apr 2014 19:18:01 +0100 Subject: hash email addresses / directory privacy enhancement In-Reply-To: <535F77F9.8070700@digitalbrains.com> References: <127577464.20140429001730@my_localhost> <535F6817.8070706@digitalbrains.com> <1841886.cxNgcJmSGr@inno> <535F77F9.8070700@digitalbrains.com> Message-ID: <1497974595.20140429191801@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 29 April 2014 at 10:59:21 AM, in , Peter Lebbing wrote: > The problem with keeping an e-mail address secret is > you need to keep it secret all of the time, while it > only needs to leak to spammers once. Those are > overwhelming odds. Does the email address really need to "leak" to spammers at all? I have a couple of domains set up with catch-all email forwarding; occasionally for about a couple of weeks one or other domain receives spam messages addressed to (or bounces to messages spoofed to be "from") random names at the domain, then it stops and doesn't happen again for months or years. > If just one of your correspondents > is infected by a virus that harvests their addressbook > or their mail folders, you've lost the battle. For a couple of weeks until the spammer moves onto a new set of email addresses. But, just maybe, it becomes an ongoing problem and makes the address unuseable. In that case, somebody who uses a unique email address to correspond with each contact simply tells that contact a new address and retires the old one. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Confusion is always the most honest response -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNf7OVXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pRhoEALkc01i9Ssiu5til0n53MGG/UFuEz0fovMss 2XcW9fWpyxnuRUAAgqed2QNEiSjX3VIB+ivDsS6g0m0xsWdURHA7GPuSYJmkvnlC pTuT25EUqPOXaYcoNZWAig+UjdD/sDEg0GZn1C1ASby5pn/hYb/54T63pBJEnWJR 5DbVLg0x =wD/x -----END PGP SIGNATURE----- From vedaal at nym.hush.com Tue Apr 29 20:18:40 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 29 Apr 2014 14:18:40 -0400 Subject: hash email addresses / directory privacy enhancement In-Reply-To: <1014993850.20140429184630@my_localhost> References: <127577464.20140429001730@my_localhost> <535F6817.8070706@digitalbrains.com> <1841886.cxNgcJmSGr@inno> <20140429142310.GE14693@IUPUI.Edu> <1014993850.20140429184630@my_localhost> Message-ID: <20140429181840.457E7A03A0@smtp.hushmail.com> I don't know how much of a spam problem there is by having keyservers harvested for their e-mail addresses, but if indeed it does become a problem, then maybe at that point, the e-mail addresses should not be listed on the keyserver. When a person generates a new key, the e-mail required by gnupg for key generation, can be listed as something benign such as name at my.keys The key will still be identified by the fingerprint, and the e-mail address can be given out by the owner to whomever she/he wants to give it to. Many keys no longer have the original e-mail address as when they were generated, so the question becomes; "If the key is accessible by the fingerprint and key name, and people consider the fingerprint the most trustable identifier of the key, and an attacker cannot forge a key with the same fingerprint, then why is it necessary to have the e-mail address on the keyserver at all? vedaal From 2014-667rhzu3dc-lists-groups at riseup.net Tue Apr 29 20:58:35 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 29 Apr 2014 19:58:35 +0100 Subject: hash email addresses / directory privacy enhancement In-Reply-To: <20140429181840.457E7A03A0@smtp.hushmail.com> References: <127577464.20140429001730@my_localhost> <535F6817.8070706@digitalbrains.com> <1841886.cxNgcJmSGr@inno> <20140429142310.GE14693@IUPUI.Edu> <1014993850.20140429184630@my_localhost> <20140429181840.457E7A03A0@smtp.hushmail.com> Message-ID: <19610715834.20140429195835@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 29 April 2014 at 7:18:40 PM, in , vedaal at nym.hush.com wrote: > When a person generates a new key, the e-mail required > by gnupg for key generation, can be listed as something > benign such as name at my.keys Or, IMHO better still, left blank. Although I would prefer the ability to include it hashed. > so the question becomes; > "If the key is accessible by the fingerprint and key > name, and people consider the fingerprint the most > trustable identifier of the key, and an attacker cannot > forge a key with the same fingerprint, then why is it > necessary to have the e-mail address on the keyserver > at all? I think it is more a convenience than a necessity. But it became a de facto standard, which the writers of some email software have relied upon to select encryption keys by email address. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Of course it's a good idea - it's mine! -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNf9mJXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pNoED/3670bloe3SMow42GKhkZ2ZF2KIk/ZizmczJ B0rl9rNWOlvqCqwACE3WrpyhiD0drwWy8ho4koPpqVm1IpAClH9c2UKj5TOkcoiv yl8LzscfvuIIiee/xNIH/Uq0s5DDBECharMyiL264v9bKvM0l8QRcA96B5mKiMek CUE/fnyX =IB77 -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Tue Apr 29 21:22:52 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 29 Apr 2014 20:22:52 +0100 Subject: UI terminology for calculated validities In-Reply-To: <535EAA84.9010803@digitalbrains.com> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <535BE95F.1040601@dougbarton.us> <717019216.20140428140715@my_localhost> <535EAA84.9010803@digitalbrains.com> Message-ID: <768948229.20140429202252@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 28 April 2014 at 8:22:44 PM, in , Peter Lebbing wrote: > - trust-model direct (and then set validity with > "trust" command) - trust: ultimate (note: don't do > this!) But unless I am missing something, "trust: ultimate" is the only way the trust command can validate a key without removing validity from all the keys on the keyring that are validated by signatures. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net We're all shipwrecked on this idea that everything has to be explained. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNf/BNXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pFt0D/1WBtZxIrzbdmow/yw7fBIlhHLoe6XgKmN+W SjvuhCn6DvL2MpzavV4abQvm7E6olS0v+bMyzCQrEgDjRincuHUsso3XmQMMSCdC 6//zrUk9YIpKYl4gsEpS3Spp3+1juPfuWj0r9o40jH+nUYfSUOofaIgjhvf0qe/M boDVEBmT =pY5b -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Tue Apr 29 21:34:27 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 29 Apr 2014 21:34:27 +0200 Subject: UI terminology for calculated validities In-Reply-To: <768948229.20140429202252@my_localhost> References: <53564380.10000@josuttis.de> <535EAA84.9010803@digitalbrains.com> <768948229.20140429202252@my_localhost> Message-ID: <1495086.yRroNSC0aI@inno> Am Di 29.04.2014, 20:22:52 schrieb MFPA: > validate a key without removing validity from > all the keys on the keyring that are validated by signatures. I don't understand that. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From 2014-667rhzu3dc-lists-groups at riseup.net Wed Apr 30 01:25:13 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 30 Apr 2014 00:25:13 +0100 Subject: UI terminology for calculated validities In-Reply-To: <1495086.yRroNSC0aI@inno> References: <53564380.10000@josuttis.de> <535EAA84.9010803@digitalbrains.com> <768948229.20140429202252@my_localhost> <1495086.yRroNSC0aI@inno> Message-ID: <1886647532.20140430002513@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 29 April 2014 at 8:34:27 PM, in , Hauke Laging wrote: > Am Di 29.04.2014, 20:22:52 schrieb MFPA: >> But unless I am missing something, "trust: ultimate" >> is the only way the trust command can validate a key >> without removing validity from all the keys on the >> keyring that are validated by signatures. > I don't understand that. The selection of "trust-model direct" tells your copy of GNUPG to ignore signatures, and thereby removes validity from all the keys on the keyring that are validated by signatures. "Trust: ultimate" validates a key whatever "trust-model" is in operation, (but also allows whoever controls that key to tell your copy of GnuPG what keys to accept). "Trust:" followed by any other option except "ultimate" appears to have no effect unless the "trust-model direct" is in operation. Have I got this right? - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net I hit the CTRL key but I'm still not in control! -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNgNN5XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pLXsD/36Wj4oVmagdywJZhmWukGCJ/ys+mH9ImjgT Zgy4h7c062auYqFfaTN6ScBZqxGZDuso6PnZAi+4iyCgkk3HAUHBBT2RGE6/jnBy qTAf5/ZiZtJzt4p8q/wOsBsdNTPxkPvY1HLJbJJl9BH/U7NW38hnCuQViyb+rXEF p5NIiPWR =acCn -----END PGP SIGNATURE----- From koen.vanimpe at cudeso.be Wed Apr 30 00:40:50 2014 From: koen.vanimpe at cudeso.be (Koen) Date: Wed, 30 Apr 2014 00:40:50 +0200 Subject: Get expiration date by searching on keyservers Message-ID: <53602A72.9060805@vanimpe.eu> Hi, I use '--keyserver --search-keys to get info on a number of keys. As far as I can tell, that doesn't return an expiration date (if that exists). Are there other ways to easily check on the exp. date, besides importing the key and then verifying the expiration date? thanks, koen From wk at gnupg.org Wed Apr 30 09:32:03 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Apr 2014 09:32:03 +0200 Subject: We are now at ic6au7wa3f6naxjq.onion Message-ID: <87oazjgtn0.fsf@vigenere.g10code.de> Hi, as part of the Crowdfunding campaign, I promised to offer an onion address for wwww.gnupg.org . Well, being a well known site, it does not really make much sense to have it as a hidden service; but if www.gnupg.org is accessed anyway via tor we could also avoid the extra TLS layer and and allow direct access via tor: ic6au7wa3f6naxjq.onion Note that lists.gnupg.org and some other services are not yet available via an onion address. Salam-Shalom, 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: 180 bytes Desc: not available URL: From wk at gnupg.org Wed Apr 30 09:41:13 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Apr 2014 09:41:13 +0200 Subject: Access to www.gnupg.org only via TLS Message-ID: <87k3a7gt7q.fsf@vigenere.g10code.de> Hi, I have changed the website setup so that any plain text access to www.gnupg.org is redirected to https://www.gnupg.org . Strict Transport Security (HSTS) has also been enabled. In case of problems with TLS you may use www dot tla-friendly dot gnupg.org to view the pages. Note that https is not enforced for lists.gnupg.org and the other services because over there we use CAcert certificates which do not work widely enough. If there is an interest to have lists at https as well, I consider to purchase a certificate for it. 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: 180 bytes Desc: not available URL: From dougb at dougbarton.us Wed Apr 30 10:04:18 2014 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 30 Apr 2014 01:04:18 -0700 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <87k3a7gt7q.fsf@vigenere.g10code.de> References: <87k3a7gt7q.fsf@vigenere.g10code.de> Message-ID: <5360AE82.6070505@dougbarton.us> On 04/30/2014 12:41 AM, Werner Koch wrote: > Hi, > > I have changed the website setup so that any plain text access to > www.gnupg.org is redirected to https://www.gnupg.org . Strict Transport > Security (HSTS) has also been enabled. > > In case of problems with TLS you may use www dot tla-friendly dot > gnupg.org to view the pages. > > Note that https is not enforced for lists.gnupg.org and the other > services because over there we use CAcert certificates which do not work > widely enough. All good news. :) > If there is an interest to have lists at https as well, > I consider to purchase a certificate for it. I know it's been discussed on the list before, but I'm quite happy with https://www.startssl.com/, and you certainly can't beat the price. :) Doug From peter at digitalbrains.com Wed Apr 30 10:35:15 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 30 Apr 2014 10:35:15 +0200 Subject: UI terminology for calculated validities In-Reply-To: <1886647532.20140430002513@my_localhost> References: <53564380.10000@josuttis.de> <535EAA84.9010803@digitalbrains.com> <768948229.20140429202252@my_localhost> <1495086.yRroNSC0aI@inno> <1886647532.20140430002513@my_localhost> Message-ID: <5360B5C3.2070802@digitalbrains.com> On 30/04/14 01:25, MFPA wrote: > "Trust:" followed by any other option except "ultimate" > appears to have no effect unless the "trust-model direct" is in > operation. > > Have I got this right? No, in the Web of Trust models[1], you can assign full and marginal trust to keys. With the default parameters, 1 signature of a fully trusted, valid key makes another key valid, or 3 signatures from marginally trusted keys. In fact, I don't think there is any practical difference between "ultimate trust" and "full trust" in trust-model direct. But I don't know anything about trust-model direct except from experimentation. HTH, Peter. [1] That is, pgp and classic. pgp is the default mode. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From gnupg at lists.grepular.com Wed Apr 30 11:09:53 2014 From: gnupg at lists.grepular.com (Mike Cardwell) Date: Wed, 30 Apr 2014 10:09:53 +0100 Subject: We are now at ic6au7wa3f6naxjq.onion In-Reply-To: <87oazjgtn0.fsf@vigenere.g10code.de> References: <87oazjgtn0.fsf@vigenere.g10code.de> Message-ID: <20140430090953.GA14003@glue.grepular.com> * on the Wed, Apr 30, 2014 at 09:32:03AM +0200, Werner Koch wrote: > as part of the Crowdfunding campaign, I promised to offer an onion > address for wwww.gnupg.org . Well, being a well known site, it does not > really make much sense to have it as a hidden service; but if > www.gnupg.org is accessed anyway via tor we could also avoid the extra > TLS layer and and allow direct access via tor: > > ic6au7wa3f6naxjq.onion > > Note that lists.gnupg.org and some other services are not yet available > via an onion address. I just did a quick "wget ic6au7wa3f6naxjq.onion" and inspected the HTML and noticed that some of the links are absolute and refer to www.gnupg.org, which would take people away from the none-hidden version of the site. Example: Aegypten Links like that should probably be made relative. Also, note that the link there is none-https, which would redirect people out of the "secure" version of the site if they're using a browser which does not support HSTS, e.g Internet Explorer 11 and below. -- Mike Cardwell https://grepular.com https://emailprivacytester.com OpenPGP Key 35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 598 bytes Desc: Digital signature URL: From wk at gnupg.org Wed Apr 30 11:17:02 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Apr 2014 11:17:02 +0200 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <5360AE82.6070505@dougbarton.us> (Doug Barton's message of "Wed, 30 Apr 2014 01:04:18 -0700") References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> Message-ID: <87eh0fgos1.fsf@vigenere.g10code.de> On Wed, 30 Apr 2014 10:04, dougb at dougbarton.us said: > I know it's been discussed on the list before, but I'm quite happy > with https://www.startssl.com/, and you certainly can't beat the > price. :) Unless you want to revoke a certificate. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gollo at fsfe.org Wed Apr 30 10:25:24 2014 From: gollo at fsfe.org (Martin Gollowitzer) Date: Wed, 30 Apr 2014 10:25:24 +0200 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <5360AE82.6070505@dougbarton.us> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> Message-ID: <20140430082524.GA21587@platinum.gollo.at> * Doug Barton [140430 10:05, mID <5360AE82.6070505 at dougbarton.us>]: > On 04/30/2014 12:41 AM, Werner Koch wrote: > >Hi, > > > >I have changed the website setup so that any plain text access to > >www.gnupg.org is redirected to https://www.gnupg.org . Strict Transport > >Security (HSTS) has also been enabled. > > > >In case of problems with TLS you may use www dot tla-friendly dot > >gnupg.org to view the pages. > > > >Note that https is not enforced for lists.gnupg.org and the other > >services because over there we use CAcert certificates which do not work > >widely enough. > > All good news. :) > > >If there is an interest to have lists at https as well, > >I consider to purchase a certificate for it. > > I know it's been discussed on the list before, but I'm quite happy > with https://www.startssl.com/, and you certainly can't beat the > price. :) You might want to consider my blogpost about StartSSL [1]. Despite that, the SSLLabs test shows two small issues when testing gnupg.org [2], one of which is the too short time sent in the HSTS header. [1] http://blogs.fsfe.org/gollo/2014/04/13/what-the-heartbleed-bug-revealed-to-me/ [2] https://www.ssllabs.com/ssltest/analyze.html?d=gnupg.org Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 665 bytes Desc: Digital signature URL: From wk at gnupg.org Wed Apr 30 14:21:15 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Apr 2014 14:21:15 +0200 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <20140430082524.GA21587@platinum.gollo.at> (Martin Gollowitzer's message of "Wed, 30 Apr 2014 10:25:24 +0200") References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> Message-ID: <8738gvgg90.fsf@vigenere.g10code.de> On Wed, 30 Apr 2014 10:25, gollo at fsfe.org said: > the SSLLabs test shows two small issues when testing gnupg.org [2], one > of which is the too short time sent in the HSTS header. Ooops, copy and paste error: I missed the last 0 of max-age=31536000. Also fixed in the Boa source code examples. The missing forward secrecy is mainly an issue with IE which gives non-FS algorithm suites a higher preference; but for older IEs a non-FS algorithm is required. We don't have any user data at this site so the missing forward secrecy for anyway bugged Microsoft browsers should not be an issue. Salam-Shalom, Werner p.s I understand why Microsoft makes it hard to use FS - that abbreviation is also used for free software ;-) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mwood at IUPUI.Edu Wed Apr 30 14:43:36 2014 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Wed, 30 Apr 2014 08:43:36 -0400 Subject: hash email addresses / directory privacy enhancement In-Reply-To: <1014993850.20140429184630@my_localhost> References: <127577464.20140429001730@my_localhost> <535F6817.8070706@digitalbrains.com> <1841886.cxNgcJmSGr@inno> <20140429142310.GE14693@IUPUI.Edu> <1014993850.20140429184630@my_localhost> Message-ID: <20140430124336.GA14263@IUPUI.Edu> On Tue, Apr 29, 2014 at 06:46:30PM +0100, MFPA wrote: > On Tuesday 29 April 2014 at 3:23:10 PM, in > , Mark H. Wood wrote: > > > Eh, I consider the possibility of address harvesting an > > opportunity for a bit of sport. I enjoy occasionally > > crafting a new regular expression to make maildrop > > automatically toss a new strain of UCE. > > Does "toss" in this context mean "send, "delete," or "reject?" Sorry, "delete". -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Machines should not be friendly. Machines should be obedient. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From 2014-667rhzu3dc-lists-groups at riseup.net Wed Apr 30 15:32:44 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 30 Apr 2014 14:32:44 +0100 Subject: UI terminology for calculated validities In-Reply-To: <5360B5C3.2070802@digitalbrains.com> References: <53564380.10000@josuttis.de> <535EAA84.9010803@digitalbrains.com> <768948229.20140429202252@my_localhost> <1495086.yRroNSC0aI@inno> <1886647532.20140430002513@my_localhost> <5360B5C3.2070802@digitalbrains.com> Message-ID: <21113549.20140430143244@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 30 April 2014 at 9:35:15 AM, in , Peter Lebbing wrote: > No, in the Web of Trust models[1], you can assign full > and marginal trust to keys. Of course. I was forgetting that in my experimentation. Would the effect of a non-exportable trust signature be the same? - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net The greater the power, the more dangerous the abuse. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNg+4JXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pZusEAIIl3woEBkfGugi+gJDdpgPv3YmRXPTddXzW ZdAXGisV84gdSEoBaez7LQty5imGLGBRgge90acrvPH43NCgH5WhgC48CHDfENEb JcoXwEm2oLg+DZODrp/Pe9g79Bu8TL0NAD32edUP1qlzybYdprJyJ+yU4wPApyz1 TZ8KNy4D =wLWr -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Wed Apr 30 17:23:43 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 30 Apr 2014 11:23:43 -0400 Subject: Get expiration date by searching on keyservers In-Reply-To: <53602A72.9060805@vanimpe.eu> References: <53602A72.9060805@vanimpe.eu> Message-ID: <5361157F.2040404@fifthhorseman.net> On 04/29/2014 06:40 PM, Koen wrote: > I use '--keyserver --search-keys to get info on a number of > keys. As far as I can tell, that doesn't return an expiration date (if > that exists). > > Are there other ways to easily check on the exp. date, besides importing > the key and then verifying the expiration date? If you want cryptographic proof of the expiration date, you'll want to fetch the keys locally anyway (the keyservers do no cryptographic verification, and even if they did, you would have to decide to trust their report, which you might not want to do). I think fetching the keys you're interested in and handling them locally is your best bet. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Apr 30 17:29:42 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 30 Apr 2014 17:29:42 +0200 Subject: UI terminology for calculated validities In-Reply-To: <21113549.20140430143244@my_localhost> References: <53564380.10000@josuttis.de> <535EAA84.9010803@digitalbrains.com> <768948229.20140429202252@my_localhost> <1495086.yRroNSC0aI@inno> <1886647532.20140430002513@my_localhost> <5360B5C3.2070802@digitalbrains.com> <21113549.20140430143244@my_localhost> Message-ID: <536116E6.5090502@digitalbrains.com> On 30/04/14 15:32, MFPA wrote: > Of course. I was forgetting that in my experimentation. > Would the effect of a non-exportable trust signature be the same? No, I don't think so. I suppose a trust signature places the key at depth 1 in the certification chain, whereas the depth can vary with assigned trust, and the chain is cut off at --max-cert-depth. But this is just what I would expect happens with a trust signature. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dshaw at jabberwocky.com Wed Apr 30 19:25:21 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 30 Apr 2014 13:25:21 -0400 Subject: Get expiration date by searching on keyservers In-Reply-To: <53602A72.9060805@vanimpe.eu> References: <53602A72.9060805@vanimpe.eu> Message-ID: <5467DADD-52B4-406E-9885-6B6B9D958DFD@jabberwocky.com> On Apr 29, 2014, at 6:40 PM, Koen wrote: > Hi, > > I use '--keyserver --search-keys to get info on a number of > keys. As far as I can tell, that doesn't return an expiration date (if > that exists). GPG's keyserver code is capable of displaying expiration date, if the keyserver provides it. Not all do. But - and this is important - like all key data (from expiration date, to revocation status, to the user IDs, etc), the info returned by a keyserver is only informational. You cannot rely on it until you download the key and check it yourself. The keyservers are simply storage, and do not verify the keys sent to them (and you shouldn't trust them even if they claimed to). David From dougb at dougbarton.us Wed Apr 30 21:23:02 2014 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 30 Apr 2014 12:23:02 -0700 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <20140430082524.GA21587@platinum.gollo.at> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> Message-ID: <53614D96.9040108@dougbarton.us> On 04/30/2014 01:25 AM, Martin Gollowitzer wrote: > You might want to consider my blogpost about StartSSL Yeah, I don't quite see your point. They are providing a very valuable service for free, and charge a nominal fee for revoking a cert. If you add up all the times you have not paid fees for the certificates themselves, vs. the rare occasions when you have to revoke one, I think you're still coming out way ahead. Personally I think it's awesome that they're allowing a free revocation re Heartbleed at all, since ... ... your whole premise seems to be invalid as there is no clear evidence at this time (that I'm aware of, and I've been paying attention) that any actual secret keys have been compromised by Heartbleed. It was listed as a potential risk when the vulnerability was first announced, but several groups have done research on that specific point and have found that it would be sufficiently difficult, if not actually impossible; to render this particular risk as negligible at best. Meanwhile, if your response is going to be in the nature of, "Everything I want should be given to me free just because I want it" please don't bother. Doug From kristian.fiskerstrand at sumptuouscapital.com Wed Apr 30 19:33:39 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 30 Apr 2014 19:33:39 +0200 Subject: Get expiration date by searching on keyservers In-Reply-To: <5467DADD-52B4-406E-9885-6B6B9D958DFD@jabberwocky.com> References: <53602A72.9060805@vanimpe.eu> <5467DADD-52B4-406E-9885-6B6B9D958DFD@jabberwocky.com> Message-ID: <536133F3.6050209@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/30/2014 07:25 PM, David Shaw wrote: > On Apr 29, 2014, at 6:40 PM, Koen wrote: > >> Hi, >> >> I use '--keyserver --search-keys to get info on a >> number of keys. As far as I can tell, that doesn't return an >> expiration date (if that exists). > > GPG's keyserver code is capable of displaying expiration date, if > the keyserver provides it. Not all do. To detail a bit more; we had a fix to read expiration from UID self-signatures that is in the current trunk[0]. Earlier versions (including 1.1.4) won't output these properly for the machine readable index. For servers that does support it it can be seen as e.g. http://sks.mrball.net:11371/pks/lookup?op=index&options=mr&search=0x0B7F8B60E3EDFAE3 that displays pub:94CBAFDD30345109561835AA0B7F8B60E3EDFAE3:1:4096:1197735934:1483182002: date -d at 1483182002 Sat Dec 31 12:00:02 CET 2016 > > But - and this is important - like all key data (from expiration > date, to revocation status, to the user IDs, etc), the info > returned by a keyserver is only informational. You cannot rely on > it until you download the key and check it yourself. The > keyservers are simply storage, and do not verify the keys sent to > them (and you shouldn't trust them even if they claimed to). > Very much so, no verification on the validity of the self-signature or other information is performed on the servers. References: [0] https://bitbucket.org/skskeyserver/sks-keyserver/pull-request/12/fixes-for-machine-readable-indexes/diff - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Veni vidi visa I came, I saw, I bought -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTYTPqAAoJEPw7F94F4TagXT8P/1bqNiTPryuHM97qB+h6XjSU qMMH1+uk0Y8w27KaCYGJlOw/KjPnLwKTkA5eCZKvg9KptU1iIv5lh/9fRuaF/2jI YU0cu5sQyZCFilAIlwzOnRlENRs6hKOZktOMR/4eLQBNk+RES/Rjc1S2KVsN9D51 HLu3u8QqwIJqYL78DOR8gUJu6ARyepJHsXdvOeTpbZHC/a2NfaFsJyvBFxnKUISl 6FFG+QaHTPEHYCJT9i112j0+qkySSIUNQCsEMCu4W3DXLea+taDpEDHC94kXCHDd zmBC60dGFi1dnBQruQpsf7KqW++YPaLLmFYOKCtovOGvFK2YoLOdaYO3mJV+k9y8 sm+8/mK2FZfH3I405rDFDZ/MuS6YTXT7+I9v1rRLUelLicSzfnTA1FPvuECgQBU/ qh/AtJ7Mhe3GnQWDbAl3Zdjd65PZo3QH3Ko5L/xj77cPdplP+T7eprHxF8/G17RP qVn7nONs5fB6eVt3Q289OS5Hi41Kxu8mVcXyinah6S9S9tiJ0kPAptP0K94mQ+h3 Jd7JRCXu4eoV95SGroIHLX2HWPSOSUwXmYI0x1Je/vB4h1b+Wv50Iw/H6NjEvBKz uiW3HcdBCFLYG1eemBrFypZH0KqWB1IEF15qu/jATQjN8OR10BszmH6QopCMXFUA nvDd8d+J4vjdpmdKMF+a =ACDv -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Wed Apr 30 22:26:09 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 30 Apr 2014 16:26:09 -0400 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <53614D96.9040108@dougbarton.us> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> Message-ID: <617D25BA-3A28-4A0F-AF9B-C864E08849C1@jabberwocky.com> On Apr 30, 2014, at 3:23 PM, Doug Barton wrote: > ... your whole premise seems to be invalid as there is no clear evidence at this time (that I'm aware of, and I've been paying attention) that any actual secret keys have been compromised by Heartbleed. It was listed as a potential risk when the vulnerability was first announced, but several groups have done research on that specific point and have found that it would be sufficiently difficult, if not actually impossible; to render this particular risk as negligible at best. There were questions early on whether grabbing secret keys was possible via Heartbleed or not. Since then, it's been proven that it is definitely possible. At least one company set up a server and invited people to try and steal the secret key via Heartbleed. It took less than a day: http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge Here's a program that automates the process. Just run it and wait: http://blog.erratasec.com/2014/04/cloudflare-challenge-writeup.html I can't speak to whether actual (meaning "not example keys put there for the purpose of stealing") secret keys have been compromised by Heartbleed, but it's definitely not impossible (or all that difficult now that someone has done the hard part - just start a script and walk away). David From pete at heypete.com Wed Apr 30 22:28:15 2014 From: pete at heypete.com (Pete Stephenson) Date: Wed, 30 Apr 2014 22:28:15 +0200 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <53614D96.9040108@dougbarton.us> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> Message-ID: On Apr 30, 2014 9:25 PM, "Doug Barton" wrote: [snip] > ... your whole premise seems to be invalid as there is no clear evidence at this time (that I'm aware of, and I've been paying attention) that any actual secret keys have been compromised by Heartbleed. It was listed as a potential risk when the vulnerability was first announced, but several groups have done research on that specific point and have found that it would be sufficiently difficult, if not actually impossible; to render this particular risk as negligible at best. Cloudflare did a challenge where a Heartbleed-vulnerable system was exposed to the internet with a challenge to recover the private key. They thought, based on internal testing, it would be quite difficult if not impossible. The key was found within hours: http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge Interestingly, Heartbleed is being used by security researchers to access online forums used by bad guys who, for whatever reason, have not patched their servers: http://www.bbc.com/news/technology-27203766 -- it is not clear if the researchers are getting private keys, but it certainly appears to be possible. In regards to certs, I like the principles behind CAcert, but using their certs on public-facing systems can be problematic due to their root not being included in browsers. For practical reasons, using a CA included in browsers is often a better choice. I use and usually recommend StartSSL but if that's not an option for whatever reason, several CAs offer free-of-charge certs for FOSS projects. Two examples that spring to mind are GoDaddy [1] and GlobalSign [2]. For paid certs, it can often be (considerably) cheaper to buy through a reseller: for example, a PositiveSSL cert from Comodo costs $49/year, but the same cert purchased via NameCheap is only $9/year. Gandi.net, a French registrar, also offers certs chained to Comodo at a reasonable price, though they're slightly more expensive than US-based NameCheap. Cheers! -Pete [1] http://www.godaddy.com/ssl/ssl-open-source.aspx [2] https://www.globalsign.com/ssl/ssl-open-source/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Wed Apr 30 22:32:27 2014 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 30 Apr 2014 13:32:27 -0700 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <617D25BA-3A28-4A0F-AF9B-C864E08849C1@jabberwocky.com> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> <617D25BA-3A28-4A0F-AF9B-C864E08849C1@jabberwocky.com> Message-ID: <53615DDB.4070501@dougbarton.us> On 04/30/2014 01:26 PM, David Shaw wrote: > There were questions early on whether grabbing secret keys was possible via Heartbleed or not. Since then, it's been proven that it is definitely possible. Thanks for that update, I stand corrected. Meanwhile it doesn't change my opinion about StartSSL. If some person or group chooses not to use them I respect their right to make that choice. But personally I still think they are doing a great service for the community and have no problem with them charging a modest fee for revocations. Doug From faramir.cl at gmail.com Wed Apr 30 21:36:43 2014 From: faramir.cl at gmail.com (Faramir) Date: Wed, 30 Apr 2014 15:36:43 -0400 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <87k3a7gt7q.fsf@vigenere.g10code.de> References: <87k3a7gt7q.fsf@vigenere.g10code.de> Message-ID: <536150CB.1050508@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 30-04-2014 3:41, Werner Koch escribi?: ... > Note that https is not enforced for lists.gnupg.org and the other > services because over there we use CAcert certificates which do not > work widely enough. If there is an interest to have lists at https > as well, I consider to purchase a certificate for it. Hello Werner, I'm thinking, now you are using CAcert certificates, would it be possible to get a CAcert signature on the gpg signing key for GnuPG releases? I know the signing key has been said to be "well known", but I don't know any of the signatures on it. However, I know CAcert's key, and an extra signature would not do any harm. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTYVDKAAoJEMV4f6PvczxAEyAH/0G8yeBQRh6yHHsbhwFUg6UI gkCwkJO4W+2xoKJTno4KSxII+IYsKBLanfi5ZIJWzrpO6L9IXWKaLs3fJ66Fq/Gt LT3mjfImcxcYJ4i6fk27cbZfbfgT7BieClGzllnuJYSzA+g6w7yly6yXR8lfO0Bp L+INAA9gRxzSQkU+K3p26JlE/W0uTiSRtDXFQJus1uJf+0bD0pnnmiWhqxgwA+nh nZ1Eo5ibE3z6EKbbCn0tPSjHkiq3XyJe7lWkZk4KbjA2pkf07OXAu21yNwTdP4Ia sNylcIg6HMinjh052L5VJxwB5RUBI34EpU+Gt8pQLS3E89tm1dk7jDVBuPblaoU= =mW1r -----END PGP SIGNATURE----- From faramir.cl at gmail.com Wed Apr 30 21:40:24 2014 From: faramir.cl at gmail.com (Faramir) Date: Wed, 30 Apr 2014 15:40:24 -0400 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <53614D96.9040108@dougbarton.us> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> Message-ID: <536151A8.2000608@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 30-04-2014 15:23, Doug Barton escribi?: > On 04/30/2014 01:25 AM, Martin Gollowitzer wrote: ... > Yeah, I don't quite see your point. They are providing a very > valuable service for free, and charge a nominal fee for revoking a > cert. If you ... > Meanwhile, if your response is going to be in the nature of, > "Everything I want should be given to me free just because I want > it" please don't bother. IMHO, to be able to revoke a compromised certificate should be free, since when you get a certificate, you have time to think about if you really need it, and to consider if you can afford it. But if the certificate is compromised, then you really need it revoked ASAP. It is like providing free airplane tickets, and then charging for the parachute. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTYVGoAAoJEMV4f6PvczxAoXAH/jdFpdKyE6XsJkD2BEKvtePI TxmObltuzPeIhjlC5L/6YnCUWP9/Xv6sBpWnvjGJWAj+wybkuI2AwvtOWW3rFvx3 gEDUX4yLYj8/OVFjMdRu6SZmtRcJR24fOq9RIaj3okPJt3nqUIMvABVjFz09hMTT VUMVYcQm57eGxvYOwOFJiqzV7R0nk1QM0Jzuab/zsE6F2E8nYKwfg666TqF6t7nA B5G+V+Jh2EWFlxi9yMxjk8+AWKE68mIjYSxKBOeGqPxI2waOzjYVUV9wtQBzgTQt nv7H/nBUElt4ZYN+f+ZTmt2C3balBa9L05+OIgkYFpXwdet7FNKu8E3gIEep7nI= =7TeX -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Wed Apr 30 23:48:30 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 30 Apr 2014 17:48:30 -0400 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <536151A8.2000608@gmail.com> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> <536151A8.2000608@gmail.com> Message-ID: <53616FAE.1020702@fifthhorseman.net> On 04/30/2014 03:40 PM, Faramir wrote: > It is like providing free airplane tickets, and then charging for the > parachute. I like this analogy, but it only covers one part of the CA's relationships -- the relationship with the subscriber. But the CA also has other relationships, including its relationship with the so-called relying parties. Another way to put it is: the CA's job, in the bigger picture of the X.509 ecosystem, is to say *only true things*. Anywhere that a CA says untrue things, it is failing its job, and relying parties cannot rely on it. A CA isn't obliged to say *all* true things, but it is obliged to say *only* true things. So a CA who learns that a statement that it has made is untrue *should* revoke that statement as soon as it finds out (oh, i wish our revocation infrastructure actually worked properly too, but that's a different rant). The fact that a CA knows that one of its outstanding statements is untrue, but it will not revoke it until someone else has paid it to do so should be deeply disturbing for anyone who is a relying party on that CA. (and since Startcom is pre-loaded in almost every major trust store, that means that everyone is a relying party on Startcom by default) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From arne at secuso.org Sun Apr 27 15:14:16 2014 From: arne at secuso.org (arne renkema-padmos) Date: Sun, 27 Apr 2014 09:14:16 -0400 Subject: UI terminology for calculated validities In-Reply-To: <53578675.80903@digitalbrains.com> References: <53564380.10000@josuttis.de> <12403760.hMomyj5PjS@inno> <53565437.1070403@josuttis.de> <2013842.cKsNLi2euY@inno> <5356E1D8.9000106@digitalbrains.com> <5356F3BA.9060507@sixdemonbag.org> <53578675.80903@digitalbrains.com> Message-ID: <798EC125-4B1D-4871-B898-2C5495DD0E19@secuso.org> > On 23 apr. 2014, at 05:23, Peter Lebbing wrote: > > But I don't see why we need to drop the term ownertrust for that. Sometimes you > need to pick a descriptive identifier for something and then define what it > exactly means; it happens all the time in science. Let's take an example from statistics: take the term "significance". It has a well defined meaning for statisticians. When they talk about higher and lower significance they are not talking about increases in effect size. However, in common English the two are often confused. Defining a term precisely in science can help a community of peers communicate more succinctly and clearly, if a sufficient proportion subscribes to the same notions of what the words mean. Of course you can start defining new terms, and they might be helpful when discussing things with more expert users. However, for novice users it might cause more confusion than clarification. To find out you'll need to go and test this with novices. Either way, as already mentioned in previous messages in the thread, often there is a trade-off between security and usability. If the goal is attracting more users, then a focus on an insecure but still more secure alternative than plaintext email may be the way to go, e.g. Opportunistic encryption. As users grow more expert they might want to transition to more secure alternatives. It might very well be that GPG is not the place to do these things, and that they could happen at the higher-level tools that rely on GPG. However, standardisation will be problematic in that case. Instead of trying to find terminology to magically clarify a very complex model to end-users (that are concerned mostly with just wanting to send an email) what about defining GPG-lite that provides good-enough-privacy. This could be tested for "intuitiveness" (familiarity) through user studies. Cheers, arne -- Arne Renkema-Padmos PhD student, TU Darmstadt arne at secuso.org, @hcisec From renkema.padmos at gmail.com Sun Apr 27 19:43:01 2014 From: renkema.padmos at gmail.com (Arne Renkema-Padmos) Date: Sun, 27 Apr 2014 13:43:01 -0400 Subject: UI terminology for calculated validities In-Reply-To: <535A9ED9.4010101@ei8fdb.org> References: <53564380.10000@josuttis.de> <535829F9.1010503@gmail.com> <5358D5B2.60705@digitalbrains.com> <1691426.OzBBnA61Yg@inno> <535A28C8.8050104@digitalbrains.com> <20140425132354.GB22122@IUPUI.Edu> <535A950D.3060604@fifthhorseman.net> <535A9ED9.4010101@ei8fdb.org> Message-ID: <041CC21C-9C1E-4F7B-8B16-21A8748F3EE3@gmail.com> I'd also like to thank Nicolai for spawning the interesting thread. > On 25 apr. 2014, at 13:43, Bernard Tyers wrote: > > At the risk of being flamed, can I suggest asking the users what they > think? A very good suggestion. > I have read some HCI research into non-expert user understanding of PGP. A nice listing of relevant literature here: http://lists.gnupg.org/pipermail/gnupg-users/2012-August/045271.html Additionally, here is a preprint version of a paper that I coauthored that will be presented at PETS2014: https://www.dropbox.com/s/ziej0q4q4r29xnj/pets-preprint.pdf It turns out that many people don't even understand the infrastructure behind email transmission, let alone end-to-end encryption. Additionally, as also noted in some of the literature above it's not just a usability issue, but also a socio-technical problem (issues around availability, network effects, unconcerned users, "nothing to hide", unclear consequences of plaintext transmission, etc). However, that isn't an excuse not to have technology available that is usable to end-users in case people do flock to E2E encryption technologies. > With the utmost respect to the list members, you (we) are not > non-expert users, and so our opinions really don't matter. Indeed. There are other concerns besides usability though, one being backward compatibility with documentation / expert understanding. I don't see why we cannot stick with the existing, ingrained terminology for experts, and standardise a set of term, metaphors, and even icons for the user-interface, which are built on experimentally verified findings (i.e. user studies). Having one list of terms/icons isn't the whole equation though: - How do you get all GPG UI projects to agree to using them? (And what about knowledge transfer to and from other crypto products?) - How do you keep the terms/icons updated? - How do you deal with different languages and cultures? Is a global standard possible? (See the failure of Isotype and Esperanto, but the success of icons on music players, i.e. start/stop/rewind, and the widespread use of the padlock.) An interesting project that may serve as inspiration, but which doesn't seem to have had lasting impact (especially not in the hodge pot of mobile browser security indicators), is the W3C's finished Web Security Context Working Group: http://www.w3.org/2006/WSC/ and especially the user interface guidelines at http://www.w3.org/TR/wsc-ui/ Some initial actions/ideas from my side: I've asked Tankred Hase (whiteout.io) about standardisation, and he mentioned that he didn't think it was very likely that email clients would standardise on terminology and icons. The reasoning behind this was that products want to have their own design/brand. This was argued to not be a problem as long as products are internally consistent and understandable. An idea I presented at 30C3: Maybe we can use an approach similar to what OSI is doing with their OSI trademark. There are many encryption tools being built in people's garages, but how does the end user know they can trust/use these? We could come up with "trusted icons", i.e. trademarked logos that can serve as an icon / icons in an email interface. Only the software that meets a certain quality standard would be able to use the logo icons (similar to the OSI requirements). Slides: https://www.dropbox.com/s/urf3flbhswrxipi/slides-v2.pdf Recording: https://www.dropbox.com/s/r6qux6ql8idu55k/30c3-arne.mp4 > The focus of Nicolai's question is *non-expert*, so we need to get > their opinions. > > Suggestions? Arguments? I think we shouldn't just get their opinions (self-report can be pretty unreliable), but instead actively try out different approaches. I.E. A user study, but maybe first an ideation session with users to tease out mental models, metaphors, (mis)conceptions, etc. Finally, and probably most importantly, if we want to start a project to deal with any of the above problems then we should have a very clear scope if we want to get anything done. (Interesting read: Simple Sabotage Field Manual of the CIA, page 28. To derail a project/meeting, one very effective way is continually expanding scope / bringing up irrelevant issues.) Cheers, arne -- Arne Renkema-Padmos PhD student, TU Darmstadt arne at secuso.org, @hcisec -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwipin.c at tcs.com Tue Apr 29 10:47:51 2014 From: dwipin.c at tcs.com (Dwipin C) Date: Tue, 29 Apr 2014 16:47:51 +0800 Subject: Error in encryption Message-ID: Hi Wanted some pointers on an error that we see once in a while. We use GnuPG version 1.4.7. Once in a while when we get concurrent encryption requests for the same public key, it fails. The we see is - "gpg: error in creating temporary file $GNUPGHOME\.#lkf14e8.unknown.29519" : File Exist Is there some sort of locking that happens during the encryption process? If yes is there a way to overcome this, other than to retry after a while ? Thanks and Regards, Dwipin Chandran Tata Consultancy Services Mailto: dwipin.c at tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: