From vmaatta at gmail.com Thu May 1 00:47:40 2014 From: vmaatta at gmail.com (=?windows-1252?Q?Ville_M=E4=E4tt=E4?=) Date: Thu, 1 May 2014 01:47:40 +0300 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: So, when was the last time you were offered a parachute on flight? :), sorry I just had to. I have to say I agree with Doug on StartSSL, I think they?re doing a more of a service to the community by offering affordable certs and the revocation fee is understandable. And reasonable. And sometimes wavered. They did for us the first time when we were adding domains to a wildcard cert, but a bit later this mess of a bug hit and we revoked again, this time they charged the fee. Shit happens. I do also understand the point why revocation shouldn?t cost money. Why it would lead to certs not being revoked and instead new ones being created [1]. It?s a valid point and something StartSSL should, maybe do, think about. Like so often, there is no one easy solution, it?s a matter of compromising and weighing different needs. On the whole I like what StartSSL are doing and I?m not quite ready to stop using their certs based on this affair. [1] http://blogs.fsfe.org/gollo/2014/04/13/what-the-heartbleed-bug-revealed-to-me/ On 30 Apr 2014, at 22:40, Faramir wrote: > Signed PGP part > 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 > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Ville From gnupg at lists.grepular.com Thu May 1 10:30:09 2014 From: gnupg at lists.grepular.com (Mike Cardwell) Date: Thu, 1 May 2014 09:30:09 +0100 Subject: Access to www.gnupg.org only via TLS In-Reply-To: References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> Message-ID: <20140501083009.GA25969@glue.grepular.com> * on the Wed, Apr 30, 2014 at 10:28:15PM +0200, Pete Stephenson wrote: > 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 write a tech blog about Internet/security related stuff. I used to have a CAcert cert on it, but every time I posted something, I'd get a raft of people contacting me to tell me my cert was invalid, and people leaving comments to the effect that I shouldn't be writing about security stuff if I can't even configure my SSL correctly. And this from people who are actually supposed to be a least moderately knowledgeable about the way the web works. Needless to say, I got bored of this fairly quickly and shifted over to StartSSL. For the average person, SSL warnings are a nuisance that needs to be ignored and clicked so they can continue doing what they were doing. For the average geek, an SSL warning seems to be a declaration of War. -- 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 peter at digitalbrains.com Thu May 1 11:57:42 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 01 May 2014 11:57:42 +0200 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <53616FAE.1020702@fifthhorseman.net> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> <536151A8.2000608@gmail.com> <53616FAE.1020702@fifthhorseman.net> Message-ID: <53621A96.10100@digitalbrains.com> On 30/04/14 23:48, Daniel Kahn Gillmor wrote: > So a CA who learns that a statement that it has made is untrue *should* > revoke that statement as soon as it finds out However, how many of the free StartSSL certs that the owners now wish to revoke have actually been compromised by Heartbleed? Peter Eckersley of the EFF raised this aspect in [1]. That the owner revokes the cert because it ran on a vulnerable OpenSSL installation does not mean the key has been compromised; it's a precaution because it was a possibility. I'm torn on this issue. I feel StartSSL should do free revocations in such cases, but I don't think it's fair they have to burn a lot of money because another party, the OpenSSL dev team, made a mistake. I have no idea what it costs in man hours to revoke all those certificates, and I have no idea about the financial situation of StartSSL. Peter. [1] https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/ItSu2bebBKk/7QBGYz5W0DQJ -- 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 2014-667rhzu3dc-lists-groups at riseup.net Thu May 1 14:15:23 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 1 May 2014 13:15:23 +0100 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: <868503700.20140501131523@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 30 April 2014 at 8:23:02 PM, in , Doug Barton 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. 24.9 USD can hardly be considered a nominal fee when applied against something that was supplied free of charge. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Teamwork is essential - it allows you to blame someone else -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNiOuFXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pc2oD/jzmwV5+yusy6kG48xif3WWbk8X328hqpxMz WbuGXlw/O3phA08vonPtll8xAEMaspRJ78tufrb5Y+aeUxzL8mrMDxkzlJg+Tkzk I6qguDVAYbqYk+K1OZgpEcPoRGA8buZugA4ZLAWpbyfL538snExsgOCKg7eR69Tt mQKuu+FO =HsdL -----END PGP SIGNATURE----- From mwood at IUPUI.Edu Thu May 1 14:57:55 2014 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Thu, 1 May 2014 08:57:55 -0400 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <53621A96.10100@digitalbrains.com> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> <536151A8.2000608@gmail.com> <53616FAE.1020702@fifthhorseman.net> <53621A96.10100@digitalbrains.com> Message-ID: <20140501125755.GA22912@IUPUI.Edu> So perhaps the problem is that the gratis certificate provision business model only works when life is good; when bad things happen, this imposes costs which require choosing between customer dissatisfaction and stockholder dissatisfaction. I think I would rather pay a reasonable amount up front for a certificate *and the services necessary to maintain it*. As someone pointed out, this is a predictable and avoidable cost. I do think that a CA should not charge for revocation, but that implies that I should have already paid for possible needs to which I'm committing myself. -- 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 wk at gnupg.org Thu May 1 14:55:51 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 May 2014 14:55:51 +0200 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <536150CB.1050508@gmail.com> (Faramir's message of "Wed, 30 Apr 2014 15:36:43 -0400") References: <87k3a7gt7q.fsf@vigenere.g10code.de> <536150CB.1050508@gmail.com> Message-ID: <8738gtfyjs.fsf@vigenere.g10code.de> On Wed, 30 Apr 2014 21:36, faramir.cl at gmail.com said: > 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 If they wish to do that they can certainly do so. I have been an an CAcert assurer for many years. Regarding the release signing key: pub rsa2048/4F25E3B6 2011-01-12 [expires: 2019-12-31] uid Werner Koch (dist sig) sig!3 4F25E3B6 2011-01-12 Werner Koch (dist sig) sig! 1CE0C630 2011-01-12 Werner Koch (dist sig) sig! 1E42B367 2011-01-12 Werner Koch ^^^^^^^^^ sig! 1CE0C630 2011-01-12 Werner Koch (dist sig) Now check my primary key: $ gpg2 --check-sigs --with-colons 1E42B367 \ | awk -F: '$1=="sig" && $2=="!" {print $5}' | sort | uniq | wc -l 75 (plus 28 signatures not checked due to missing keys. Which probably means that I didn't signed their key) I see more than 70 unique signers since 2008. Of course it is also signed by my old key which has 308 still valid signers. That key used to be on rank 2 of that key signing fun list - up until the KDE and Debian guys entered the game ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Thu May 1 15:09:04 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 01 May 2014 23:09:04 +1000 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <868503700.20140501131523@my_localhost> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> <868503700.20140501131523@my_localhost> Message-ID: <53624770.6050503@sixdemonbag.org> >> 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. > > 24.9 USD can hardly be considered a nominal fee when applied against > something that was supplied free of charge. Sure it can. It's pretty foolish to expense something only by its opening cost. Instead, good practice is to amortize the expenses of opening, closing and maintenance over the expected life of the resource. Free to open, *possibly* free to close (if the cert expires) and $24.99 otherwise, and no maintenance costs, is pretty easy to expense. What's the probability you'll need to revoke a cert? Call it one in five each year and you'll be probably overshooting. Opening costs: $0.00 Maintenance costs: $0.00 Probabilistic closing costs: $5.00 ================================================= Total operating costs: $5.00 per year $5 per year for an SSL cert is pretty hard to beat. Yes, *this* year it'll cost you $25, but that's because of an event already baked into your risk model. From hans at guardianproject.info Thu May 1 15:39:29 2014 From: hans at guardianproject.info (Hans of Guardian) Date: Thu, 1 May 2014 09:39:29 -0400 Subject: hkps ssl problem In-Reply-To: <09484176-1F67-4B33-A756-C56F2C9AE686@gmail.com> References: <09484176-1F67-4B33-A756-C56F2C9AE686@gmail.com> Message-ID: <67AAE8A8-9FE6-4B93-A906-4D37195DD423@guardianproject.info> Looks like you need to get this file and point the config to the real path: keyserver-options ca-cert-file=/pathto/.gnupg/sks-keyservers.netCA.pem .hc On Apr 29, 2014, at 4:41 AM, labrani wrote: > 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 > > _______________________________________________ > 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 labrani at gmail.com Thu May 1 17:24:52 2014 From: labrani at gmail.com (Fl) Date: Thu, 1 May 2014 17:24:52 +0200 Subject: hkps ssl problem In-Reply-To: <67AAE8A8-9FE6-4B93-A906-4D37195DD423@guardianproject.info> References: <09484176-1F67-4B33-A756-C56F2C9AE686@gmail.com> <67AAE8A8-9FE6-4B93-A906-4D37195DD423@guardianproject.info> Message-ID: <8AE26940-F9DD-423E-8C9F-2B0D587CDC42@gmail.com> I already have this line in my config file. Finaly i found the solution : since im running macgogtools its seems that the gpg bin which is coming within is not working fine. I install the gnupg binaries and then use its gpg bin and all work fine. Fl > On May 1, 2014, at 3:39 PM, Hans of Guardian wrote: > > > Looks like you need to get this file and point the config to the real path: > > keyserver-options ca-cert-file=/pathto/.gnupg/sks-keyservers.netCA.pem > > > .hc > >> On Apr 29, 2014, at 4:41 AM, labrani wrote: >> >> 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 >> >> _______________________________________________ >> 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 vmaatta at gmail.com Thu May 1 21:48:00 2014 From: vmaatta at gmail.com (=?iso-8859-1?Q?Ville_M=E4=E4tt=E4?=) Date: Thu, 1 May 2014 22:48:00 +0300 Subject: hkps ssl problem In-Reply-To: <8AE26940-F9DD-423E-8C9F-2B0D587CDC42@gmail.com> References: <09484176-1F67-4B33-A756-C56F2C9AE686@gmail.com> <67AAE8A8-9FE6-4B93-A906-4D37195DD423@guardianproject.info> <8AE26940-F9DD-423E-8C9F-2B0D587CDC42@gmail.com> Message-ID: Hi? any other problems with GPG Tools version? I was using the brew -installed gpg first, had some issues with getting it to recognise OpenPGP card, I switched to GPG Tools version and it?s been ok. Now I?m having trouble getting non-card based keys to work with SSH through gpg-agent. I.e. they don?t, I need to run ssh-agent on any terminal session I want to use local keys. I?m thinking whether it?s worth the effort of trying the brew version again on that? PS. The issue I have with gpg-agent has been on the list some years back in some form, but no real solutions? I?m waiting to debug my setup some more first and I?ll send some more info on the list later. -- Ville On 01 May 2014, at 18:24, Fl wrote: > I already have this line in my config file. > Finaly i found the solution : since im running macgogtools its seems that the gpg bin which is coming within is not working fine. I install the gnupg binaries and then use its gpg bin and all work fine. > > Fl > > On May 1, 2014, at 3:39 PM, Hans of Guardian wrote: > >> >> Looks like you need to get this file and point the config to the real path: >> >> keyserver-options ca-cert-file=/pathto/.gnupg/sks-keyservers.netCA.pem >> >> >> .hc >> >> On Apr 29, 2014, at 4:41 AM, labrani wrote: >> >>> 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 >>> >>> _______________________________________________ >>> 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: From mailinglisten at hauke-laging.de Fri May 2 03:45:30 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 02 May 2014 03:45:30 +0200 Subject: UI terminology for calculated validities In-Reply-To: <535A28C8.8050104@digitalbrains.com> References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <535A28C8.8050104@digitalbrains.com> Message-ID: <3264888.41oIjcsKyr@inno> Am Fr 25.04.2014, 11:20:08 schrieb Peter Lebbing: > 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? Of course, it does: start cmd:> LANG=en gpg --edit-key 0x1a571df5 quit pub 4096R/0x1A571DF5 created: 2012-11-04 usage: SCE trust: ultimate validity: ultimate This is a statement about the key, not about some UID. Or: start cmd:> gpg --with-colons --list-keys 0x1a571df5 pub:u:4096:1:BF4B8EEF1A571DF5:1351995465:1415197758::u:::escESCA: uid:u:::: uid:u:::: uid:u:::: /usr/share/doc/packages/gpg2/DETAILS: 2. Field: A letter describing the calculated validity. The key itself must have such a state for the simple reason that you can select an encryption key via the UID but you (usually) cannot know "which UID" has made a signature. You just know the (sub)key. The WoT is calculated over key validities not over UID validities. 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 May 2 04:02:30 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 02 May 2014 04:02:30 +0200 Subject: UI terminology for calculated validities In-Reply-To: <535A91B2.90602@fifthhorseman.net> References: <53564380.10000@josuttis.de> <1619717.pObFgkP320@inno> <535A91B2.90602@fifthhorseman.net> Message-ID: <4947277.3iX2JyFA0M@inno> Am Fr 25.04.2014, 12:47:46 schrieb Daniel Kahn Gillmor: > > 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, That is not a crypto-related argument. I would never suggest to build key management software in a way that forces people to reveal this information. But I strongly argue against making the decision for the users what information they may offer and which not. I am not a privacy expert but I assume that for most of the Internet users it is not difficult to find out who their family members or their close friends are. If this information is available anyway then it makes little sense to "protect" this information in the OpenPGP area. > and it's not clear how to use the additional > relationship information in an effective way. I am convinced that future crypto software will have to attribute both security and authenticity assessments with keys. Currently most users are just playing crypto (or rather: playing IT security; crypto is not the weak part of it; its organizational handling is). There will be limits similar to --min-cert-level which restrict the accepting of signatures (for certain security levels). > let's keep it simple, and minimize the amount of social graph leakage. Let's not try to protect the users against themselves even in non- technical contexts. Your opinion about leaking social information is not better that that of somebody who likes to leak it. The result should not be you making that impossible for him but quite simple: He leaks, you don't. 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 May 2 04:23:25 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 02 May 2014 04:23:25 +0200 Subject: UI terminology for calculated validities In-Reply-To: <535A941B.60807@fifthhorseman.net> References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <535A941B.60807@fifthhorseman.net> Message-ID: <2200056.Uaq5uCmBkn@inno> Am Fr 25.04.2014, 12:58:03 schrieb Daniel Kahn Gillmor: > yes, users *should* ignore --ask-cert-level: > > https://www.debian-administration.org/users/dkg/weblog/98 I completely disagree with that article. And I consider your statement ?I don't think there is a satisfactory answer to the question "how will specifying the level of identity certification concretely benefit anyone involved?"? REALLY strange. It is hard for me to believe that someone at your level of crypto understanding is serious about that. You claim ?So there is no functional gain in declaring the difference between a "normal" certification and a "positive" one? and ? if I understand you correctly ? the only argument for that is the current behaviour of GnuPG. The correct view is that the current GnuPG behaviour (i.e. not offering the possibility to ignore level-0 sigs) is a serious problem, really limiting the use of WoT calculation. Are you really going to tell me that a generic certification was more valuable than a persona certicifation though the first contains the second? I hope not. 90% of the current WoT is just the illusion of security. I once wrote an email to somebody who had written a terribly wrong article about OpenPGP on his web site. He answered me, thanked me for the hints and wrote: "I have signed your key and attached it. Perhaps you want to sign mine, too." That's what the majority of level-0 signatures means: "I have no idea what I am doing here." > > 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. That is exactly what happens. And thus I like the term. > "Acceptable" might be better, but it still leaves me asking > "acceptable to whom?" and "acceptable for what?" The context is the respective keyring. Who "owns" it and for what purpose? My opinion as a non-native speaker is less relevant in this case but I feel like you seem to indicate: That "acceptable" easily leads to the question "Why? By which standards?". "Accepted" seems to avoid that by "You have (not yet) accepted it. You must know why (not)". To me "accepted" seems more personal, "acceptable" more general. But that may just be a lose language feeling. 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 May 2 04:30:40 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 02 May 2014 04:30:40 +0200 Subject: UI terminology for calculated validities In-Reply-To: <535A9ED9.4010101@ei8fdb.org> References: <53564380.10000@josuttis.de> <535A950D.3060604@fifthhorseman.net> <535A9ED9.4010101@ei8fdb.org> Message-ID: <4746193.H74j8bjs4h@inno> Am Fr 25.04.2014, 18:43:53 schrieb Bernard Tyers: > At the risk of being flamed, can I suggest asking the users what they > think? That doesn't make sense before the users have understood the problem. > The focus of Nicolai's question is *non-expert*, so we need to get > their opinions. > > Suggestions? Arguments? Crypto is becoming a more important subject (OK, that wasn't so difficult) at universities. At least in Germany. Not in the sense that they did what I feel they are ("morally") obliged to ? making sure that most of their (at least math, CS and engineering) students learn it ? but more professors seem to consider that something important now. Thus I guess it should be rather easy to throw some theses (rather not in CS, though) at this question. I know a German professor teaching in Belgium who has already offered a kind of "Why don't the students attend to or organize Cryptoparties?" thesis. 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 May 2 04:38:17 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 02 May 2014 04:38:17 +0200 Subject: UI terminology for calculated validities In-Reply-To: <926791071.20140426134332@my_localhost> References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> Message-ID: <1570455.5MFBMy4FEj@inno> Am Sa 26.04.2014, 13:43:32 schrieb MFPA: > > 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. This may be a language problem (on my side) but in my understanding you do exactly that: You accept a key for usage. Whether you verify it before is your decision. And thus I prefer "accept" over "authenticate" because "authentication" is an opinion (not only in the quality you do that but also in whether you do it at all or not) but "accepting" is a simple fact. Facts are easier to handle than opinions. As more than one year has not been enough for me to write a certification policy for my new key all my certifications are local ones. I hope you don't misunderstand the feature: Local signature is not meant as "rather useless signature" but just as "not for the public". I have local certifications at cerification level 1 (your case) and 3. 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 dkg at fifthhorseman.net Fri May 2 05:34:30 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 01 May 2014 23:34:30 -0400 Subject: UI terminology for calculated validities In-Reply-To: <1143089782.20140426132040@my_localhost> References: <53564380.10000@josuttis.de> <5356EF6C.30201@fifthhorseman.net> <1132800573.20140423203227@my_localhost> <1619717.pObFgkP320@inno> <535A91B2.90602@fifthhorseman.net> <1143089782.20140426132040@my_localhost> Message-ID: <53631246.2090303@fifthhorseman.net> On 04/26/2014 08:20 AM, MFPA wrote: > 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? Because i think that the keyservers are the most useful and predictable and minimally leaky when we keep the data on them as simple as possible. of course, the data is already not simple (OpenPGP is a huge sprawling mess of a format), but that doesn't mean we should add new forms of assertion to the data hosted there, especially if that data could be used to flesh out the social graph in potentially worrisome ways. >> 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). I can see wanting to assert that i personally have control over both keys, and making that assertion publicly (perhaps from both keys). but i don't see the advantage of someone else publishing claims that i am the same person holding two different keys. That looks to me like people using the keyservers to document social relationships that they are not involved in; i don't think that's a good idea. > 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. yes, exactly. > 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. i don't see how including the UserIDs in such a certification makes any sense, let alone adds any extra security. One way that gpg makes certifications directly on the primary key itself is when you revoke a key. I don't know if there are other mechanisms in gpg to expose that sort of thing. >> 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. I tend to see it the other way; i'd want to know specifically how the proposed information is supposed to be useful *first*, and then (if it's a compelling enough case) we can talk about how to specify it. --ask-cert-level fails this test, for example. We don't actually make use of that data in any certificate validation algorithm, so publishing it just produces a richer social graph than we need to publish, and doesn't benefit anyone other than folks who want to data mine the social graph on the keyservers. That's a net loss in my opinion. I make this argument in more detail about --ask-cert-level here: https://www.debian-administration.org/users/dkg/weblog/98 >> 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. ugh, unicode canonicalization :P You're probably right, but: ugh! --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 May 2 05:39:26 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 01 May 2014 23:39:26 -0400 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: <5363136E.2090608@fifthhorseman.net> On 04/26/2014 06:01 PM, Gabriel Niebler wrote: > 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. I don't think this is the case. In the ideal situation, i'd want to say to gpg: "here is some data; please encrypt it to ", and then gpg would figure out what key to use. gpg *does* know the intended recipient, and it *does* know the validity of every key we know that happens to be associated with that user ID. whether the OpenPGP certificate happens to have other user IDs associated with it, and whether those User IDs are valid or not is irrelevant in this case. --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 May 2 05:48:08 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 01 May 2014 23:48:08 -0400 Subject: UI terminology for calculated validities In-Reply-To: <4947277.3iX2JyFA0M@inno> References: <53564380.10000@josuttis.de> <1619717.pObFgkP320@inno> <535A91B2.90602@fifthhorseman.net> <4947277.3iX2JyFA0M@inno> Message-ID: <53631578.8080309@fifthhorseman.net> On 05/01/2014 10:02 PM, Hauke Laging wrote: > Let's not try to protect the users against themselves even in non- > technical contexts. Your opinion about leaking social information is not > better that that of somebody who likes to leak it. The result should not > be you making that impossible for him but quite simple: He leaks, you > don't. We're talking about building infrastructure here. That means that (by definition) we're making choices for some people who will never know the details of the infrastructure. The greater the complexity of the infrastructure, the more fragile it is, and the more corner cases it's likely to have. And infrastructure which supports social graph publication is inherently more leaky than infrastructure which declines to define a way to do so. I know you and i disagree on this Hauke; it's not the first time. But i want to make sure that we build simple authentication infrastructure where possible, and i want to ensure that we don't make it easy for users to do things without thinking that might be harmful in the future. If i was designing a road in a mountainous region, i'd want to build the road with guard rails too, even though some people might prefer to drive off the edge. This discussion has had some interesting highlights for me: including encouraging avoiding the whole delegated certification infrastructure itself (encouraging new users to avoid the WoT calculations entirely at first). this is good, simplifying stuff. I *still* haven't heard an argument that makes sense to me for why the added complexity of certificate signing policies and certification levels are things that will help users use these tools. The added complexity hurts rather than helps adoption and use. --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 Fri May 2 05:49:16 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 02 May 2014 05:49:16 +0200 Subject: UI terminology for calculated validities In-Reply-To: <53631246.2090303@fifthhorseman.net> References: <53564380.10000@josuttis.de> <1143089782.20140426132040@my_localhost> <53631246.2090303@fifthhorseman.net> Message-ID: <2673680.ONURaWY1p5@inno> Am Do 01.05.2014, 23:34:30 schrieb Daniel Kahn Gillmor: > I tend to see it the other way; i'd want to know specifically how the > proposed information is supposed to be useful *first*, and then (if > it's a compelling enough case) we can talk about how to specify it. > > --ask-cert-level fails this test, for example. We don't actually make > use of that data in any certificate validation algorithm This is a clear mix up of cause and effect. You don't discuss a new technical solution but you point at the rather trivial (because always given; otherwise no change would be necessary) fact that the *current* technical solution limits the use of this information. From that you conclude that no change is necessary. To me that is quite the opposite of your own demand. 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 faramir.cl at gmail.com Fri May 2 06:14:18 2014 From: faramir.cl at gmail.com (Faramir) Date: Fri, 02 May 2014 00:14:18 -0400 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <53621A96.10100@digitalbrains.com> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> <536151A8.2000608@gmail.com> <53616FAE.1020702@fifthhorseman.net> <53621A96.10100@digitalbrains.com> Message-ID: <53631B9A.9000605@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 01-05-2014 5:57, Peter Lebbing escribi?: > On 30/04/14 23:48, Daniel Kahn Gillmor wrote: >> So a CA who learns that a statement that it has made is untrue >> *should* revoke that statement as soon as it finds out > > However, how many of the free StartSSL certs that the owners now > wish to revoke have actually been compromised by Heartbleed? Peter > Eckersley of the EFF raised ... IMHO, Heartbleed is not the point, any certificate suspected (or even worst, known) to have been compromised should be revoked. I wonder what would happen if a stolen certificate is used to do a fraud, and the affected customers can prove the CA was aware of the compromise and refused to revoke it because they didn't get money. I'm glad StartSSL provide certificates for free, but I'd rather have them asking a nominal fee to issue the certificate rather than asking it to revoke it in case of dissaster. In my case, I don't own a credit card, and I can't send money to paypal, so eventually I might be tempted to get a free certificate, but would be unable to pay a nominal fee to revoke it, not because I don't have money, but because I don't have any way to deliver it to the CA. I also agree that using CAcert certificates may be very uncomfortable, since the root certificate must be manually added to the browser, and we (yes, I'm part of CAcert community, and used to collaborate in policy group) have been unable to produce a license that both covers CAcert (you know, the "as is, we don't claim this is reliable" stuff), and also can be interpreted as compatible with free software philosophy. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTYxuYAAoJEMV4f6PvczxAa3oH/0U7qFBtLqPB+FeMVvNkPCS0 rPt6XkdtrK39UCAgcxJZMcy4RmUcRI6atcjV1DCSP5Rc41aDBE+0uVlHHUTh7Ns2 gXBOA5LJ82WNZqAwNBW12uakdN7iwDnddtMPrUVheoX+is9fqQgLFRKwMnz1ohZf w2GkkWJGai0AZQ8jP6ZYzmR0lHyGOy05ZMAeV/f03WcE2/8ObtSPBmjko4dfe8GT YM7ZRfkHTECQMK1qiCF6DUDfJP0ZdlVvF2cXzz7QM9U7pKWtHrJ3FL7nz1AWnmG0 pJi6ILKS3I3sCllwWlnA5RH5fjjmLgQ3tFnrtjnKyp24KmIa7T+0j4ID6LeYUqA= =Y92P -----END PGP SIGNATURE----- From faramir.cl at gmail.com Fri May 2 07:04:07 2014 From: faramir.cl at gmail.com (Faramir) Date: Fri, 02 May 2014 01:04:07 -0400 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <8738gtfyjs.fsf@vigenere.g10code.de> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <536150CB.1050508@gmail.com> <8738gtfyjs.fsf@vigenere.g10code.de> Message-ID: <53632747.40308@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 01-05-2014 8:55, Werner Koch escribi?: > On Wed, 30 Apr 2014 21:36, faramir.cl at gmail.com said: > >> 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 > > If they wish to do that they can certainly do so. I have been an > an CAcert assurer for many years. Oh, great, I'm an assurer too... a very bored one, since nobody seems to care for assurances in this zone of the globe :P But CAcert won't sign any key unless the key owner request it. It is an automated process, but must be started by the key owner. The key must carry the name you used when you got assured, and the email address must have been verified (but freeform UIDs are accepted, if they have not changed it recently). > Regarding the release signing key: > > pub rsa2048/4F25E3B6 2011-01-12 [expires: 2019-12-31] uid > Werner Koch (dist sig) ... I had to issue a local signature to it ;) > Now check my primary key: > > $ gpg2 --check-sigs --with-colons 1E42B367 \ ... > I see more than 70 unique signers since 2008. Of course it is > also signed by my old key which has 308 still valid signers. That > key used to be on rank 2 of that key signing fun list - up until > the KDE and Debian guys entered the game ;-) Indeed, very impressive, but unfortunately, I still get Marginal calculated trust, not unexpected, since I only have exchanged signatures with the very few chilean assurers available. Of course, I'm not saying you should get a CAcert signature just to please me ;) Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTYydHAAoJEMV4f6PvczxAsdMH/1SlEDac7mVg+Q6I5XUKIPHU ePHMQdqDj3z3nA5DlS12nAtMkfaqKQOGYNG+ccgBC5r7TDPsCP/Y3kOYENZkJK1Q vIIZLPzZf27bssA/uV4sSHLJKR2OI11KN0+Z/16ZxaMXIkqZMEPzXs2AXtZ9s87o i+3ZcECYyj4Tuf2yh+FDsk/MxbloJtznNiUXExcEf92rFHRUT//co9v9wWOPqlWP XeslpRnBySiMkqC0YFVgwMUHK8c9vtLGCd8PO0fKJjtg4l7wF/jpkxj0BHM76FGP qUdCPcal5xtc001r6gosAP2i5uJXpnJzAZI2ypvmHd5y6haHkxGS+RejJaX2NSk= =PTfg -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Fri May 2 07:35:10 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 02 May 2014 07:35:10 +0200 Subject: UI terminology for calculated validities In-Reply-To: <53631578.8080309@fifthhorseman.net> References: <53564380.10000@josuttis.de> <4947277.3iX2JyFA0M@inno> <53631578.8080309@fifthhorseman.net> Message-ID: <3656592.yhfgetdfPp@inno> Am Do 01.05.2014, 23:48:08 schrieb Daniel Kahn Gillmor: > We're talking about building infrastructure here. That means that (by > definition) we're making choices for some people who will never know > the details of the infrastructure. That is correct. But there are two groups of decisions: a) how to do it b) whether it can be done at all or not > The greater the complexity of the infrastructure, the more fragile it > is, That may be true but there is a level of complexity below which the infrastructure (of a complex problem) becomes useless. That is about the current state of the WoT. Crypto is about protecting information. The level of required protection depends on the (kind of) information. In order to decide whether a key is suitable to protect a certain data you mandatorily need certain information about the key. Most of which cannot be taken from the certificate. That is not an opinion but a simple but broadly ignored fact. Ignored in order to protect the users from too much complexity... > And infrastructure which supports social graph publication is > inherently more leaky than infrastructure which declines to define a > way to do so. That is correct. But there is a difference between "supports" and "enforces". > I know you and i disagree on this Hauke; it's not the first time. Disagreements are not a problem per se. It's perfectly OK to disagree on the recommendation whether to publish such information or not. And it is OK to debate how to present (or hide) this information to the user (e.g. via ??expert in gpg or "expert settings" in some GUIs). > i want to ensure that we don't > make it easy for users to do things without thinking that might be > harmful in the future. That is a noble intention and I don't doubt it. But if ensuring turns into disabling then a line is crossed. In my courses I tell the crypto newbies to forget the WoT. Not forever but until they have a firm understanding of the technology. That is a useful way. Crippling the technology isn't. > If i was designing a road in a mountainous region, i'd want to build > the road with guard rails too, even though some people might prefer > to drive off the edge. That would probably be a good idea if there is only one road. In contrast to rather expensive mountain roads we can build a second road more or less for free. I guess there wouldn't be a concensus that the better road should not be built just because some unqualified driver might use it though he has been told not to do so. If somebody deliberately endangers himself ? so be it. That possibility is no reason to prevent those users with a brain from improving their situation. > I *still* haven't heard > an argument that makes sense to me for why the added complexity of > certificate signing policies and certification levels are things that > will help users use these tools. I repeat myself: Crypto is about protecting information. The level of required protection depends on the (kind of) information. In order to decide whether a key is suitable to protect a certain data you mandatorily need certain information about the key. Most of which cannot be taken from the certificate. That is not an opinion but a simple but broadly ignored fact. Ignored in order to protect the users from too much complexity... "help users use these tools" not in the sense of "making the current use easier" but in the sense of "using the tools for applications which are today not (or hardly) possible". > The added complexity hurts rather than helps adoption and use. Added complexity would not even affect unqualified users (if well implemented). 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 labrani at gmail.com Fri May 2 10:40:07 2014 From: labrani at gmail.com (labrani) Date: Fri, 2 May 2014 10:40:07 +0200 Subject: hkps ssl problem In-Reply-To: References: <09484176-1F67-4B33-A756-C56F2C9AE686@gmail.com> <67AAE8A8-9FE6-4B93-A906-4D37195DD423@guardianproject.info> <8AE26940-F9DD-423E-8C9F-2B0D587CDC42@gmail.com> Message-ID: <4CAA5742-A008-4127-8008-33FA5FDC1084@gmail.com> Hi Personnaly i've installed gpgtools in order to use it with mail mac os application. and it is working fine unless i try to use an hkps server. with http there is no problem. i dont know the real reason why the gpgtools version is not working since on their site they said all is ok : i think that there is a bug while trying to use the ca-cert options. FL On May 1, 2014, at 21:48, Ville M??tt? wrote: > Hi? any other problems with GPG Tools version? > > I was using the brew -installed gpg first, had some issues with getting it to recognise OpenPGP card, I switched to GPG Tools version and it?s been ok. Now I?m having trouble getting non-card based keys to work with SSH through gpg-agent. I.e. they don?t, I need to run ssh-agent on any terminal session I want to use local keys. I?m thinking whether it?s worth the effort of trying the brew version again on that? > > PS. The issue I have with gpg-agent has been on the list some years back in some form, but no real solutions? I?m waiting to debug my setup some more first and I?ll send some more info on the list later. > > -- > Ville > > On 01 May 2014, at 18:24, Fl wrote: > >> I already have this line in my config file. >> Finaly i found the solution : since im running macgogtools its seems that the gpg bin which is coming within is not working fine. I install the gnupg binaries and then use its gpg bin and all work fine. >> >> Fl >> >> On May 1, 2014, at 3:39 PM, Hans of Guardian wrote: >> >>> >>> Looks like you need to get this file and point the config to the real path: >>> >>> keyserver-options ca-cert-file=/pathto/.gnupg/sks-keyservers.netCA.pem >>> >>> >>> .hc >>> >>> On Apr 29, 2014, at 4:41 AM, labrani wrote: >>> >>>> 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 >>>> >>>> _______________________________________________ >>>> 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: From peter at digitalbrains.com Fri May 2 11:36:41 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 02 May 2014 11:36:41 +0200 Subject: UI terminology for calculated validities In-Reply-To: <3264888.41oIjcsKyr@inno> References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <535A28C8.8050104@digitalbrains.com> <3264888.41oIjcsKyr@inno> Message-ID: <53636729.8070309@digitalbrains.com> On 02/05/14 03:45, Hauke Laging wrote: > start cmd:> gpg --with-colons --list-keys 0x1a571df5 > pub:u:4096:1:BF4B8EEF1A571DF5:1351995465:1415197758::u:::escESCA: uid:u:::: > uid:u:::: uid:u:::: > > /usr/share/doc/packages/gpg2/DETAILS: > > 2. Field: A letter describing the calculated validity. So did you read the description? Let me quote from that very section: >> If the validity information is given for a UID or UAT record, it describes >> the validity calculated based on this user ID. If given for a key record it >> describes the best validity taken from the best rated user ID. /It describes the best validity taken from the best rated user ID/. It is simply a wrapup of the information that follows on the validity of the UID's on the key. And this is also what that "validity" is in: > pub 4096R/0x1A571DF5 created: 2012-11-04 usage: SCE > trust: ultimate validity: ultimate Although that is a rather poor example because it has ultimate ownertrust, so it's always ultimately valid. But the entry refers to field 2 of a pub record in the --with-colons output, AFAICT. > The key itself must have such a state for the simple reason that you can > select an encryption key via the UID but you (usually) cannot know "which > UID" has made a signature. You just know the (sub)key. So when verifying a signature, the UI should simply display all UID's, or possibly all valid UID's. Guess what? At least the command line does: --------------------------8<------------>8-------------------------- $ gpg2 -d test.gpg Hello world gpg: Signature made Fri 02 May 2014 11:07:53 CEST using RSA key ID 3E7F0306 gpg: Good signature from "Test more extra UID" gpg: aka "Test extra UID" gpg: aka "Testkey" --------------------------8<------------>8-------------------------- It gets even more interesting with "verify-options show-uid-validity", which I have turned on: --------------------------8<------------>8-------------------------- $ gpg2 -d test.gpg Hello world gpg: Signature made Fri 02 May 2014 11:07:53 CEST using RSA key ID 3E7F0306 gpg: Good signature from "Test more extra UID" [unknown] gpg: aka "Test extra UID" [full] gpg: aka "Testkey" [unknown] --------------------------8<------------>8-------------------------- I have only signed that one fully valid key. All this stuff is simply related to how things are presented to users, they are not an essential part of how it actually works. I'd say a feature request to only display valid UID's on signatures might have merit, but I still don't see a technical reason to equate validity with just a key. In the case of signatures, you definitely need to know who signed it, not just that it is a valid signature. And I can't tell that from just the key ID[1], I need UID's. If some hacker I validated sends me a signed message "Here, copy paste this to your command line", I might not listen even though it's a valid signature. If the signature was from the trustworthy IT guy who is helping me solve some issue with my PC, I'd just do it. That's why you need more information than "this is a valid signature". > The WoT is calculated over key validities not over UID validities. This is just wrong. Validity is always calculated for couplings of keys and UID's. However, when you certify a UID, that certification indeed comes from your key, not your UID, so /ownertrust/ is assigned to a whole key rather than a UID. This means that deeper in the certification chain, validity of a UID is calculated based on the trust assigned to a key, not trust assigned to a UID. So yes, ownertrust is indeed associated just with a key, not the UID's. This is not the same as "validity is calculated over keys", which is much too broad. HTH, Peter. [1] Which might not even be unique; and fingerprints are long! -- 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 rejo at zenger.nl Fri May 2 10:53:02 2014 From: rejo at zenger.nl (Rejo Zenger) Date: Fri, 2 May 2014 10:53:02 +0200 Subject: hkps ssl problem In-Reply-To: <4CAA5742-A008-4127-8008-33FA5FDC1084@gmail.com> References: <09484176-1F67-4B33-A756-C56F2C9AE686@gmail.com> <67AAE8A8-9FE6-4B93-A906-4D37195DD423@guardianproject.info> <8AE26940-F9DD-423E-8C9F-2B0D587CDC42@gmail.com> <4CAA5742-A008-4127-8008-33FA5FDC1084@gmail.com> Message-ID: <20140502085302.GG1194@broop-kidron.bof.nl> ++ 02/05/14 10:40 +0200 - labrani: >Personnaly i've installed gpgtools in order to use it with mail mac os application. >and it is working fine unless i try to use an hkps server. with http there is no problem. >i dont know the real reason why the gpgtools version is not working since on their site they said all is ok : i think that there is a bug while trying to use the ca-cert options. Works for me. What error message do you see? -- Rejo Zenger E rejo at zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J rejo at zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 931 bytes Desc: not available URL: From labrani at gmail.com Fri May 2 11:53:53 2014 From: labrani at gmail.com (labrani) Date: Fri, 2 May 2014 11:53:53 +0200 Subject: hkps ssl problem In-Reply-To: <20140502085302.GG1194@broop-kidron.bof.nl> References: <09484176-1F67-4B33-A756-C56F2C9AE686@gmail.com> <67AAE8A8-9FE6-4B93-A906-4D37195DD423@guardianproject.info> <8AE26940-F9DD-423E-8C9F-2B0D587CDC42@gmail.com> <4CAA5742-A008-4127-8008-33FA5FDC1084@gmail.com> <20140502085302.GG1194@broop-kidron.bof.nl> Message-ID: <8EF114A3-6963-4EBD-8834-4116D9011411@gmail.com> i already give the message error in my first mail but here it is again from the gui application : gpg-key-chain Receive keys failed! Code = 0 Error text: gpg: requesting key 0xB6633197 from hkps server hkps.pool.sks-keyservers.net gpg: no valid OpenPGP data found. gpg: Total number processed: 0 FL On May 2, 2014, at 10:53, Rejo Zenger wrote: > ++ 02/05/14 10:40 +0200 - labrani: >> Personnaly i've installed gpgtools in order to use it with mail mac os application. >> and it is working fine unless i try to use an hkps server. with http there is no problem. >> i dont know the real reason why the gpgtools version is not working since on their site they said all is ok : i think that there is a bug while trying to use the ca-cert options. > > Works for me. What error message do you see? > > > -- > Rejo Zenger > E rejo at zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl > T @rejozenger | J rejo at zenger.nl > OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 > XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From 2014-667rhzu3dc-lists-groups at riseup.net Fri May 2 15:01:24 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 2 May 2014 14:01:24 +0100 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <53624770.6050503@sixdemonbag.org> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> <868503700.20140501131523@my_localhost> <53624770.6050503@sixdemonbag.org> Message-ID: <1876570627.20140502140124@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 1 May 2014 at 2:09:04 PM, in , Robert J. Hansen wrote: > Sure it can. Somebody who applies a rigorous approach, such as you went on to outline, may consider it a "nominal" fee. To somebody who simply contacted the supplier of a "free" service to instruct them to cancel the free service, it is quite a substantial unexpected bill: to many people, choosing to pay it may equate to choosing not to eat for two or three days. > It's pretty foolish to expense something only by its > opening cost. Instead, good practice is [...] Fair enough. Most people are foolish, at least sometimes. And it is up to them to face the consequences. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Look, it's a hat! It's not going to hurt you. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNjlzJXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p6L0EAL4/R9EfhJSoloHwFXed5j6BCwSBNnkhhyao GVIHayQXEZThIFR8Xjn234wwHxDuir7QJ20gxc6QOZkyDC9QBtgUcQT73QnOoQtq LQWJgXojR8Y8cslpGZbu4jceaXfySiOaEI0bci/5RKjVl7H1IbaLyZk089VS2UJX OHPDTOjo =cNGK -----END PGP SIGNATURE----- From peter at digitalbrains.com Fri May 2 15:38:55 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 02 May 2014 15:38:55 +0200 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <1876570627.20140502140124@my_localhost> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> <868503700.20140501131523@my_localhost> <53624770.6050503@sixdemonbag.org> <1876570627.20140502140124@my_localhost> Message-ID: <53639FEF.2010501@digitalbrains.com> On 02/05/14 15:01, MFPA wrote: > To somebody who simply contacted the supplier of a "free" service to > instruct them to cancel the free service, it is quite a substantial > unexpected bill: to many people, choosing to pay it may equate to > choosing not to eat for two or three days. Well, unexpected to some extent. The policy, which you attest to have read when you get the certificate, clearly mentions this fee. That you need to pay it now, that is unexpected, that the fee is there is properly agreed to. I just think it's important to note this difference, as I get the feeling some people are suggesting that the fee itself was unexpected, which I find dishonest. 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 2014-667rhzu3dc-lists-groups at riseup.net Fri May 2 15:57:46 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 2 May 2014 14:57:46 +0100 Subject: UI terminology for calculated validities In-Reply-To: <1570455.5MFBMy4FEj@inno> References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <1570455.5MFBMy4FEj@inno> Message-ID: <333214734.20140502145746@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 2 May 2014 at 3:38:17 AM, in , Hauke Laging wrote: > in my > understanding you do exactly that: You accept a key for > usage. I see what you mean. I accept a key for usage by applying a non-exportable signature. But I neither accept nor reject any claim made or implied about the identity its controller. There is ambiguity in using the word "accept" and that is why I prefer the word "activate." > Whether you verify it before is your decision. What would you verify? For any encrypted mail I send, all that really matters is the person controlling the email address I am sending to can read emails that I encrypt to that key. A simple exchange of messages verifies this. Other people would have instances where they actually need to be certain who controls that key. In extreme cases, somebody may even need to know the person's legal name as recognised by their government. > As more than one year has not been enough for me to > write a certification policy for my new key all my > certifications are local ones. That is good. There are an awful lot of certifications out there from keys for which there is no published certification policy. All of these are essentially meaningless noise: unless we know what the signer is claiming, how do we know what do do with their claim? > I hope you don't > misunderstand the feature: Local signature is not meant > as "rather useless signature" but just as "not for the > public". Well, until/unless you have decided what you want to say, it is not a good idea to make a public announcement. > I have local certifications at cerification level 1 > (your case) and 3. The majority of mine are level 0, even for people I have conversed with on mailing lists for years. I don't have a single key on my keyring from anybody I know in real life. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net The problem is not that we're paranoid; it's that we're not paranoid enough. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNjpF9XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pdPIEAKv4sTB1JxWVu7+T9eXeyzLz84ENo75bu3Ik 1eIJqOfh7y3SOCRiTL6xCKDMOYFV19ag3l5rFMIJZKap8M7PvUvNiaYQg4NYiGCh gJeb2FJ6X/OKDOyrY6/4a6QnCmPRDYVQtlEMbuJh1cvlR3HVJIMls+OHboKWQbnD 51omqCwZ =2xm6 -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Fri May 2 16:55:33 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 2 May 2014 15:55:33 +0100 Subject: UI terminology for calculated validities In-Reply-To: <53631246.2090303@fifthhorseman.net> References: <53564380.10000@josuttis.de> <5356EF6C.30201@fifthhorseman.net> <1132800573.20140423203227@my_localhost> <1619717.pObFgkP320@inno> <535A91B2.90602@fifthhorseman.net> <1143089782.20140426132040@my_localhost> <53631246.2090303@fifthhorseman.net> Message-ID: <1508536446.20140502155533@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 2 May 2014 at 4:34:30 AM, in , Daniel Kahn Gillmor wrote: > but i don't see the > advantage of someone else publishing claims that i am > the same person holding two different keys. Agreed, that is an awful idea. > people using the keyservers to document > social relationships that they are not involved in; i > don't think that's a good idea. People wishing to do this already use signatures and UIDs to add their message to the background noise on the keyservers. "KeyA and KeyB are controlled by the same person" would be merely inconsequential noise unless it were a claim made by both KeyA and KeyB. > One way that gpg makes certifications > directly on the primary key itself is when you revoke a > key. I don't know if there are other mechanisms in gpg > to expose that sort of thing. This shows the code is already there to make certifications directly on the primary key. > I tend to see it the other way; i'd want to know > specifically how the proposed information is supposed > to be useful *first*, and then (if it's a compelling > enough case) we can talk about how to specify it. I guess there is also the option for somebody who wished to run tests and maybe standardise later if something useful came out of it. > --ask-cert-level fails this test, for example. I always thought that seemed like it ought to be a useful thing to consider when making a certification. > We > don't actually make use of that data in any certificate > validation algorithm, so publishing it just produces a > richer social graph than we need to publish, and > doesn't benefit anyone other than folks who want to > data mine the social graph on the keyservers. That's a > net loss in my opinion. I consider to be a loss, the publication of any un-necessary information that allows a person to be identified or their associations analysed. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Nothing a Pan-Galactic Gargle Blaster won't cure! -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNjsfVXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p6NkD/RalxmeLVx8JSHkuwL/TMee70d1utPH8tmJk AvKBDcXkunFwT8KyoLU/M3uTVp7R2ajPtNc7Qmu2NJn/qV/U/DIGDPOJX6rzujjL vMI6hbvULcoAMAA2ql3MDeTRFQ42FzQYkd7wGIHmBBiwL33lVzAdJW23TkRBL8qL w4Tf0Zsf =0if5 -----END PGP SIGNATURE----- From peter at digitalbrains.com Fri May 2 17:12:46 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 02 May 2014 17:12:46 +0200 Subject: Signature without policy meaningless? (was Re: UI terminology for calculated validities) In-Reply-To: <333214734.20140502145746@my_localhost> References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <1570455.5MFBMy4FEj@inno> <333214734.20140502145746@my_localhost> Message-ID: <5363B5EE.3040201@digitalbrains.com> On 02/05/14 15:57, MFPA wrote: > That is good. There are an awful lot of certifications out there from > keys for which there is no published certification policy. All of > these are essentially meaningless noise: unless we know what the > signer is claiming, how do we know what do do with their claim? I don't quite understand. If I know someone, I can talk with them about how they verify ownership before they sign. Then I can judge whether I agree and assign ownertrust accordingly. If I don't know them, I wouldn't assign ownertrust even if their policy came with sparkles, glitter and a free magazine subscription. 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 2014-667rhzu3dc-lists-groups at riseup.net Fri May 2 17:17:53 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 2 May 2014 16:17:53 +0100 Subject: UI terminology for calculated validities In-Reply-To: <4947277.3iX2JyFA0M@inno> References: <53564380.10000@josuttis.de> <1619717.pObFgkP320@inno> <535A91B2.90602@fifthhorseman.net> <4947277.3iX2JyFA0M@inno> Message-ID: <188230923.20140502161753@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 2 May 2014 at 3:02:30 AM, in , Hauke Laging wrote: > Let's not try to protect the users against themselves > even in non- technical contexts. Why not? If they are determined, they will get around the safeguards anyway. If they were simply unwittingly going to do something potentially harmful, the safeguards were worth it. > Your opinion about > leaking social information is not better that that of > somebody who likes to leak it. But either of those two is better than somebody who leaks it without having considered all angles and formed an opinion, and without considering the interests of others who may be harmed by his leaking. > The result should not be > you making that impossible for him The leaking of personal and/or social information cannot be made impossible but it needs to be a deliberate choice. We should get as close as we can to making _accidental_ leaking impossible. > but quite simple: He leaks, you don't. It is nothing like a simple "He leaks, you don't" when he is leaking information relating to others as well as to himself. (More "He leaks, you don't - so you avoid him like the plague. Oops, he already leaked information about you before you found out he was leaky and started to avoid him.") - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Consistency is the last refuge of the unimaginative -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNjtydXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pilwD/Ar41w1C7TiTI7iA6Sk4H4YCLirnYhNzS9S9 ZHptNWfstBu4mrbVROz7smF9oRzFz6cn610tNskLRPdZmnNoXlyxq340civTF/Rd fbu2yUxlVALmR5wwsBbG/rHVzFJV3WBAYgHBXdLOHgWTXr+Sid44s96Ms+3xIaEy 3UQLZcjT =pMPH -----END PGP SIGNATURE----- From ndk.clanbo at gmail.com Fri May 2 17:21:32 2014 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 02 May 2014 17:21:32 +0200 Subject: Signature without policy meaningless? (was Re: UI terminology for calculated validities) In-Reply-To: <5363B5EE.3040201@digitalbrains.com> References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <1570455.5MFBMy4FEj@inno> <333214734.20140502145746@my_localhost> <5363B5EE.3040201@digitalbrains.com> Message-ID: <5363B7FC.9050006@gmail.com> Il 02/05/2014 17:12, Peter Lebbing ha scritto: > I don't quite understand. If I know someone, I can talk with them about how they > verify ownership before they sign. Then I can judge whether I agree and assign > ownertrust accordingly. Too bad (IIUC) you can't say "I certify that this person is *really* the one given in this UID, but I absolutely don't trust his identity validations"... BYtE, Diego. From peter at digitalbrains.com Fri May 2 19:21:59 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 02 May 2014 19:21:59 +0200 Subject: Signature without policy meaningless? (was Re: UI terminology for calculated validities) In-Reply-To: <5363B7FC.9050006@gmail.com> References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <1570455.5MFBMy4FEj@inno> <333214734.20140502145746@my_localhost> <5363B5EE.3040201@digitalbrains.com> <5363B7FC.9050006@gmail.com> Message-ID: <5363D437.8030307@digitalbrains.com> On 02/05/14 17:21, NdK wrote: > Too bad (IIUC) you can't say "I certify that this person is *really* the > one given in this UID, but I absolutely don't trust his identity > validations"... For yourself or as a public statement? For yourself, it's as easy as signing the key, and then assigning "I do NOT trust" as ownertrust to that person. So you can do what you want, unless I misunderstand you. As a public statement; now we're going into trust signature territory, which is not really a common deployment in the WoT. But I guess you could simply make a normal signature instead of a trust signature. True, you do not make a public statement of distrust, but you don't make a statement of positive trust either. An example would be when the HR department of your employer signs a key of one of the employees who is not supposed to be introducing other people into the Web of Trust, which actually would happen more often than not. The HR department would simply issue a normal signature. Now when there's a new HR person who is supposed to introduce other employees into the Web of Trust, they would issue a trust signature to that new HR person. But without trust signatures, your exportable signatures do not indicate that you trust that person to certify others; they make no statement about that aspect at all. It only potentially influences validity, never ownertrust. 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 robertc at broadcom.com Fri May 2 19:50:14 2014 From: robertc at broadcom.com (Bob (Robert) Cavanaugh) Date: Fri, 2 May 2014 17:50:14 +0000 Subject: UI terminology for calculated validities In-Reply-To: <3656592.yhfgetdfPp@inno> References: <53564380.10000@josuttis.de> <4947277.3iX2JyFA0M@inno> <53631578.8080309@fifthhorseman.net> <3656592.yhfgetdfPp@inno> Message-ID: <8F0B09FC6339FA439524099BFCABC11F2D312F7A@IRVEXCHMB11.corp.ad.broadcom.com> Hi Hauke&Group, I have been following this thread with a lot of interest. I want to jump in here to make sure that something implicit is made explicit: If a unsophisticated user is allowed too much latitude (or provided too much information and the way to dessiminate it), not only can they harm their own security posture, but they can also harm others. To use Daniel's analogy, I would put up the guardrails, because even though I may not care about the driver who intentionally goes off the road, I do care about the busload of children on the curve below him that he could kill due to his ignorance/stupidity. Whatever infrastructure changes are proposed and ultimately adopted, protection of the data must be the primary concern, not ease-of-use. There are a lot of tools available that take some time to learn. Sometimes this is ultimately a good thing. I would rather a child learn how to cut wood with a small hand saw than let them loose with a radial arm saw to start. Overhauling the WoT may (and probably does) make a lot of sense, but when designing a security infrastructure limiting the amount of information to the bare minimum to perform the task (or provide the correct amount of protection) is a cardinal rule. -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Hauke Laging Sent: Thursday, May 01, 2014 10:35 PM To: gnupg-users at gnupg.org Subject: Re: UI terminology for calculated validities Am Do 01.05.2014, 23:48:08 schrieb Daniel Kahn Gillmor: > We're talking about building infrastructure here. That means that (by > definition) we're making choices for some people who will never know > the details of the infrastructure. That is correct. But there are two groups of decisions: a) how to do it b) whether it can be done at all or not > The greater the complexity of the infrastructure, the more fragile it > is, That may be true but there is a level of complexity below which the infrastructure (of a complex problem) becomes useless. That is about the current state of the WoT. Crypto is about protecting information. The level of required protection depends on the (kind of) information. In order to decide whether a key is suitable to protect a certain data you mandatorily need certain information about the key. Most of which cannot be taken from the certificate. That is not an opinion but a simple but broadly ignored fact. Ignored in order to protect the users from too much complexity... > And infrastructure which supports social graph publication is > inherently more leaky than infrastructure which declines to define a > way to do so. That is correct. But there is a difference between "supports" and "enforces". > I know you and i disagree on this Hauke; it's not the first time. Disagreements are not a problem per se. It's perfectly OK to disagree on the recommendation whether to publish such information or not. And it is OK to debate how to present (or hide) this information to the user (e.g. via ??expert in gpg or "expert settings" in some GUIs). > i want to ensure that we don't > make it easy for users to do things without thinking that might be > harmful in the future. That is a noble intention and I don't doubt it. But if ensuring turns into disabling then a line is crossed. In my courses I tell the crypto newbies to forget the WoT. Not forever but until they have a firm understanding of the technology. That is a useful way. Crippling the technology isn't. > If i was designing a road in a mountainous region, i'd want to build > the road with guard rails too, even though some people might prefer > to drive off the edge. That would probably be a good idea if there is only one road. In contrast to rather expensive mountain roads we can build a second road more or less for free. I guess there wouldn't be a concensus that the better road should not be built just because some unqualified driver might use it though he has been told not to do so. If somebody deliberately endangers himself ? so be it. That possibility is no reason to prevent those users with a brain from improving their situation. > I *still* haven't heard > an argument that makes sense to me for why the added complexity of > certificate signing policies and certification levels are things that > will help users use these tools. I repeat myself: Crypto is about protecting information. The level of required protection depends on the (kind of) information. In order to decide whether a key is suitable to protect a certain data you mandatorily need certain information about the key. Most of which cannot be taken from the certificate. That is not an opinion but a simple but broadly ignored fact. Ignored in order to protect the users from too much complexity... "help users use these tools" not in the sense of "making the current use easier" but in the sense of "using the tools for applications which are today not (or hardly) possible". > The added complexity hurts rather than helps adoption and use. Added complexity would not even affect unqualified users (if well implemented). 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 From rejo at zenger.nl Fri May 2 21:57:34 2014 From: rejo at zenger.nl (Rejo Zenger) Date: Fri, 2 May 2014 21:57:34 +0200 Subject: hkps ssl problem In-Reply-To: <8EF114A3-6963-4EBD-8834-4116D9011411@gmail.com> References: <09484176-1F67-4B33-A756-C56F2C9AE686@gmail.com> <67AAE8A8-9FE6-4B93-A906-4D37195DD423@guardianproject.info> <8AE26940-F9DD-423E-8C9F-2B0D587CDC42@gmail.com> <4CAA5742-A008-4127-8008-33FA5FDC1084@gmail.com> <20140502085302.GG1194@broop-kidron.bof.nl> <8EF114A3-6963-4EBD-8834-4116D9011411@gmail.com> Message-ID: <20140502195734.GD3763@broop-kidron.home> ++ 02/05/14 11:53 +0200 - labrani: >i already give the message error in my first mail > >but here it is again from the gui application : gpg-key-chain > >Receive keys failed! >Code = 0 > >Error text: >gpg: requesting key 0xB6633197 from hkps server hkps.pool.sks-keyservers.net >gpg: no valid OpenPGP data found. >gpg: Total number processed: 0 On the command line, I see this: rejo at broop-kidron:~$ gpg --keyserver hkps.pool.sks-keyservers.net --search 0xB6633197 gpg: searching for "0xB6633197" from hkp server hkps.pool.sks-keyservers.net (1) Rejo Zenger [...] In other words, that works. Did you try to the application in debugging mode? See: . And, did you file a (bug) report to them? They are very responsive in the one case I ran into a bug. -- Rejo Zenger E rejo at zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J rejo at zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 931 bytes Desc: not available URL: From faramir.cl at gmail.com Sat May 3 00:03:04 2014 From: faramir.cl at gmail.com (Faramir) Date: Fri, 02 May 2014 18:03:04 -0400 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <535E9F76.8090106@fifthhorseman.net> References: <535E9F76.8090106@fifthhorseman.net> Message-ID: <53641618.8050806@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 28-04-2014 14:35, Daniel Kahn Gillmor escribi?: ... > 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. What about to adding the boss key to the keys the message is encrypted to? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTZBYXAAoJEMV4f6PvczxAQakH/1ogvcGn1Lcdu1UDZ0eZ4a2P nYyRyn1xHZBm/UDMvMfo2+I4rqjMPpUB/gdiosDGXLLG009MiyHl3hd8IdCKCGcp qTIYR7H10ImWFDAi/VmkqPpJi9XSe9AfRO2nqMnMVVTuMGbTp4hCqZqgiAnyH8Pc SSV4iUWj/aykzTuBgfFdS5o6JkANKa9fgXlOI55OtKePTPiKTrALJngXZtJ8OeWT 1fSc8jnKGCYd+mVZFwRJlqHVMhPZigi83BE/HYAde7j8F0Ubnmn6zipTDiiQvy9o ZLs8lmLpHRJO3t+vtP42VFOnY+Qah5z/iJilL1722ODfxwnpyZZHKdSRfGK0Olo= =CTVq -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Sat May 3 00:18:38 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 02 May 2014 18:18:38 -0400 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <53641618.8050806@gmail.com> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> Message-ID: <536419BE.7090403@fifthhorseman.net> On 05/02/2014 06:03 PM, Faramir wrote: > El 28-04-2014 14:35, Daniel Kahn Gillmor escribi?: > ... >> 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. > > What about to adding the boss key to the keys the message is > encrypted to? You're saying instead of doing escrow of encryption keys? The only problem with that approach is that you have no control over the people who are encrypting messages and sending them to you. So you're bound to get some messages that the Boss wouldn't be able to decrypt later. It should be *possible* with OpenPGP to prepend a new PK-ESK packet on any received message, but i know of no tools that do that. also, once you leave the organization, messages could still come in encrypted to your key by people who want to talk to the org, but don't know that you've left. in that case, the organization couldn't get those messages. (in some cases, this may be the Right Thing; in other business relationships, that might be really problematic) I'm not saying that all employers *should* do escrow of all their employees' encrpytion-capable keys. In fact, i think the majority of employer/employee relationships should probably never require any kind of key escrow. But there are some relationships where key escrow makes sense, and i wanted to clarify that it *only* makes sense for encryption-capable keys, not personal signing or authentication keys. --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 faramir.cl at gmail.com Sat May 3 00:20:24 2014 From: faramir.cl at gmail.com (Faramir) Date: Fri, 02 May 2014 18:20:24 -0400 Subject: A few newbie Qs In-Reply-To: <6a65f4ec-9a51-4b14-b077-a98d37b9aa9d@email.android.com> References: <20140426184108.28260@gmx.com> <535C5F1A.20304@sixdemonbag.org> <535CD0C7.7080500@digitalbrains.com> <535CDD1F.6000806@sixdemonbag.org> <6a65f4ec-9a51-4b14-b077-a98d37b9aa9d@email.android.com> Message-ID: <53641A28.20408@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 27-04-2014 9:04, Simon Ward escribi?: ... > 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 also has a setting that somehow splits the password and paste it in 2 parts, I didn't get the mumbojumbo related to it, but supposedly should cause clipboard captures to collect 2 times half the password, not the whole thing. But is also says it is vulnerable to malware aimed specifically to Keepass2. In other words, its goal is to make it harder to malware to capture the password, but not impossible. The problem is, if my password is too strong, I want to autotype it. If it is too short, it is not secure enough, and if I have too many passwords, no matter how simple they are, I tend to forget them, so I either autotype them or re utilize them, another big NO. Reaching some point, passwordcard.org starts looking very good, but I don't know how random are these cards. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTZBooAAoJEMV4f6PvczxAt6QH/jn7d9IIdnL1ni2kBJ1n+rME hNWi2CagpdVSGyWO03dm768ggqygQ/3G7XtkRJT0SbEdga2jGrPOx5OuwJNhnH2/ 33an53ulfBfJ04IizNFp7qDeIhY+8ewyTZdyhK3KcLlaI7I9O3LHvdsBeHSOjVX1 4sDRtmwY4fiWtT7JFpPvlcK0uR7jdVl+BkyBkkQbgNM+eTj+M+zARf1S3lzhNh3N GO/ZWb6eJfieOckD4Ti6s9DKHkS1pBLBk4goL7pHaHcd94fi4v2e1K+4WQtNGhXY Y81tk5lPIWZVog4YguQM1yvEsnX8wH+KVmmUS1HClGg0e3HV1oSL0zAvpbaSAwc= =jesB -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Sat May 3 01:10:42 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 02 May 2014 19:10:42 -0400 Subject: Signature without policy meaningless? (was Re: UI terminology for calculated validities) In-Reply-To: <5363D437.8030307@digitalbrains.com> References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <1570455.5MFBMy4FEj@inno> <333214734.20140502145746@my_localhost> <5363B5EE.3040201@digitalbrains.com> <5363B7FC.9050006@gmail.com> <5363D437.8030307@digitalbrains.com> Message-ID: <536425F2.9090008@fifthhorseman.net> On 05/02/2014 01:21 PM, Peter Lebbing wrote: > As a public statement; now we're going into trust signature territory, which is > not really a common deployment in the WoT. But I guess you could simply make a > normal signature instead of a trust signature. True, you do not make a public > statement of distrust, but you don't make a statement of positive trust either. Furthermore, what would such a machine-readable statement of "i would never rely on his identity certifications" be useful for? You can already make such an assertion if you want to, but it won't be machine-readable. For example, you can write and sign a text document that says as much, and publish it on your blog, tweet it, put it in the newspaper, whatever. Having such an assertion cryptographically bound to the OpenPGP certificate in parseable form implies in some sense that you think a mechanical process (e.g. WoT calculated validity) should be able to make use of it. But how would that work? It sounds like you'd want to ask an OpenPGP to introduce an additional concept on top of the notions of validity and ownertrust (which are already confusing): some sort of meta-ownertrust: instead of ownertrust's question of: "how much am i willing to rely on NdK's identity assertions", meta-onwertrust would ask "how much am i willing to believe NdK's assessments of certification practice quality?" Who is going to understand this question? What kind of UI would you suggest for it? *and* by creating a standardized mechanism, you're encouraging further leakage of more-nuanced relationship information than would be found in a the traditional simple identity certification model. Sounds like a lot of protocol and UI complexity, with not much of a benefit to me. --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 faramir.cl at gmail.com Sat May 3 01:41:49 2014 From: faramir.cl at gmail.com (Faramir) Date: Fri, 02 May 2014 19:41:49 -0400 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <536419BE.7090403@fifthhorseman.net> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> Message-ID: <53642D3D.1010506@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 02-05-2014 18:18, Daniel Kahn Gillmor escribi?: > On 05/02/2014 06:03 PM, Faramir wrote: >> El 28-04-2014 14:35, Daniel Kahn Gillmor escribi?: ... >>> 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 ... >> What about to adding the boss key to the keys the message is >> encrypted to? > > You're saying instead of doing escrow of encryption keys? Yes, but now I realize it would only solve the problem of accessing files encrypted by you (and just because I always add my own key to the encryption recipients, it doesn't mean other people even want to be able to decrypt messages sent by them). > The only problem with that approach is that you have no control > over the people who are encrypting messages and sending them to > you. So you're bound to get some messages that the Boss wouldn't > be able to decrypt later. Yes, you are right... then, a new keypair for work related stuff, and handing over the encryption subkey. And maybe a big disclaimer saying "if you send personal stuff to me, send it to my personal email, encrypted to my personal key". Maybe it would be nice to be able to bind specific encryption keys to specific UIDs, but the simplest thing is to keep things apart. ... > I'm not saying that all employers *should* do escrow of all their > employees' encrpytion-capable keys. In fact, i think the majority > of employer/employee relationships should probably never require > any kind of key escrow. But there are some relationships where key > escrow makes sense, and i wanted to clarify that it *only* makes > sense for encryption-capable keys, not personal signing or > authentication keys. I agree. A few weeks ago I started working for a company that makes websites (usually, wordpress or joomla), and the passwords to access the sites obviously belong to the company. For now the solution was to say "the login details are in an excel file in my desktop, in case you need them". Of course I keep a copy with me in case the desktop dies or is stolen. A work mate left the login details of the site he was working on, written in a piece of paper on his desk (I hope he finishes it before somebody discards the paper while cleaning). And yes, I'm very uncomfortable with that, I'd rather have some way to have a thief proof passwords repository, but so far I don't know how to do it, and I'd also have to convince my boss and work mates to use it. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTZC09AAoJEMV4f6PvczxA7KEIAJVVeJkDMPIp7rgJ+adAvEen lBSc8S9wth7EHPyWRpcPzowlNoAZ5umkJviArBGpQe639kBgL+CJgtmMOFxLYzc8 PmJQzqLElmfS5usDt0TyA7WYoY4PlpMAU0uxECCxFrwJC5Qw6CHa+C5zuW8PdJ6J 6LUQ1onCYA7Rm3Mg4IsFrsFfrLeIdZeA8ilCfd2B3ymF6KjFH4m2jvqJDCegfdtK z1Xgh5DhgP9RiQ79to+lS6KOVHm5cn3etkaW3J+r/1Ew2muYqk14bOLUcrQhaWbx 2CJ8Td9kdgCVxVVMjIORoIV9WcLXZmxLw/HF09kbsZLNu1RIOD1LZc7nCMblASk= =zmUw -----END PGP SIGNATURE----- From faramir.cl at gmail.com Sat May 3 02:43:58 2014 From: faramir.cl at gmail.com (Faramir) Date: Fri, 02 May 2014 20:43:58 -0400 Subject: signatures for other people's emails In-Reply-To: <1877363.7A8bajizQs@inno> References: <1877363.7A8bajizQs@inno> Message-ID: <53643BCE.6050604@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 16-04-2014 11:14, Hauke Laging escribi?: > Hello, ... Hello Hauke, > 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. Well, my university handles it like this: the person sends the important message to the authority backing up the announcement (usually the "secretary of studies", a.k.a. the man you need to talk when there are troubles), and he sends it to the students. Students see a message from him and say "OMG, I hope I'm not in troubles, I need to read this". On thunderbird there is an addon that allows to re-expedite a message without modifying it, so I suppose it would not break an inline pgp signature, but probably s/mime would break. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTZDvOAAoJEMV4f6PvczxAD6MH/RWO+4VLedbQ0/aR0mx8lCPe dCiu9A3OegpHqlX8MBiiOQz8+/yhrymXwres4rroHWX3oeSJUuR5XKehyM9mI/9P oD+5quiCp0h82rgdytNJOuIBtHgzWef+dZxFt/21I82fItI3+qX62SonnDjrzwLa Lbb/DdYU8/PlWEs3SS+g20pFTPMplkMdhjAwZiqE3HZKZNq+WpYOewHeljKW1+GQ FUJw4lzFvqr17cOL2w4eOhRzP/SHHm6Q+c+FA8ysMikHoTNH3A3PF7HxcyuwNT1k isvEb81cFL4xxU88+FGWxFgEi80NfF9+cl6Dph4BC+VOESFTNYJnvaMpPh4qFXM= =A4K1 -----END PGP SIGNATURE----- From gnupg at tim.thechases.com Sat May 3 03:08:35 2014 From: gnupg at tim.thechases.com (gnupg at tim.thechases.com) Date: Fri, 2 May 2014 20:08:35 -0500 Subject: new keys vs. sub-keys vs. uids Message-ID: <20140502200835.2cb51cad@bigbox.christie.dr> Please forgive any folly (or poor word-choices for technical terms) in my questions, as I'm still feeling my way around the edges of GPG. I'd like to have different personas, all under one key. So I'd have one for my work email, one for personal email, one for each of several dozen mailing lists. I began my experimenting by creating various uids: $gpg --gen-key ... email: home at example.name ... Enter passphrase: ******* $gpg --edit-key home at example.name gpg> adduid ... Enter email address: work at example.com ... gpg> save However, after adding multiple uids and emailing an encrypted test message from the new UID (work at example.com), I noticed that Claws Mail reported that it had been signed by "home at example.name" instead of "work at example.com", leaking signature information I'd rather keep separated. I suspect I don't fully grasp the intent of additional UIDs. In the hope of keeping the entries completely separate, I then tried $rm -rf ~/.gnupg # these are just test-keys for now $gpg --gen-key ... email: home at example.name ... Enter passphrase: ******* $gpg --gen-key ... email: work at example.name ... Enter passphrase: ******* This seemed to work as expected, but has the down-side that I would have N separate passphrases to maintain/remember for each of the N personas. Yes, I can make them all the same passphrase, but it would be nice if they were all under one master passphrase. So I guess I'm looking for 1) something that doesn't leak identities across signatures 2) a single passphrase to manage the multiple identities 3) can be identified by the signing email address (Claws seems to make this easy for choosing the signing key) Is there a way I'm missing to go about keeping these separate without the overhead of new keys for each persona? Thanks, -tkc From faramir.cl at gmail.com Sat May 3 03:10:10 2014 From: faramir.cl at gmail.com (Faramir) Date: Fri, 02 May 2014 21:10:10 -0400 Subject: signatures for other people's emails In-Reply-To: <1567753.xkBQJNmas7@inno> References: <1877363.7A8bajizQs@inno> <1567753.xkBQJNmas7@inno> Message-ID: <536441F2.8030004@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 16-04-2014 13:37, Hauke Laging escribi?: > 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. You only need 1, but he must be well known. > 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). Well, then the sender must be somebody that usually sends important messages to students. One more message won't trouble him. > 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. Mmmm... you would have the message sent to the supporter, and if he forwards it with copy to you, maybe... or maybe not, not sure about what is the problem. > d) The same for the recipients: They cannot simply search for a > mail from the real sender. But the message should include your email address... again, I don't get what is the problem. > 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. Well, then he should involve the person that has the addresses, probably the person that uses to send important messages to students. Remember, no matter how many signatures the message has, if it doesn't come from a know source, they may consider it as spam and delete it without even opening it. You need the sender to be well know and respected. Yes, it would be nice to have a tool that allows you to attack a signal from other people to make the message more appealing, but then the email clients would have to support it, and now more and more people moves to webmail, that is becoming harder. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTZEHxAAoJEMV4f6PvczxAoGwH/0DMC65ihNCnd8j+eTdV7BEI AbP1A3trmj81ltmHizj+avEAVgJU+kgybneziu0UBHuknurLLNaPtcNL9Yvgjjir OW/llwkQg1MnXbCFqnsWrC6TqhPhNMnS3soHrCNICZzMxNspdktkLAjnpU0dU+xx Z/gOt5hwkBqzTw6T0Woc0zpPcADqa5PeNsR+DNAyqncM/TEwEuj1FNhWerS0oUWe L0q31PuTLzOT9QA1j3G7oWHjwQ/oiBxrqcjUYKb/no/qH3bmX+g4lH4JHsFmTAOw KZX2GfXxqErqfKEEBQguBlJ2IXuW1z2/yelg++IxxBVMYZGefnxyJYcgT0HfTps= =0/UI -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sat May 3 03:24:55 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 03 May 2014 11:24:55 +1000 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <1876570627.20140502140124@my_localhost> References: <87k3a7gt7q.fsf@vigenere.g10code.de> <5360AE82.6070505@dougbarton.us> <20140430082524.GA21587@platinum.gollo.at> <53614D96.9040108@dougbarton.us> <868503700.20140501131523@my_localhost> <53624770.6050503@sixdemonbag.org> <1876570627.20140502140124@my_localhost> Message-ID: <53644567.1000302@sixdemonbag.org> > To somebody who simply contacted the supplier of a "free" service to > instruct them to cancel the free service, it is quite a substantial > unexpected bill: to many people, choosing to pay it may equate to > choosing not to eat for two or three days. I find it unlikely someone who has the financial means to keep a server provisioned will be left unable to eat for two or three days over a $25.90 fee. Inconvenienced, sure, but that inconvenience is the result of improper planning on their part. Further, you are not asking StartSSL to "cancel the free service." This isn't about asking StartSSL to stop doing something: this is about asking them to *do something new* -- generate a revocation certificate and ensure it gets propagated to all the certificate revocation lists. That's nontrivial. From rjh at sixdemonbag.org Sat May 3 03:32:34 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 03 May 2014 11:32:34 +1000 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <536419BE.7090403@fifthhorseman.net> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> Message-ID: <53644732.8090302@sixdemonbag.org> > 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. Imagine this: you're a purchasing agent at Yoyodyne. You've established WoT connections with all your providers using a certificate whose only UID is: "Daniel Kahn Gillmor (sales orders only) " Now you go out on vacation for three weeks and on day four a sudden business need arises in which a sales order must be filed. Seems perfectly reasonable for me for the company to issue a signature on a purchase order using your *corporate-owned*, *corporate-controlled* certificate, which was always issued for the needs of the corporation. Just because a certificate has your name on it doesn't make it yours and doesn't mean you have a legal or moral right to control how it's used. Personally, I would prefer not to have my name on such a certificate, for reasons that have already been expressed on the list. But if there's a corporate policy that says each cert must have the name of someone authorized to use it, then that's the way you play the game. From dkg at fifthhorseman.net Sat May 3 03:53:53 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 02 May 2014 21:53:53 -0400 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <53644732.8090302@sixdemonbag.org> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> Message-ID: <53644C31.8080206@fifthhorseman.net> On 05/02/2014 09:32 PM, Robert J. Hansen wrote: >> 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. > > Imagine this: you're a purchasing agent at Yoyodyne. You've established > WoT connections with all your providers using a certificate whose only > UID is: > > "Daniel Kahn Gillmor (sales orders only) " > > Now you go out on vacation for three weeks and on day four a sudden > business need arises in which a sales order must be filed. This business use case could be better handled by ensuring that whoever is filling my shoes for three weeks has their own key and has a relationship with the customers/clients/vendors that they need to work with. Cryptography aside, that's a just a better and more honest way to do business, rather than trying to pretend i'm not actually on vacation. So i mean, sure, i can definitely imagine a company doing it the way you describe. I just don't think it's a good business practice. OTOH, if the key was a role key (that is, if the User ID on the key was just "Yoyodyne Sales ") then it's no longer a personal key and sharing the associated signing or certifying key with other people who fill that role wouldn't be unreasonable. Tangentially: there are still cleverer ways to manage role keys like that, if you want to provide accountability and smoother transitions -- for example, the role key's certifying public key could be managed strictly by the sysadmin, and she could add separate signing subkeys for each member of the Yoyodyne sales force. Then if a message is signed, you know which of your team actually signed it. And if someone leaves the team, you can just revoke their signing subkey, (if the role key had an encryption-capable subkey, though, you'd still need to rotate that subkey -- revoke the old subkey, create and distribute a new subkey -- since that subkey would be shared by all members of the team in a role key scenario). --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 dshaw at jabberwocky.com Sat May 3 04:28:12 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 2 May 2014 22:28:12 -0400 Subject: new keys vs. sub-keys vs. uids In-Reply-To: <20140502200835.2cb51cad@bigbox.christie.dr> References: <20140502200835.2cb51cad@bigbox.christie.dr> Message-ID: On May 2, 2014, at 9:08 PM, gnupg at tim.thechases.com wrote: > So I guess I'm looking for > > 1) something that doesn't leak identities across signatures > 2) a single passphrase to manage the multiple identities > 3) can be identified by the signing email address (Claws seems to > make this easy for choosing the signing key) > > Is there a way I'm missing to go about keeping these separate without > the overhead of new keys for each persona? Briefly, no. The signature is issued from the key, not by a particular identity using that key. There is an optional feature in OpenPGP to say "I meant that signature to come from *this* user ID", but that doesn't really solve your problem either - it doesn't hide the fact that there are other identities or what those identies are, but rather indicates the one (of several) that you're using at the moment. In any event, GPG doesn't support that feature (neither does PGP). If you have a key with multiple user IDs, anyone looking at that key can see all of those identities. The standard method for doing what you are trying to do is to have two separate keys. David From rjh at sixdemonbag.org Sat May 3 05:01:05 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 03 May 2014 13:01:05 +1000 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <53644C31.8080206@fifthhorseman.net> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> Message-ID: <53645BF1.9020703@sixdemonbag.org> > So i mean, sure, i can definitely imagine a company doing it the way you > describe. I just don't think it's a good business practice. Unfortunately, the world doesn't much care what we think of as good business practices. And why should they? We're nerds -- we understand technology, perhaps, but odds are good few if any of us have ever sat at the CIO/CTO/CSO level. On what expertise do we declare it to be "not good business practice"? I agree that this is not the sort of business practice I would like to see, but I'm not willing to go out on the limb with you and to declare it a bad business practice. And regardless of whether it's a good practice or a bad one, I've worked in businesses that have done exactly this -- so it's a real-world example that demonstrates the occasional need for a third party to possess signing keys. From ndk.clanbo at gmail.com Sat May 3 09:54:48 2014 From: ndk.clanbo at gmail.com (NdK) Date: Sat, 03 May 2014 09:54:48 +0200 Subject: Signature without policy meaningless? (was Re: UI terminology for calculated validities) In-Reply-To: <536425F2.9090008@fifthhorseman.net> References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <1570455.5MFBMy4FEj@inno> <333214734.20140502145746@my_localhost> <5363B5EE.3040201@digitalbrains.com> <5363B7FC.9050006@gmail.com> <5363D437.8030307@digitalbrains.com> <536425F2.9090008@fifthhorseman.net> Message-ID: <5364A0C8.6050002@gmail.com> Il 03/05/2014 01:10, Daniel Kahn Gillmor ha scritto: > Having such an assertion cryptographically bound to the OpenPGP > certificate in parseable form implies in some sense that you think a > mechanical process (e.g. WoT calculated validity) should be able to make > use of it. But how would that work? Making WoT calculator avoid looking for keys signed by that user if reached throught my certification. > It sounds like you'd want to ask > an OpenPGP to introduce an additional concept on top of the notions of > validity and ownertrust (which are already confusing): They work: I'm *really* confused. :) > some sort of meta-ownertrust: instead of ownertrust's question of: > "how much am i willing to rely on NdK's identity assertions", Well, if ownertrust answers that, it's what I need: a way to say "I am sure this key belongs to X, but I don't want it to be used to introduce more keys in the WoT". > meta-onwertrust would ask > "how much am i willing to believe NdK's assessments of certification > practice quality?" Who is going to understand this question? What kind > of UI would you suggest for it? No, it's not what I meant. BYtE, Diego. From martin-gnupg-users at dkyb.de Sat May 3 10:07:25 2014 From: martin-gnupg-users at dkyb.de (Martin Behrendt) Date: Sat, 03 May 2014 10:07:25 +0200 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <53645BF1.9020703@sixdemonbag.org> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> Message-ID: <5364A3BD.4060009@dkyb.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 03.05.2014 05:01, schrieb Robert J. Hansen:> > And regardless of whether it's a good practice or a bad one, I've > worked in businesses that have done exactly this -- so it's a > real-world example that demonstrates the occasional need for a > third party to possess signing keys. > And regardless of whether it's a good practice or a bad one, I've worked in businesses that have done exactly this (ordered people to jump out the windows) -- so it's a real-world example that demonstrates the occasional need for a company to make such orders. Am 03.05.2014 03:32, schrieb Robert J. Hansen: > > Personally, I would prefer not to have my name on such a > certificate, for reasons that have already been expressed on the > list. But if there's a corporate policy that says each cert must > have the name of someone authorized to use it, then that's the way > you play the game. Personally, I would prefer not to discriminate against black people, for reasons that have already been expressed on the list. But if there's a corporate policy that says I have to, then that's the way you play the game. PLEASE refrain from using generic phrases which defend stupidity because the stupidity is done in real-life. These are lazy things to say, they might sounds like arguments, but they are not. And they have been used way to often to defend the worst human behavior or to defend why nobody did something against it. It makes by heart bleed every time I see or hear them. It is okay to say: "This is done." But please ALWAYS conclude (if "this" is stupid/injustice/bad practice) "but it needs to be changed." I know, we are living in a world where it is hard to fight every stupidity that is in place. And sometimes you have to do these stupid things in order to get somewhere. But a first easy step is, not to defend them. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEAREKAAYFAlNko7wACgkQ/6vdZgk46shmbQCfQ7jsvq208OHZyQATOceBDYMF eMwAn27OZCAZlMUvhtvgDZ/Ox7snzqWr =T/dl -----END PGP SIGNATURE----- From nicholas.cole at gmail.com Sat May 3 10:50:47 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sat, 3 May 2014 09:50:47 +0100 Subject: Signature without policy meaningless? (was Re: UI terminology for calculated validities) In-Reply-To: <5364A0C8.6050002@gmail.com> References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <1570455.5MFBMy4FEj@inno> <333214734.20140502145746@my_localhost> <5363B5EE.3040201@digitalbrains.com> <5363B7FC.9050006@gmail.com> <5363D437.8030307@digitalbrains.com> <536425F2.9090008@fifthhorseman.net> <5364A0C8.6050002@gmail.com> Message-ID: On Sat, May 3, 2014 at 8:54 AM, NdK wrote: > Il 03/05/2014 01:10, Daniel Kahn Gillmor ha scritto: > >> Having such an assertion cryptographically bound to the OpenPGP >> certificate in parseable form implies in some sense that you think a >> mechanical process (e.g. WoT calculated validity) should be able to make >> use of it. But how would that work? > Making WoT calculator avoid looking for keys signed by that user if > reached throught my certification. > >> It sounds like you'd want to ask >> an OpenPGP to introduce an additional concept on top of the notions of >> validity and ownertrust (which are already confusing): > They work: I'm *really* confused. :) > >> some sort of meta-ownertrust: instead of ownertrust's question of: >> "how much am i willing to rely on NdK's identity assertions", > Well, if ownertrust answers that, it's what I need: a way to say "I am > sure this key belongs to X, but I don't want it to be used to introduce > more keys in the WoT". But it doesn't work like that anyway. Unless you are using Trust signatures (and few people do) then a signature on a key does not encourage a 3rd party to trust signatures made by that key. Even if a key is recognised as authenticated/validated/certified for association with a particular email address, the signatures made by that key will not be trusted by anyone who has not made an active decision to make a particular key a trusted introducer. In fact, this is a reason (though one of many) why the web of trust has never quite lived up to its promise. No UI that I am aware of sets even marginal trust by default on newly imported keys. Most users (I suspect) will only ever end up trusting keys that they themselves have signed. That is the default position. It is interesting to speculate whether the WoT would have been more effective if there had been a culture of marginally trusting new keys by default, allowing users to make an active choice either to not trust someone or to fully trust someone. As it is, the inertia of the system works against the idea of a web of trust.[*] In any case - there is no need for what you are suggesting. 3rd parties are not (by default) going to infer from your signature that they should then trust the key you sign as an introducer. N. [*] I'm aware there are problems with "marginal trust" related the fact that the requirement of three marginally trusted signatures to confer validity may in fact be fairly weak. The three signatures may not, in fact, be made independently of each other (consider three keys owned by the same person which all introduce a third key, for example, or multiple signatures made a single key-signing party). From rjh at sixdemonbag.org Sat May 3 13:35:14 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 03 May 2014 21:35:14 +1000 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <5364A3BD.4060009@dkyb.de> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> <5364A3BD.4060009@dkyb.de> Message-ID: <5364D472.9000206@sixdemonbag.org> > Personally, I would prefer not to discriminate against black people, > for reasons that have already been expressed on the list. But if > there's a corporate policy that says I have to, then that's the way > you play the game. In which case, the proper response is to say "I quit." That's a simple moral issue: the company policy is for something I find morally reprehensible, and so I quit. Morally reprehensible policies, though, are not the same as *foolish* policies. In which case yes, by all means, bring the foolishness to the attention of those who have the ability to change it... but so long as you wish to be employed, make sure to comply with the foolish policy. Speaking just for myself, if my employer were to slam a business-class plane ticket in my hand and tell me "you're flying to Indore and hopping a bus to Ranapur and we want you to have your face painted blue for the entire journey," well, I might ask a few questions. But it's hardly offensive and I have a rent check to pay, and I've done many things in my life more foolish than painting my face blue before hopping on a business-class to Indore. > It is okay to say: "This is done." But please ALWAYS conclude (if > "this" is stupid/injustice/bad practice) "but it needs to be changed." This is done. But, you know what? *We're not going to change it*. So, since this is done, let's accept reality and work with what is, rather than talk about what a tremendous injustice it is that the world has stupid people in it who will not listen to our wisdom about the way things ought to be. The world is full of stupid people and stupid policies. Change what you can; encourage others to change what they can; and when 99% of the world around you is still as stupid as it was yesterday, roll up your shirtsleeves and start engaging with what's left. From wish at dumain.com Sat May 3 14:53:41 2014 From: wish at dumain.com (William Hay) Date: Sat, 3 May 2014 13:53:41 +0100 Subject: UI terminology for calculated validities In-Reply-To: <535A27BC.40602@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> <1397259291.20140424204510@my_localhost> <53598DE0.2060301@gmail.com> <535A27BC.40602@digitalbrains.com> Message-ID: <20140503135341.4ca90615@cerberus.dumain.com> On Fri, 25 Apr 2014 11:15:40 +0200 Peter Lebbing wrote: > 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 wonder if discussing terminology separate from the overall UI is the best idea? I suspect that the more words one makes people learn to use a technology the fewer people will use it. If one wants widespread adoption I think one needs a GUI (phone/tablet or WIMP style) and this provides more options than the traditional GnuPG dumb terminal compatible interface. However if we're mucking around with terminology can I suggest replacing the terms key signing and certificates with the metaphor of 'letters of introduction'? Key signing is a confusing mixed metaphor. I doubt anyone on the list has ever signed a real key -most inks don't take well to metals. Certificates on the other hand seem more appropriate for a hierarchical system than WoT. Letters of introduction are not something one encounters much in the modern world one but tying the process to a physical analogue might make things easier to understand. One could recycle old costume dramas to make tutorials. In normal usage one needs the answer to two questions: Can I send private messages to this person? Did this message/file come from the person in question? The answers can be represented graphically (green tick, red cross). The sort of person who is interested in the details of how that particular conclusion was reached can probably be expected to learn the current terminology. It gets a bit more complicated when managing/signing keys but with a GUI one could just present statements about a key for the user to assent (or not to) without any need to classify the statement itself. I (will not say whether|do not know whether|am quite confident that|am very confident that) this key belongs to . Use a drop down menu to choose among the options Issue letter of introduction: Yes/no? Accept introductions made via this key: (No,In concert with X others,Yes). Certain options (like trust signatures, ultimate trust and accepting introductions from a key without having validated/authenticated any userids on it) could be hidden behind an expert mode button. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From 2014-667rhzu3dc-lists-groups at riseup.net Sat May 3 17:05:16 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 3 May 2014 16:05:16 +0100 Subject: new keys vs. sub-keys vs. uids In-Reply-To: <20140502200835.2cb51cad@bigbox.christie.dr> References: <20140502200835.2cb51cad@bigbox.christie.dr> Message-ID: <1145815351.20140503160516@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 3 May 2014 at 2:08:35 AM, in , gnupg at tim.thechases.com wrote: > However, after adding multiple uids and emailing an > encrypted test message from the new UID > (work at example.com), I noticed that Claws Mail reported > that it had been signed by "home at example.name" instead > of "work at example.com", The email client will have told GnuPG to search for a key with a UID containing , which it found. I suspect was reported by the email client as the signing identity due to being set as the default UID. Anybody could look at the key using GnuPG or something like PGPdump and see all the IDs. In fact, simply checking the signature with GnuPG should display something like:- gpg: Good signature from "... " [unknown] gpg: aka "... " [unknown] > In the hope of > keeping the entries completely separate, I then tried [a unique key for each persona] > This seemed to work as expected, but has the down-side > that I would have N separate passphrases to > maintain/remember for each of the N personas. Yes, I > can make them all the same passphrase, but it would be > nice if they were all under one master passphrase. GnuPG can't manage your passphrases for you, but there are various password managers available to do just that. > So I guess I'm looking for > 1) something that doesn't leak identities across > signatures Not leaking the identity information can be achieved by not putting it in your UIDs. For example, my key has only one UID: "MFPA " However, not having the email address in my UID makes it harder for people to use my key. Anybody who receives signed emails that I sent from different addresses can see they were signed with the same key and deduce they are likely to be from the same person. But they cannot look at the key and enumerate what other addresses or names I might use. > 2) a single passphrase to manage the > multiple identities You could use the same password for several keys, or use a password manager such as you might use to remember website login details. > 3) can be identified by the signing > email address (Claws seems to make this easy for > choosing the signing key) To enable my email client to locate my key by email address, I make use of group lines in my gpg.conf. For example:- group <2014-667rhzu3dc-lists-groups at riseup.net>=0xA8A90B8EAD0C6E69 For my email client, this only works if the email address in the group line is surrounded by angle brackets. Other people report that they need to omit the angle brackets, and still others report that it does not matter for them. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Free advice costs nothing until you act upon it -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNlBblXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pfWMD/36QBpvlbY33J27Y2UmCfg7PUNR6wL+Wtaci DQM/JkmMFQZPg3MeYrCEBjO1xosMcvRgtof/TTaV4XkiR1XPdW8JHTiQVNCTHYjg DCY9aGVugClVdC/BeNxIwXD4ttBB9cOENHoCCnFOZerOSdIj0r2238eguascLNXR AkDhgdY1 =p1Ik -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sat May 3 18:28:56 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 3 May 2014 17:28:56 +0100 Subject: UI terminology for calculated validities In-Reply-To: <20140503135341.4ca90615@cerberus.dumain.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> <535A27BC.40602@digitalbrains.com> <20140503135341.4ca90615@cerberus.dumain.com> Message-ID: <1202141502.20140503172856@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 3 May 2014 at 1:53:41 PM, in , William Hay wrote: > I wonder if discussing terminology separate from the > overall UI is the best idea? I think the discussion has been of some use in aiding some of us's understanding, but has gone at least as far as it usefully could. Provided words/phrases are not recycled in a UI and its FAQ/manual to mean something different to an already-accepted meaning in the context of GnuPG/OpenPGP, I think it matters little which words are used to get across what needs to be conveyed. > However if we're mucking around with terminology can I > suggest replacing the terms key signing and > certificates with the metaphor of 'letters of > introduction'? [...] > Letters of > introduction are not something one encounters much in > the modern world one but tying the process to a > physical analogue might make things easier to > understand. One could recycle old costume dramas to > make tutorials. That is an interesting thought. I wonder how what proportion of the population would know what it meant, unless it appeared in a book they studied at school or a film/TV programme they saw last week. > In normal usage one needs the answer to two questions: > Can I send private messages to this person? Did this > message/file come from the person in question? I would propose a third question: Was the message/file altered in transit? > It gets a bit more complicated when managing/signing > keys but with a GUI one could just present statements > about a key for the user to assent (or not to) without > any need to classify the statement itself. > I (will not say whether|do not know whether|am quite > confident that|am very confident that) this key belongs > to . Why ask the certification level? What is this information used for? Unless it actually has a real use, the user should not be asked to spend time considering it, it should not be recorded, and certainly should not be published. If somebody thinks they need this, and knows why, they should be able to find it in an "expert" mode. The basic user (and in my opinion, most users) should just have one question but need to answer it in respect of each UID, something like:- "I accept this key for communication with . Yes/No" aka . Yes/No" aka . Yes/No" > Issue letter of introduction: Yes/no? I think this should also be in an "expert" mode, or at least absent from a "basic" mode. And I would prefer something more like "I hereby publicly state that this key belongs to . Yes/No" With a Yes/No selector for each of the UIDs on the key. The active copy on the user's keyring should get a non-exportable signature whatever the answer, and for each UID where the user answered "Yes" a copy bearing the exportable signature on that UID only should be placed in a message encrypted to that key and pre-addressed to the email address in that UID. > Accept introductions made via this key: (No,In concert > with X others,Yes). Another I think should possibly not be in the "basic" mode. Does an absolute beginner really need to be able to nominate trusted introducers? - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net 1 + 1 = 3, for large values of 1 -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNlGVZXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pBVcEAII7VGBQuIJlBiWbqYbnROpKKba4zNRN+gWR uN9zmr6C/r6Rkr/YNL4vcyckr2vxxvdCcD17sXpaAK5RI3ltG1JyhFW9P1NXOxWE 6wZKoUEIBc8O8Ba99IIzdBzD7J0VrOfh3xvJgrq/lXAZNNYD4OVUAMQEZS6lzgSe 9ESBdSzz =kdgF -----END PGP SIGNATURE----- From wish at dumain.com Sat May 3 20:56:55 2014 From: wish at dumain.com (William Hay) Date: Sat, 3 May 2014 19:56:55 +0100 Subject: UI terminology for calculated validities In-Reply-To: <1202141502.20140503172856@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> <53598DE0.2060301@gmail.com> <535A27BC.40602@digitalbrains.com> <20140503135341.4ca90615@cerberus.dumain.com> <1202141502.20140503172856@my_localhost> Message-ID: <20140503195655.5c2dfe81@cerberus.dumain.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sat, 3 May 2014 17:28:56 +0100 MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote: > > Letters of > > introduction are not something one encounters much in > > the modern world one but tying the process to a > > physical analogue might make things easier to > > understand. One could recycle old costume dramas to > > make tutorials. > > That is an interesting thought. I wonder how what proportion of the > population would know what it meant, unless it appeared in a book they > studied at school or a film/TV programme they saw last week. It's a descriptive term so it shouldn't be all that hard to guess the meaning. In any case I think people would get it straight away if one showed them a video clip of someone requesting,receiving and then using a paper letter of introduction. That would make it easier to explain the digital equivalent. Pity D'Artagnan lost his. > > In normal usage one needs the answer to two questions: > > Can I send private messages to this person? Did this > > message/file come from the person in question? > > I would propose a third question: Was the message/file altered in > transit? In most cases this would have the opposite answer to the second question. It might make things simpler to combine them in practice: Is this an unaltered message/file from the purported sender? > > > > > It gets a bit more complicated when managing/signing > > keys but with a GUI one could just present statements > > about a key for the user to assent (or not to) without > > any need to classify the statement itself. > > > I (will not say whether|do not know whether|am quite > > confident that|am very confident that) this key belongs > > to . > > Why ask the certification level? What is this information used for? > Unless it actually has a real use, the user should not be asked to > spend time considering it, it should not be recorded, and certainly > should not be published. If somebody thinks they need this, and knows > why, they should be able to find it in an "expert" mode. You're right. If we're not issuing certs/letters of introduction then there is no need. If we are then for compatibility with the existing WoT I don't think we can avoid asking. > > The basic user (and in my opinion, most users) should just have one > question but need to answer it in respect of each UID, something > like:- > > "I accept this key for communication with . Yes/No" > aka . Yes/No" > aka . Yes/No" Presumably if implementing with the existing gnupg infrastructure this would be a non-exportable generic certification? > > > > > Issue letter of introduction: Yes/no? > > I think this should also be in an "expert" mode, or at least absent > from a "basic" mode. I'd prefer to keep things like trust signatures and granting ultimate trust a little more fenced off than ordinary keysigning/letters of introduction so perhaps an intermediate mode. > > And I would prefer something more like "I hereby publicly state that > this key belongs to . Yes/No" With a Yes/No selector for each > of the UIDs on the key. Once you start doing things publicly one would need to pick a certification level in order to inter-operate with the existing WoT. It isn't clear to me that there is a good default. My original phrasing was intended to fit in with the letter of introduction metaphor. While in the long run I may have to kill my darlings for now I'll stick to trying to make my pet metaphor work. In that context I think leading off the whole thing with "To whom it may concern," might work better than a separate public declaration for each uid. > > Accept introductions made via this key: (No,In concert > > with X others,Yes). > > Another I think should possibly not be in the "basic" mode. Does an > absolute beginner really need to be able to nominate trusted > introducers? Another one for an intermediate mode I think. William -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJTZTv3AAoJEIs9pW5WIWm3C1sQAIKCxAgFZPGNHit4XEVRsY3E sHpTrXhat94XVH42PNSKGpsZ5QPOcBfsgQKBC1zLCKJwSV8a5qEy94Idd1zKVlv3 FTszxd8TEYToQXexTX5AFxQmuOTR5HKGlFKO2DZigK7BVtE2BtLATADroJ0JQs8A rK1MkGVlUaaVM2n0ZGY0V5zIE1q7xhMvkyzXQK757NdybA9VhXX8k1zIzLsnrpue OjzkyRV0RllyULqjuLNGkotACEarB8stlJubdPoxKBrhTF5Ajiv0lsA5b4gMX69S 60SiwP8EANpJvwmE/i6HdDZh9niQ2QqdaTbW5NrKn4aoxr4gRAnPZrfaynsJYhUy CCTtITAntg1yLkemx4NoCididqkYZx1MY/fnn3zslptXFQWAUtz8RKJl+zuCnkNT AFAQZxzVJig6Re3NSCnhVNqxPiDJLE146ZrNqdW/4mQvKN1+eZM4HllU1TeAnGAD AOnLLRK0+v58sdf4gy0WGAQl1xI3zk0B/7CCIQlXQLtk6Mg14qlj1AEka6IXAXCj 6M58ntipwCUZI4m1aYwhI+PRj7C7UxJ0IgWTR2Vo+bqpp93uhptcwsfbSRqfeNV9 P2gHj/I4xmrgq8A7y+kzsZSRUyv05uhFQhDURXqQrYc3wZbTyHEIOuvKrDqIM03E 9nEF0bvQ0McPnvbG9OwU =wYHb -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sat May 3 23:33:14 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 3 May 2014 22:33:14 +0100 Subject: UI terminology for calculated validities In-Reply-To: <20140503195655.5c2dfe81@cerberus.dumain.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> <535A27BC.40602@digitalbrains.com> <20140503135341.4ca90615@cerberus.dumain.com> <1202141502.20140503172856@my_localhost> <20140503195655.5c2dfe81@cerberus.dumain.com> Message-ID: <1894803954.20140503223314@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 3 May 2014 at 7:56:55 PM, in , William Hay wrote: > In most cases this would have the opposite answer to > the second question. It might make things simpler to > combine them in practice: > Is this an unaltered message/file from the purported > sender? Combining is good. Back to two simple questions. But I disagree with the premise that the third question would usually have had the opposite answer to the second: emails are frequently slightly altered in transit, breaking the signature, but still came from the purported sender. > You're right. If we're not issuing certs/letters of introduction then > there is no need. If we are then for compatibility with the existing > WoT I don't think we can avoid asking. I refer you to an article on Daniel Kahn Gillmor's blog. > Presumably if implementing with the existing gnupg > infrastructure this would be a non-exportable generic > certification? Yes. Exactly what you would get by default from applying a non-exportable signature with GnuPG. > Once you start doing things publicly one would need to > pick a certification level in order to inter-operate > with the existing WoT. It isn't clear to me that there > is a good default. The existing default of an 0x10 "Generic certification" is a good default. GnuPG only prompts you to pick a certification level if you enable the "--ask-cert-level" option, which is disabled by default. As far as I know, the level doesn't affect WoT calculations. > My original phrasing was intended to fit in with the > letter of introduction metaphor. While in the long run > I may have to kill my darlings for now I'll stick to > trying to make my pet metaphor work. In that context I > think leading off the whole thing with "To whom it may > concern," might work better than a separate public > declaration for each uid. "To whom it may concern" is much more subtle than "I hereby publicly state," but a letter of introduction that was not specifically addressed could be considered a form of public declaration. I still think there is merit in making the user choose which UIDs to include in the letter of introduction: some of them may include email addresses, roles, or personas outwith the user's knowledge of the key owner. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net No matter what a man's past may have been, his future is spotless. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNlYKVXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pXSYD/1b3wL/SkQ9qrrjOR+XdAz23eMe/6tz4FAUy NxXo2p/DMPVn+VW2pY7Vq9Ko2G4r+ydFtyst9364BOXBihspWuir4K5byaW8lPjC lcDfjvCfJIXs+8Zz6BKzw8z0LPZLdizCD9xC5CKdBWl77ipStb+cVlPBOF9sxrl1 jVERs1qb =wWHU -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Sat May 3 23:47:22 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 03 May 2014 23:47:22 +0200 Subject: UI terminology for calculated validities In-Reply-To: <1894803954.20140503223314@my_localhost> References: <53564380.10000@josuttis.de> <20140503195655.5c2dfe81@cerberus.dumain.com> <1894803954.20140503223314@my_localhost> Message-ID: <2123757.Pxcbtkot8g@inno> Am Sa 03.05.2014, 22:33:14 schrieb MFPA: > GnuPG only prompts you to pick a certification level if you enable the > "--ask-cert-level" option, which is disabled by default. As far as I > know, the level doesn't affect WoT calculations. Then let's extend your knowlege: --min-cert-level It's even explained in dkg's article which you point to. 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 Sun May 4 03:27:41 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 4 May 2014 02:27:41 +0100 Subject: UI terminology for calculated validities In-Reply-To: <2123757.Pxcbtkot8g@inno> References: <53564380.10000@josuttis.de> <20140503195655.5c2dfe81@cerberus.dumain.com> <1894803954.20140503223314@my_localhost> <2123757.Pxcbtkot8g@inno> Message-ID: <193671611.20140504022741@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 3 May 2014 at 10:47:22 PM, in , Hauke Laging wrote: > Then let's extend your knowlege: --min-cert-level > It's even explained in dkg's article which you point > to. It says "(users can change this cutoff with the --min-cert-level option, but it's not clear why they would want to do so)." This is not so much an explanation, as an acknowledgement of a function he cannot explain a use case for. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net A closed door is an invitation to knock -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNll5NXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pPfID/1YVU2I/WeTbf1vwWU6WwrFe9RDJpSKXXraA UypZECi3I9R6WQRy/QN+97gCqS4eFeWoissTbrGihSWl34cg6jweiJrCDaSfykoW F91Unb9p1vsOg5gy/D8o3KrxvWggcEtLW58zVCYSs+0wVCTiaFXt8oVqP+e3ZMD3 180Nn9un =8ibp -----END PGP SIGNATURE----- From ndk.clanbo at gmail.com Sun May 4 09:03:15 2014 From: ndk.clanbo at gmail.com (NdK) Date: Sun, 04 May 2014 09:03:15 +0200 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <53645BF1.9020703@sixdemonbag.org> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> Message-ID: <5365E633.8050805@gmail.com> Il 03/05/2014 05:01, Robert J. Hansen ha scritto: > And regardless of whether it's a good practice or a bad one, I've worked > in businesses that have done exactly this -- so it's a real-world > example that demonstrates the occasional need for a third party to > possess signing keys. That practice is the same as asking you to sign blank sheets of paper so they can later write on them what they like. IMVHO it's an *illegal* practice, and actually I vaguely remember news about a case where a female worker had to sign a blank sheet, that was later used for her "resignation" when she asked for maternity leave. IIRC she won the cause. Signing cards, at least here in Italy, are bound to a person. If multiple persons can sign the same kind of document (or if a "vice" is needed), then there are more cards, each controlled by a different person. That's why it's called "qualified signature" and it's (legally) stronger than a plain one. As already pointed out it could be different for encryption-only keys, that could be escrowed under some circumstances. BYtE, Diego. From ndk.clanbo at gmail.com Sun May 4 09:21:24 2014 From: ndk.clanbo at gmail.com (NdK) Date: Sun, 04 May 2014 09:21:24 +0200 Subject: Signature without policy meaningless? (was Re: UI terminology for calculated validities) In-Reply-To: References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <1570455.5MFBMy4FEj@inno> <333214734.20140502145746@my_localhost> <5363B5EE.3040201@digitalbrains.com> <5363B7FC.9050006@gmail.com> <5363D437.8030307@digitalbrains.com> <536425F2.9090008@fifthhorseman.net> <5364A0C8.6050002@gmail.com> Message-ID: <5365EA74.5040502@gmail.com> Il 03/05/2014 10:50, Nicholas Cole ha scritto: >> Well, if ownertrust answers that, it's what I need: a way to say "I am >> sure this key belongs to X, but I don't want it to be used to introduce >> more keys in the WoT". > But it doesn't work like that anyway. Unless you are using Trust > signatures (and few people do) then a signature on a key does not > encourage a 3rd party to trust signatures made by that key. Ah, OK. Now it makes more sense. Tks for the clarification. > Even if a key is recognised as authenticated/validated/certified for > association with a particular email address, the signatures made by > that key will not be trusted by anyone who has not made an active > decision to make a particular key a trusted introducer. IIUC, *unless* I tsig it. But if I use tsig I'm doing both an "identity" signature and a trust signature. I see no way I can publicly say "I don't really know real-world identity of this subject, but I trust him as an introducer" (yep, might sound strange [*], but often a pseudonym is more meaningful than RL name, but pseudonyms aren't "good" in WoT): if I tsig his key, I'm cerifying his pseudonym -- that I shouldn't do since it's not on any document. [*] well, not too strange in many cases, when it's "healtier" that a pseudonym is *not* easily correlated to a RL identity. > In fact, this is a reason (though one of many) why the web of trust > has never quite lived up to its promise. No UI that I am aware of > sets even marginal trust by default on newly imported keys. Most > users (I suspect) will only ever end up trusting keys that they > themselves have signed. That is the default position. Understandable/safer, but harder to bootstrap :) BYtE, Diego. From rjh at sixdemonbag.org Sun May 4 10:30:23 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 04 May 2014 18:30:23 +1000 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <5365E633.8050805@gmail.com> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> <5365E633.8050805@gmail.com> Message-ID: <5365FA9F.60702@sixdemonbag.org> > That practice is the same as asking you to sign blank sheets of paper so > they can later write on them what they like. The better comparison is to the autopen. And if that's good enough for President Obama... The autopen is a machine that replicates a physical signature. That's pretty much a perfect analogue to what we're talking about here: should it be possible for a third party to recreate your digital signature? Should it be possible for a third party to recreate your *physical* signature? That one has been conclusively answered 'depending on the circunstances, yes!' time and time again. Consider the President as an example: he may wish to sign a piece of legislation but he's unfortunately unavailable for signatures. Instead, he contacts a trusted secretary and orders the secretary to autopen his signature on a document -- said signature, since it is made on his behalf (even if it's physically made by a machine operated by a third person), being just as legally binding as if he himself had written his signature. Are there good business reasons for third party escrow of signing keys? Quite probably. If you can think of a situation where an autopen is appropriate, whether in business or in government, that's also a situation where third-party escrow of signing keys would also likely be appropriate. From martin-gnupg-users at dkyb.de Sun May 4 11:38:15 2014 From: martin-gnupg-users at dkyb.de (Martin Behrendt) Date: Sun, 04 May 2014 11:38:15 +0200 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <5365FA9F.60702@sixdemonbag.org> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> <5365E633.8050805@gmail.com> <5365FA9F.60702@sixdemonbag.org> Message-ID: <53660A87.4090902@dkyb.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 04.05.2014 10:30, schrieb Robert J. Hansen: > > Are there good business reasons for third party escrow of signing > keys? Quite probably. If you can think of a situation where an > autopen is appropriate, whether in business or in government, > that's also a situation where third-party escrow of signing keys > would also likely be appropriate. > No, there are no good reasons. There is no technical problem to give different signers the same rights to make certain signatures but make it comprehensible who actually signed it. This is important in case an error happened or someone intentionally did something wrong to commit a crime. In a world were everyone would do the right thing and didn't make mistakes I would be definitely with you. It would be no problem to not be able to distinguish who actually made a signature. But we are not living in that world. And you should know that. I read your story "Two Thousand Miles to the Promised Land". Just imagine that guy being able to make signatures appeared to be made by you or anyone else in the company without the recipient knowing, juts because there have been "good business reasons". Imagine how much more damage he could have done. So again, there are no good business reason. There are only reasons like laziness, stupidity or it costs to much. And it costs to much might be a legitimate reason in our world. But only so long someone made damage that is higher than the cost to make it right from the beginning. And as a side note. Your answer to my other mail completely missed my point. I was saying that you are using phrases and rhetoric rather than arguments to try to defend your point. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEAREKAAYFAlNmCoYACgkQ/6vdZgk46sjI1gCfb7+PXECe2By1dDjkdshLvjvx qpAAnA3u2C3tKx9ivulWwTD6SexqnS4y =xPrL -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sun May 4 12:51:27 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 4 May 2014 11:51:27 +0100 Subject: Signature without policy meaningless? (was Re: UI terminology for calculated validities) In-Reply-To: <5365EA74.5040502@gmail.com> References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <1570455.5MFBMy4FEj@inno> <333214734.20140502145746@my_localhost> <5363B5EE.3040201@digitalbrains.com> <5363B7FC.9050006@gmail.com> <5363D437.8030307@digitalbrains.com> <536425F2.9090008@fifthhorseman.net> <5364A0C8.6050002@gmail.com> <5365EA74.5040502@gmail.com> Message-ID: <726888940.20140504115127@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 4 May 2014 at 8:21:24 AM, in , NdK wrote: > if I use tsig I'm doing both an "identity" signature and a trust > signature. I see no way I can publicly say "I don't really know > real-world identity of this subject, but I trust him as an introducer" Generally speaking, why would the public need to know if *you* trust him as an introducer? Anyway, if you use "--ask-cert-level" when signing, and tell GnuPG when it asks "I have not checked at all," you will make a "persona" certification. I'm not sure if that works/makes sense with a trust signature, since 0x11 (persona) certifications are generally ignored in WoT calculations. > (yep, might sound strange [*], but often a pseudonym is more meaningful > than RL name, but pseudonyms aren't "good" in WoT): if I tsig his key, > I'm cerifying his pseudonym -- that I shouldn't do since it's not on any > document. Who cares about documentation, so long as you actually know that key is under the control of the entity using that name in conjunction with that email address? Documents can be faked or fraudulently obtained, and certain government agencies in some countries will issue their agents with documents in false names if fact mirrors fiction. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Is it possible to be a closet claustrophobic? -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNmG75XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p37wD/1fW028NrIGE+pomNM7tSaqEa+T7Pp7RduFt 5esiT2r7DRGTExW1yzR1JXKZbM4C/l3z4wWa8STGgbVzowPApxhmnODYAXOaYEJE nktZ/xheOVc0N6ktri3xW+OY5VnsSA2KSD8nNDbhqkD685kdmpXvFdiFn08MF3R8 SsHIE0ky =30hS -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sun May 4 12:52:36 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 04 May 2014 20:52:36 +1000 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <53660A87.4090902@dkyb.de> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> <5365E633.8050805@gmail.com> <5365FA9F.60702@sixdemonbag.org> <53660A87.4090902@dkyb.de> Message-ID: <53661BF4.9060905@sixdemonbag.org> > No, there are no good reasons. If that's an axiom in your system, then so be it. But let's not go about thinking that's something you've deduced from principles. > There is no technical problem to give different signers the same > rights to make certain signatures but make it comprehensible who > actually signed it. This is important in case an error happened or > someone intentionally did something wrong to commit a crime. It's not about technical problems. In the case of the President and his autopen, it's about legal problems. Under United States law, for a piece of legislation to take effect the President must affix his signature to the *exact same piece of paper* that the House and Senate affixed their marks to. He's not allowed to sign a copy. When the Affordable Care Act passed Congress, the President was off in France. He wanted to sign it immediately, but couldn't. The piece of paper approved by Congress was in Washington D.C., he was in France, and time was of the essence. One option would be to put the bill in an F-18 and fly it to France for the President's signature, but even then it would be a five or six hour delay. The President instead chose to have a third party issue his signature on his behalf using an autopen. You are certainly free to think this is a broken system. (Thinking the American political system is broken is the favorite pastime of many Americans.) But you have to admit this is a real-life example taken from the highest corridors of power in an environment where there are some extreme security implications of allowing third parties to execute the President's signature... ... /and yet they choose to do it./ That's the world we live in. You are, of course, free to scream that they are all idiots and fools and morons who are not listening to your divinely-inspired wisdom. Me, I'm going to grit my teeth, say, "well, let me see if I can help them not make a complete hash of things," and engage the world as it is. > And you should know that. I read your story "Two Thousand Miles to the > Promised Land". Just imagine that guy being able to make signatures > appeared to be made by you or anyone else in the company without the > recipient knowing, juts because there have been "good business > reasons". Imagine how much more damage he could have done. Did you read the part about the ex-CEO breaking into my apartment and accessing my PC? Come on, man. My *personally owned* certificates were compromised. How much worse could it really have been if he'd chosen to improperly use my *corporately owned* certificate? > And as a side note. Your answer to my other mail completely missed my > point. I was saying that you are using phrases and rhetoric rather > than arguments to try to defend your point. If you haven't been seeing arguments, then I respectfully suggest reading closer. From 2014-667rhzu3dc-lists-groups at riseup.net Sun May 4 13:03:48 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 4 May 2014 12:03:48 +0100 Subject: Signature without policy meaningless? (was Re: UI terminology for calculated validities) In-Reply-To: References: <53564380.10000@josuttis.de> <1691426.OzBBnA61Yg@inno> <926791071.20140426134332@my_localhost> <1570455.5MFBMy4FEj@inno> <333214734.20140502145746@my_localhost> <5363B5EE.3040201@digitalbrains.com> <5363B7FC.9050006@gmail.com> <5363D437.8030307@digitalbrains.com> <536425F2.9090008@fifthhorseman.net> <5364A0C8.6050002@gmail.com> Message-ID: <1466917791.20140504120348@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 3 May 2014 at 9:50:47 AM, in , Nicholas Cole wrote: > [*] I'm aware there are problems with "marginal trust" > related the fact that the requirement of three > marginally trusted signatures to confer validity may in > fact be fairly weak. The three signatures may not, in > fact, be made independently of each other (consider > three keys owned by the same person which all introduce > a third key, for example, or multiple signatures made a > single key-signing party). The default is three but you can change it to whatever number you want. I wonder what the effect might be if the default trust level "I don't know or won't say" were treated in calculations as a marginal-marginal, needing perhaps the cube or fourth power of the required number of marginals to confer validity? - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Life is a holiday. In the same way that glass is a liquid. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNmHppXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pBjID/2jKJIrNVmrXq9HnWYUot14bJuFid0v0Hbfs Gm/hooiOEcDm81FHShkm6gS5kwdSUNgBJBkVt1d2cdGQE71ZFQmbKxF8EwANxVmK Y3WIZH6iPIQnKf98QoA+JDl4uDw3prsXR5InHaI6K/ugFKg3ceVNHTeMLMBOQYas SQkw+0A+ =kFjn -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sun May 4 14:03:00 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 4 May 2014 13:03:00 +0100 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <5365FA9F.60702@sixdemonbag.org> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> <5365E633.8050805@gmail.com> <5365FA9F.60702@sixdemonbag.org> Message-ID: <1928814538.20140504130300@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 4 May 2014 at 9:30:23 AM, in , Robert J. Hansen wrote: > The autopen is a machine that replicates a physical > signature. Sounds like an updated version of the rubber-stamp signatures that used to be on some company cheques and other documents. > That's pretty much a perfect analogue to > what we're talking about here: should it be possible > for a third party to recreate your digital signature? > Should it be possible for a third party to recreate > your *physical* signature? In either case, if it can be shown that a third party has at least once done so, then everything bearing my signature is now questionable. However much somebody may trust me, they can no longer assume a particular instance of my signature was put there by me rather than the third party. (Unless the signature was witnessed by trusted individuals whose signatures have not been compromised.) > That one has been > conclusively answered 'depending on the circunstances, > yes!' time and time again. Consider the President as > an example: he may wish to sign a piece of legislation > but he's unfortunately unavailable for signatures. > Instead, he contacts a trusted secretary and orders the > secretary to autopen his signature on a document -- > said signature, since it is made on his behalf (even if > it's physically made by a machine operated by a third > person), being just as legally binding as if he himself > had written his signature. So why not just follow the standard practice of the trusted secretary signing the document himself and annotating it was signed for and on behalf of his boss? If the "autopen" signature looks just like the real deal then, unless the document is annotated to indicate it is machine-generated by , you have described something that sounds to me like an act of deception. > Are there good business reasons for third party escrow > of signing keys? Quite probably. I can see none. > If you can think of > a situation where an autopen is appropriate, whether in > business or in government, that's also a situation > where third-party escrow of signing keys would also > likely be appropriate. I cannot think of a situation where it would be appropriate to have a machine fake somebody's signature, rather than have somebody else sign on their behalf. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Learning without thought is naught; thought without learning is dangerous. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNmLIlXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pFlkEAKiB7jcHFJmKrcbIm6TdGb0cXNBsvLoIZNCc cry3q159h1sdsXgcZsZEHZU94BSSrrQC04P9fDtejdReCk6f/D4+O4MZ6NegwqXZ eySSHCOTnGbtETNzXQ92dsYdWnA48P4BK5vjpfG9c2u2ShTJzot1+tezIc4chjc+ hb7dSxqp =JMPU -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sun May 4 14:15:07 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 4 May 2014 13:15:07 +0100 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <53661BF4.9060905@sixdemonbag.org> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> <5365E633.8050805@gmail.com> <5365FA9F.60702@sixdemonbag.org> <53660A87.4090902@dkyb.de> <53661BF4.9060905@sixdemonbag.org> Message-ID: <1344716110.20140504131507@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 4 May 2014 at 11:52:36 AM, in , Robert J. Hansen wrote: > Under United States law, for a piece of legislation to > take effect the President must affix his signature to > the *exact same piece of paper* that the House and > Senate affixed their marks to. He's not allowed to > sign a copy. > When the Affordable Care Act passed Congress, the > President was off in France. [snipped] > The President instead chose to have > a third party issue his signature on his behalf using > an autopen. If the President's real signature on a copy of the document is not deemed acceptable, it seems pretty crazy to accept a machine-generated copy of the President's signature known to have been applied by a third party. But c'est la vie. - -- 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----- iPQEAQEKAF4FAlNmL1BXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p730D/3tSso/1/2MUcBqldB0XnbRUBUEBe8aryKjD V2usDIUSqZW2iDwoKX0PLz++yG7tI5uIkRwbOf+eSDiM2FCSsNy5DycLe+2eOSWM kCa4u/+/T5T5AzDOMEkQLIORWv6jcI0wmBXInPzQcQF66ugTom6eDr8xVQw5TFW3 niNw/E1j =0YdA -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sun May 4 14:28:24 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 04 May 2014 22:28:24 +1000 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <1344716110.20140504131507@my_localhost> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> <5365E633.8050805@gmail.com> <5365FA9F.60702@sixdemonbag.org> <53660A87.4090902@dkyb.de> <53661BF4.9060905@sixdemonbag.org> <1344716110.20140504131507@my_localhost> Message-ID: <53663268.5000205@sixdemonbag.org> > If the President's real signature on a copy of the document is not > deemed acceptable, it seems pretty crazy to accept a machine-generated > copy of the President's signature known to have been applied by a > third party. But c'est la vie. Welcome to government, where "pretty crazy" is about the best you can hope for. :) The laws specifying the President's signature must be on the same physical document the House and Senate approved predates the widespread use of electronic documents. Someday they'll get around to updating it, and when they do they'll probably do it badly... From rjh at sixdemonbag.org Sun May 4 14:43:14 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 04 May 2014 22:43:14 +1000 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <1928814538.20140504130300@my_localhost> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> <5365E633.8050805@gmail.com> <5365FA9F.60702@sixdemonbag.org> <1928814538.20140504130300@my_localhost> Message-ID: <536635E2.4010709@sixdemonbag.org> > So why not just follow the standard practice of the trusted secretary > signing the document himself and annotating it was signed for and on > behalf of his boss? Because the law says the document must bear the President's signature, not that of a functionary acting on the President's direction. > If the "autopen" signature looks just like the real deal then, unless > the document is annotated to indicate it is machine-generated by > , you have described something that sounds to me like an act of > deception. Deception? In politics? Surely you jest. That could /never/ happen... > I cannot think of a situation where it would be appropriate to have a > machine fake somebody's signature, rather than have somebody else sign > on their behalf. This original thread started off with Daniel Kahn Gillmor saying there were no use cases for a third party holding signing keys. Well, there *are* use cases, as evidenced by the President's signing of the Affordable Care Act. And every time someone says "well, he really shouldn't," I don't know how to read that except as an admission of "yes, there is a use case, but no, I don't like it." In which case you're in full agreement with me and you're just in denial about it. Yes, there is a use case, and no, I don't like it, either... but that doesn't change the fact there's a use case! From ndk.clanbo at gmail.com Sun May 4 15:05:34 2014 From: ndk.clanbo at gmail.com (NdK) Date: Sun, 04 May 2014 15:05:34 +0200 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <536635E2.4010709@sixdemonbag.org> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> <5365E633.8050805@gmail.com> <5365FA9F.60702@sixdemonbag.org> <1928814538.20140504130300@my_localhost> <536635E2.4010709@sixdemonbag.org> Message-ID: <53663B1E.1030001@gmail.com> Il 04/05/2014 14:43, Robert J. Hansen ha scritto: > Because the law says the document must bear the President's signature, > not that of a functionary acting on the President's direction. Just 'cause the law lays *way* behind technology: when it was created, they couldn't think of "autosign" machines, figure digital signatures! > Deception? In politics? Surely you jest. That could /never/ happen... ROFLASTC :) BYtE, Diego. From dkg at fifthhorseman.net Sat May 3 22:15:13 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 03 May 2014 16:15:13 -0400 Subject: UI terminology for calculated validities In-Reply-To: <20140503195655.5c2dfe81@cerberus.dumain.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> <535A27BC.40602@digitalbrains.com> <20140503135341.4ca90615@cerberus.dumain.com> <1202141502.20140503172856@my_localhost> <20140503195655.5c2dfe81@cerberus.dumain.com> Message-ID: <53654E51.5010303@fifthhorseman.net> On 05/03/2014 02:56 PM, William Hay wrote: > Once you start doing things publicly one would need to pick a > certification level in order to inter-operate with the existing WoT. > It isn't clear to me that there is a good default. There is a good default for certifying someone else's key. the default is "generic certification" (signature type 0x10), which is the same as the "I will not answer. (default)" selection in the "gpg --ask-cert-level" interface. In my keyring of a little over 2000 keys, the overwhelming majority of all User ID certifications that aren't self-sigs use this signature type. This default interoperates just fine with the existing WoT. --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 Mon May 5 07:05:51 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 05 May 2014 07:05:51 +0200 Subject: improving validity calculation: external program Message-ID: <2871177.1mkj8MGvCz@inno> Hello, from time to time when changes to GnuPG's behaviour (about validity and trust) are suggested, Werner responds kind of: "No, that should be done on top of GnuPG." This attitude makes sense but in the current situation I would ask: How? How shall that be done on top of GnuPG without causing a huge mess of adaption need in the higher layer applications? Thus I would like to suggest that ? similar to gpg-agent's option "pinentry-program" ? an option is added which disables gpg's internal handling of --check-trustdb / --update-trustdb and has the configured external program be called for that. This would more or less be a modified version of --import-ownertrust. This way it would become easy to test and offer other validity calculation strategies. Simple cases: a) The WoT could be easily disabled for newbies by configuring a validity calculator which ignores it. b) Ignore level 0 certifications. Less simple case: a) The calculator could be configured to treat different keys as one (because the owner is the same); we recently discussed this need. I don't want to distract you from the general idea by offering complicated suggestions which will never even come close to concensus... ;-) A nice extension would be to define an output format (or database format for gpg to read the data from) so that a) this calculator can show for each certification if and how much it contributes to the validity of another key (or: UID); IIRC this is currently not possible b) levels for security and authenticity could be added. Today we have "valid" and "invalid". But the real world is not a dichotomy: Different kinds of information have different requirements for both security and authenticity (or the combination of both). We must map this spectrum to key selection somehow (or at least create the possibility for others to easily do so). 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 martin-gnupg-users at dkyb.de Mon May 5 10:41:50 2014 From: martin-gnupg-users at dkyb.de (Martin Behrendt) Date: Mon, 05 May 2014 10:41:50 +0200 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <53661BF4.9060905@sixdemonbag.org> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> <5365E633.8050805@gmail.com> <5365FA9F.60702@sixdemonbag.org> <53660A87.4090902@dkyb.de> <53661BF4.9060905@sixdemonbag.org> Message-ID: <53674ECE.3060405@dkyb.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 04.05.2014 12:52, schrieb Robert J. Hansen: >> No, there are no good reasons. > > If that's an axiom in your system, then so be it. But let's not > go about thinking that's something you've deduced from principles. > Well I haven't heard any so far. > It's not about technical problems. In the case of the President > and his autopen, it's about legal problems. Under United States > law, for a piece of legislation to take effect the President must > affix his signature to the *exact same piece of paper* that the > House and Senate affixed their marks to. He's not allowed to sign > a copy. > So, let's make an insecure system instead of maybe changing the law? Or maybe changing your priority as a president. There is more than one road that leads to Rom. Besides, *he* needs to sign the original document. So it is okay to make it appear he signed it originally by himself but he has not? That is okay and within the law? For this to be within the law, I would expect they would need to write it into the law. So they also could write other stuff in the law, e.g to add the information who operated the autopen and that an autopen was used. > You are certainly free to think this is a broken system. (Thinking > the American political system is broken is the favorite pastime of > many Americans.) But you have to admit this is a real-life example > taken from the highest corridors of power in an environment where > there are some extreme security implications of allowing third > parties to execute the President's signature... > > ... /and yet they choose to do it./ > This is, again, rhetoric and not an argument. I explained that before. > That's the world we live in. You are, of course, free to scream > that they are all idiots and fools and morons who are not listening > to your divinely-inspired wisdom. Me, I'm going to grit my teeth, > say, "well, let me see if I can help them not make a complete hash > of things," and engage the world as it is. > No I'm not screaming. It has nothing to do with me having more wisdom than others. I just want to learn from the past and put 10% more energy in having a more secure system. I'm just saying that there are better ways to solve the same problem while you defend your position with phrases and rhetoric and not with arguments. Let me exaggerate of what it sounds to me, what you are saying: There is a nuclear power plant build next to a volcano on the shore of an ocean and just on top of the boundary points of two tectonic plates. I'm saying. Hey guys thats stupid, shouldn't we build wind engines or wave power machines here instead and shut down the nuclear power plant? The volcano is active, tsunamis do happen here and let's not forget about the earthquakes. And you are saying: "You are, of cause, free to scream that they are all idiots and fools and morons who are not listening to your divinely-inspired wisdom. Me I'm going to grit my teeth, say, "well, let me see if I can help them not make a complete hash of things," and engage the world as it is." It is valid to say: Yes this is stupid but we need to secure the system on a short term perspective as it is but we need to do something better on the long run. But from what you are saying and how you are behaving I only get: The world is stupid. I won't change it but I will help to make the outcome of the stupid things not have such a bad effect. But I will defend the overall stupidity behind it because the stupidity is done and that is how the world is. And there are people saying "We are not going to change it." > Did you read the part about the ex-CEO breaking into my apartment > and accessing my PC? Come on, man. My *personally owned* > certificates were compromised. How much worse could it really have > been if he'd chosen to improperly use my *corporately owned* > certificate? > Yes, I said I read the story. And ones you discovered your personally owned certificates were compromised you revoked them, made new ones and you were aware of the fact that they might be misused and could be more cautions over a period of time. But your corporate certificates could have been misused from the beginning without stealing them first from you by design of the system you defend. Can you see the difference? >> And as a side note. Your answer to my other mail completely >> missed my point. I was saying that you are using phrases and >> rhetoric rather than arguments to try to defend your point. > > If you haven't been seeing arguments, then I respectfully suggest > reading closer. > I didn't say you are *only* using phrases and rhetoric. I admit you are also using badly designed examples which most of the time, if you think them through, are not helping your point. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEAREKAAYFAlNnTs4ACgkQ/6vdZgk46shx0wCePfgKmiv3wpOQl/n8bnR7WhEA puYAn0UWyjiplyGQUoIrkdqY5/dQV3cs =BxdB -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Mon May 5 12:55:21 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 05 May 2014 20:55:21 +1000 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <53674ECE.3060405@dkyb.de> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> <5365E633.8050805@gmail.com> <5365FA9F.60702@sixdemonbag.org> <53660A87.4090902@dkyb.de> <53661BF4.9060905@sixdemonbag.org> <53674ECE.3060405@dkyb.de> Message-ID: <53676E19.8060206@sixdemonbag.org> > So, let's make an insecure system instead of maybe changing the law? Feel free to push for it. Optimistically, you might be able to get it done in five years. And in the interim time, you need to have a method to deal with the world as it is, because the world doesn't care what you think it should be. > Or maybe changing your priority as a president. I don't think you'll have much luck changing the President's priorities. > This is, again, rhetoric and not an argument. I explained that before. As I explained, you are choosing not to recognize the argument. Point blank: /the world does not care what you think./ Nor what I think, for that matter. The world cares about its established procedures and The Way Things Have Always Been Done. If you try very hard, you may be able to make small amounts of headway in changing small things. I encourage this: choose wisely where you will expend your efforts. But that will still leave vast parts of the world that will not be changed, and you have to have some plan for dealing with those parts other than to tsk-tsk and say, "well, they shouldn't be doing that." By all means, pick an important part of the world that needs changing and work on it. But the rest of the world will keep on going about its merry way, not giving a damn what you -- or I -- think of it. Should third-party signatures on behalf of another exist? That's an irrelevant question. What's relevant is they *do* exist. If you want to commit your life to changing this, feel free: go with God and I wish you luck. But otherwise, deal with the world as it is, because the world genuinely does not care what you think of it. Or what I think of it, for that matter. This is the last I'm going to say on the matter: if I'm not abundantly clear by this point, I doubt I'll be any more clear in the future. From martin-gnupg-users at dkyb.de Mon May 5 14:01:13 2014 From: martin-gnupg-users at dkyb.de (Martin Behrendt) Date: Mon, 05 May 2014 14:01:13 +0200 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <53676E19.8060206@sixdemonbag.org> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> <53644C31.8080206@fifthhorseman.net> <53645BF1.9020703@sixdemonbag.org> <5365E633.8050805@gmail.com> <5365FA9F.60702@sixdemonbag.org> <53660A87.4090902@dkyb.de> <53661BF4.9060905@sixdemonbag.org> <53674ECE.3060405@dkyb.de> <53676E19.8060206@sixdemonbag.org> Message-ID: <53677D89.9040008@dkyb.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 05.05.2014 12:55, schrieb Robert J. Hansen: > >> This is, again, rhetoric and not an argument. I explained that >> before. > > As I explained, you are choosing not to recognize the argument. > You honestly seem to think that "We are doing $A, so it is okay to do keep on doing $A instead of working towards doing $B which is way smarter to do." is an argument. This gives me an explanation why you didn't listen to your doubts in the mentioned story. Maybe you got convinced to keep on going by similar "arguments"? > Point blank: /the world does not care what you think./ Nor what I > think, for that matter. The world cares about its established > procedures and The Way Things Have Always Been Done. If you try > very hard, you may be able to make small amounts of headway in > changing small things. I encourage this: choose wisely where you > will expend your efforts. But that will still leave vast parts of > the world that will not be changed, and you have to have some plan > for dealing with those parts other than to tsk-tsk and say, "well, > they shouldn't be doing that." > > By all means, pick an important part of the world that needs > changing and work on it. But the rest of the world will keep on > going about its merry way, not giving a damn what you -- or I -- > think of it. > Can you see the fundamental difference for the development of our society in defending stupidity; and working to reduce the effect of stupidity but *at least* pointing out or mentioning smartness? Change doesn't come by one person. It comes by enough people speaking about it. You have to start somewhere. And if you don't feel like not to do the least bit, to improve our society. Well than maybe you also shouldn't make an effort against it. Especially not with senseless rhetoric which has been used to discriminate against people and worse and justifying for others not to do something about it. It is completely valid to argue!!!: $A is easy, simple, takes no effort and it works. These can be good arguments to not to change something in place. And explaining to change to $B takes to much resources and thats why we are not doing is, is also valid. Than you can have a discussion. But the other rhetoric is just wrong. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEAREKAAYFAlNnfYkACgkQ/6vdZgk46sg6GgCcC9C9X7ycg7xZ70LA2j3DxRqh RAEAoJvuuWcHUsjDaBtKQ7tpyoIoryss =iuuv -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Mon May 5 16:21:20 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 05 May 2014 10:21:20 -0400 Subject: typo on http://gpg4win.org/download.html Message-ID: <53679E60.2010304@fifthhorseman.net> hi gnupg folks-- https://gpg4win.org/download.html says: Please note: Does not use portable applications - especially crypto applications - on potentially infected systems. I think you want to change "Does" to "Do" to turn the note into an imperative: Please note: Do not use portable applications - especially crypto applications - on potentially infected systems. If the gpg4win web site is under revision control someplace, i'd be happy to send a diff for future edits like this. If so, please let know where i should look for it. Thanks for making gpg4win available for people stuck on Windows. 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 subscribernamegoeshere+201207 at gmail.com Mon May 5 15:28:13 2014 From: subscribernamegoeshere+201207 at gmail.com (sngh) Date: Mon, 5 May 2014 15:28:13 +0200 Subject: Newbie Q, simple shared-use single-address email workflow with pgp key (small company or small # of people in a group) Message-ID: Newbie Q, simple shared-use single-address email workflow with pgp key (small company or small # of people in a group) Good day pgp/gnupg participants. I am looking for answers to maybe a common setup of email on a single email address, residing on a single but shared machine (windows), that is being operated by a smallish group of multiple people (e.g. small group, foundation, company, business), that needs to do secured emails to and from the outside world (e.g. mailing privacy sentivie emails, documents). Was thinking about using Thunderbird on Windows with GnuPG extension for it (enigmail). How would I create the private key and key-ring, also to protect it somewhat from being spread to the outside by mostly unknowing mis-use of the windows machine or by accident of the non-tech savvy users of that machine and so on? Basic task is that the single email address needs to be able to send and receive encrypted emails. As most of the world out there are familiar with emails and email addresses, using a pgp public key with the currently still low number of other email partners of this address would be a way to master this task? Any hints on securing or handling the private key (keyring) and other hints to this setup and scenario? Omitting the passphrase alltogether? Any way of making it easy for the windows machine's users to not mess too much with the pgp level of things there? Can the enigmail layer be simplified to really easy levels as to simple buttons if to encrypt or not to encrypt the email and similar? I guess there is no simple solution in dealing with all those public keys of the remote senders and recipients though. Thanks for some hints and experience. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.chepied at gmail.com Mon May 5 17:40:50 2014 From: cedric.chepied at gmail.com (=?UTF-8?B?Q8OpZHJpYyBDaMOpcGllZA==?=) Date: Mon, 05 May 2014 17:40:50 +0200 Subject: updatestartuptty and gpg key Message-ID: <5367b104.8276c20a.5885.0cee@mx.google.com> Hi, I'm trying to start gpg-agent with systemd and I'm having some troubles. I don't know if this is a bug or if I don't know how to use agent. When I start another service with systemd that uses gpg-agent, I can't enter my passphrase because gpg-agent don't know "where" it can ask me to enter it. When I start an X session, I use 'echo UPDATESTARTUPTTY | gpg-connect-agent' and it's a little better. Services using ssh keys can ask me the passphrase. But services using gpg key for file decryption can't. When I start a tty console. I use 'gpg-connect-agent updatestartuptty /bye' (I can't remember why I'm not using the same command). When I start a service using ssh key, the "window" asking my passphrase is displayed but it don't get focus, my tty is not usable and I can't talk to agent anymore. Nothing happens when I try to decrypt a file in an other service. How can I tell gpg-agent on which tty/X display it can ask me passphrases? Here are my two services: ---8<------------------------------------------------------- [Unit] Description=Test ssh After=gpg-agent.service [Service] ExecStart=/usr/sbin/scp distant-machine:/tmp/plop /tmp ---8<------------------------------------------------------- And ---8<------------------------------------------------------- [Unit] Description=Test decrypt After=gpg-agent.service [Service] ExecStart=/usr/sbin/gpg -d /home/user/.authinfo.gpg ---8<------------------------------------------------------- Here is my gpg-agent service: ---8<------------------------------------------------------- [Unit] Description=GnuPG private key agent IgnoreOnIsolate=true [Service] Type=forking Environment=GPG_ENVFILE=%h/.gnupg/gpg-agent.env ExecStart=/usr/bin/gpg-agent --daemon --enable-ssh-support --use-standard-socket --write-env-file ${GPG_ENVFILE} ExecStartPost=/bin/sh -c "xargs systemctl --user set-environment < ${GPG_ENVFILE}" ExecStopPost=/bin/rm ${GPG_ENVFILE} ExecReload=/bin/kill -HUP $MAINPID Restart=on-abort [Install] WantedBy=mystuff.target ---8<------------------------------------------------------- Regards, -- C?dric Ch?pied From kristian.fiskerstrand at sumptuouscapital.com Mon May 5 23:46:06 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 05 May 2014 23:46:06 +0200 Subject: [Announcement] SKS 1.1.5 Released Message-ID: <5368069E.4080800@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, We are pleased to announce the availability of a new stable SKS release: Version 1.1.5. SKS is an OpenPGP keyserver whose goal is to provide easy to deploy, decentralized, and highly reliable synchronization. That means that a key submitted to one SKS server will quickly be distributed to all key servers, and even wildly out-of-date servers, or servers that experience spotty connectivity, can fully synchronize with rest of the system. What's New in 1.1.5 ==================== - Fixes for machine-readable indices. Key expiration times are now read from self-signatures on the key's UIDs. In addition, instead of 8-digit key IDs, index entries now return the most specific key ID possible: 16-digit key ID for V3 keys, and the full fingerprint for V4 keys. - Add metadata information (number of keys, number of files, checksums, etc) to key dump. This allows for information on the key dump ahead of download/import, and direct verification of checksums using md5sum -c . - Replaced occurrances of the deprecated operator 'or' with '||' (BB issue #2) - Upgraded to cryptlib-1.7 and own changes are now packaged as separate patches that is installed during 'make'. Added the SHA-3 algorithm, Keccak - Option max_matches was setting max_internal_matches. Fixed (BB issue #4) - op=hget now supports option=mr for completeness (BB issue #17) - Add CORS header to web server responses. Allows JavaScript code to interact with keyservers, for example the OpenPGP.js project. - Change the default hkp_address and recon_address to making the default configuration support IPv6. (Requires OCaml 3.11.0 or newer) - Only use '-warn-error A' if the source is marked as development as per the version suffix (+) (part of BB Issue #2) - Reduce logging verbosity for debug level lower than 6 for (i) bad requests, and (ii) no results found (removal of HTTP headers in log) (BB Issue #13) - Add additional OIDs for ECC RFC6637 style implementations (brainpool and secp256k1) (BB Issue #25) and fix issue for 32 bit arches. - Fix a non-persistent cross-site scripting possibility resulting from improper input sanitation before writing to client. (BB Issue #26 | CVE-2014-3207) Note when upgrading from earlier versions of SKS ==================== The default values for pagesize settings changed in SKS 1.1.4. To continue using an existing DB from earlier versions without rebuilding, explicit settings have to be added to the sksconf file. pagesize: 4 ptree_pagesize: 1 Getting the Software ==================== SKS can be downloaded from https://bitbucket.org/skskeyserver/sks-keyserver Prerequisites ==================== There are a few prerequisites to building this code. You need: * ocaml-3.11.0 or later (ocaml-3.12.x is recommended). Get it from * Berkeley DB version 4.6.* or later, whereby 4.8 or later is recommended. You can find the appropriate versions at * GNU Make and a C compiler (e.g gcc) Verifying the integrity of the download ==================== Releases of SKS are signed using the SKS Keyserver Signing Key available on public keyservers with the KeyID 0x41259773973A612A and has a fingerprint of C90E F143 0B3A C0DF D00E 6EA5 4125 9773 973A 612A. Using GnuPG, verification can be accomplished by, first, retrieving the signing key using gpg --keyserver pool.sks-keyservers.net --recv-key 0x41259773973A612A followed by verifying that you have the correct key gpg --keyid-format long --fingerprint 0x41259773973A612A should produce: pub 4096R/41259773973A612A 2012-06-27 Key fingerprint = C90E F143 0B3A C0DF D00E 6EA5 4125 9773 973A 612A A check should also be made that the key is signed by trustworthy other keys; gpg --list-sigs 0x41259773973A612A and the fingerprint should be verified through other trustworthy sources. Once you are certain that you have the correct key downloaded, you can create a local signature, in order to remember that you have verified the key. gpg --lsign-key 0x41259773973A612A Finally; verifying the downloaded file can be done using gpg --keyid-format long --verify sks-x.y.z.tgz.asc The resulting output should be similar to gpg: Signature made Wed Jun 27 12:52:39 2012 CEST gpg: using RSA key 41259773973A612A gpg: Good signature from "SKS Keyserver Signing Key" Checksums for sks-1.1.5.tgz SHA1: a353426e99de3fb02bf93b953f574335a9f2a590 SHA256: 92a7f113f0ba7a28d51d7ced60a984d042d8524c651dc3fcafe9d11cc32981a0 Thanks ==================== We have to thank all the people who helped with this release, by discussions on the mailing list, submitting patches, or opening issues for items that needed our attention. Happy Hacking, The SKS Team (Yaron, John, Kristian, Phil, and the other contributors) - -- - ---------------------------- 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 - ---------------------------- "Excellence is not a singular act but a habit. You are what you do repeatedly."| (Shaquille O'Neal) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTaAaeAAoJEPw7F94F4Tag0MEP/Aqc6K+39KDp8JUC+sQK8HPA 1890fKF4MccqHBhMmfNSqIZmsY82qIEjrX2KMjn52nAnbCf8DN9rJEcM/3mpbJpG uB52x73vfQRGyYB/AYbvZF/T3Xliv5VU69zvvIrGU1l8CS1o74C5wQsMdz8HGJnj Ec5ES/9udnZV70Zx2D3SX7V6LNfTRtCRL6Rq1xbsnHi+VIHvSAqA+SspUNlyCCCj QK8HG8aehgrx9hllzJbofVKRYyPtAoWuNped23qbHAvhZcdmLG8cfLez2PEigSFn ZfJPD/AeXTpWo42KGz5FTSA3VS7kpERXxiF/8wEdrtgdyMKnbvmIVEWe4/vCsaKS 31LflE3j7Dwtt2yCwWd6J+G/k5dD4JX9qp1ZPmmNTbwqclfZt+mxoBDFl0zkHjeA vNZAT8iAQJeVe/MUzsVbAJihkwBrSttGmGRtG2tFsWorCkKvUdnQT0IsztkmyYUO ObdwPeZRR/LNm8xgBjRB2fW/gzWAIB6uEjpp9jfZmCiKBv9Wgk7l5mtTghP21Oa7 UoArnIdOvdWOzw6uL5MkrEAReD2kqD6sesxUer2I7nqBQqUwpASjD2HSp6rE7Ndy chIT1RAD2gvQlm8gYKnvZ+Z/WRk7okZeMSKpjSYfXX8yKRXjHS/y7M2r36w6+n8V OcBDyGo60Q/GOXM+Ev2v =CnUB -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Tue May 6 05:08:34 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 5 May 2014 23:08:34 -0400 Subject: improving validity calculation: external program In-Reply-To: <2871177.1mkj8MGvCz@inno> References: <2871177.1mkj8MGvCz@inno> Message-ID: <1EC6FF57-3267-4382-9021-194CD9AACDE4@jabberwocky.com> On May 5, 2014, at 1:05 AM, Hauke Laging wrote: > Hello, > > from time to time when changes to GnuPG's behaviour (about validity and > trust) are suggested, Werner responds kind of: "No, that should be done > on top of GnuPG." This attitude makes sense but in the current situation > I would ask: How? How shall that be done on top of GnuPG without causing > a huge mess of adaption need in the higher layer applications? > > Thus I would like to suggest that ? similar to gpg-agent's option > "pinentry-program" ? an option is added which disables gpg's internal > handling of --check-trustdb / --update-trustdb and has the configured > external program be called for that. This would more or less be a > modified version of --import-ownertrust. Believe it or not, this almost exists. Way back in 2003, I added the concept of an "external" trustdb. The intent was exactly for what you mention: to allow people to make up and experiment with their own ideas in trust handling without having to have GPG support them all directly. The trustdb in GPG is essentially a frozen image of what ownertrust you've set on which keys, and which users IDs are valid, and to what degree (partial, full, etc). When you run --check-trustdb and/or --update-trustdb, you're rebuilding the trustdb image. An external trustdb is just like any other trustdb, except that GPG follows it directly, and does no trust calculations of its own. So GPG is capable of reading this special trustdb that can encode any behavior you like. The catch is that I never had time to write a generic trustdb "compiler" where you could feed it the key/user ID/validity relationships you desire, and have it spit out the resulting trustdb. A reasonably good programmer should be able to write one in short order though. You just need to follow the format used in tdbio.c, and tag it as TM_EXTERNAL so GPG knows to treat it as special and refuse to run check-trustdb or update-trustdb on it. Note that while you may choose to use a nonstandard notion of trust and/or validity, that of course only applies to you. Just like the standard trust models, just because A sees B's key as valid, it doesn't necessarily imply that B sees A's key as valid. David From kristian.fiskerstrand at sumptuouscapital.com Tue May 6 11:08:24 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 06 May 2014 11:08:24 +0200 Subject: Changes to sks-keyservers.net pools Message-ID: <5368A688.60005@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear lists, Following the release of SKS 1.1.5[0] the following changes will be made to the pools of sks-keyservers.net subset.pool.sks-keyservers.net has been set to a minimum requirement of SKS 1.1.5 with immediate effect. Due to CVE-2014-3207[1] I want to bump hkps.pool.sks-keyservers.net to a requirement of 1.1.5 as this can potentially be in another security context / zone, however I'm giving this a grace period of (at least) 45-60 days to allow server administrators to upgrade their servers. I'm not making any changes to the main pool at this point. References: [0] http://lists.nongnu.org/archive/html/sks-devel/2014-05/msg00026.html [1] http://www.openwall.com/lists/oss-security/2014/05/01/16 - -- - ---------------------------- 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 - ---------------------------- "Statistics are like a bikini. What they reveal is suggestive, but what they conceal is vital." (Aaron Levenstein) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTaKaIAAoJEPw7F94F4Tags08P/RQLNnrKbAWZGAj6clPjEPd9 Re88zQZyoZIxvMCxzY8szanpM0qCjO9Qet/CJnEuhAYYuGLQb4BhtU8Ps4/FXQ/F Gns/8x2urA2Suw1wDjoo47AWsfx4W6AJh9Nr6ESZB42wk7pZfjHihDjAGEXIOrsc 9R5BJggH0HY1/GNUrlLLPNQvaJGWE2weGdI8b9+uR219HnjgBB+K2XK4z8G8QRqB OC7/nPkyYNGivI+K4lIqtDSwILXQkFsOPmsg0N6a0tLpJOFzLSvzksEKPyOsJCHo 9dQttBXPGj+GIhdeexs7WNPeYOwzbVEsu5Lrsbb+oEcQ/wik8awQo3Zizz3ArkOs N2CnIf2Zob2tRsycVVDs24QpwmS2zJKbt7Ziy1lyTLWZYq330fC0BlyQ1V/+1SRc oWi2WUBLBW41W1ZjXHcNeUCo8A+XOre1uU2jYY/r2w2tANs1LIobdNNc2+iPb7uD MhSugCuRA5oDu8KcXlEOIMinciPj+X6iRtZKFqiemmOkczjOBuii+F3Ae3p6YJM3 68wFn9ya8+ZPDC12zU+hcOrhiKS7JjW4crodb7BW/WxqWsSywL6JHeIwSSCEhURz 5fWj37X/GnOl5yO38r9WrE90yM+3KToHgZ44vubfkmfVwAanhMF3TMhQu3yTXZiT Zz+xYWS5YoI9TeFG6c+f =hzHF -----END PGP SIGNATURE----- From ben at adversary.org Tue May 6 11:58:57 2014 From: ben at adversary.org (Ben McGinnes) Date: Tue, 06 May 2014 19:58:57 +1000 Subject: Managing Subkeys for Professional and Personal UIDs In-Reply-To: <53644732.8090302@sixdemonbag.org> References: <535E9F76.8090106@fifthhorseman.net> <53641618.8050806@gmail.com> <536419BE.7090403@fifthhorseman.net> <53644732.8090302@sixdemonbag.org> Message-ID: <5368B261.5020306@adversary.org> On 3/05/14 11:32 AM, Robert J. Hansen wrote: > > Seems perfectly reasonable for me for the company to issue a > signature on a purchase order using your *corporate-owned*, > *corporate-controlled* certificate, which was always issued for the > needs of the corporation. > > Just because a certificate has your name on it doesn't make it yours > and doesn't mean you have a legal or moral right to control how it's > used. Just like a credit card; it might have your name on it, but the fine print says it belongs to the bank (or other issuing financial institution). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From benfell at parts-unknown.org Tue May 6 05:19:25 2014 From: benfell at parts-unknown.org (benfell at parts-unknown.org) Date: Mon, 05 May 2014 20:19:25 -0700 Subject: [Sks-devel] [Announcement] SKS 1.1.5 Released In-Reply-To: <5368069E.4080800@sumptuouscapital.com> References: <5368069E.4080800@sumptuouscapital.com> Message-ID: <20140506031925.DCD3012C105E@mail.parts-unknown.org> Kristian Fiskerstrand writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello, > > We are pleased to announce the availability of a new stable SKS > release: Version 1.1.5. I am very, very new to the whole rpmbuild thing, but I've managed to roll a Fedora 20 RPM that appears to be working on my system (absolutely no guarantees anywhere else). I've assigned it a release number of 0 which I think/hope will allow a first official Fedora release of the package to upgrade it. In this, I *did* fix the init files so there is no leading space on the #! line. The RPMs aren't signed in the normal way within the RPMs but rather with gpg-generated signatures (you'll see when you ; I haven't figured that bit out. Also, for some reason, rpmbuild -ba didn't produce a source RPM (perhaps I misunderstood the man page?), at least that I can find. I used the patches from the latest Fedora 1.1.4 source RPM and adapted its spec file to use a source downloaded from the official site. They are available at https://disunitedstates.org/rpm/ -- David Benfell See https://parts-unknown.org/node/2 if you do not understand the attachment. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From benfell at parts-unknown.org Tue May 6 11:17:07 2014 From: benfell at parts-unknown.org (benfell at parts-unknown.org) Date: Tue, 06 May 2014 02:17:07 -0700 Subject: [Sks-devel] [Announcement] SKS 1.1.5 Released In-Reply-To: <20140506031925.DCD3012C105E@mail.parts-unknown.org> References: <5368069E.4080800@sumptuouscapital.com> <20140506031925.DCD3012C105E@mail.parts-unknown.org> Message-ID: <20140506091707.CF85212C1071@mail.parts-unknown.org> benfell at parts-unknown.org writes: > > The RPMs aren't signed in the normal way within the RPMs but rather with > gpg-generated signatures (you'll see when you ; I haven't figured that bit > out. These RPMs should now be correctly signed with my usual key (0x1236602B). -- David Benfell See https://parts-unknown.org/node/2 if you do not understand the attachment. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From wk at gnupg.org Tue May 6 16:35:41 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 May 2014 16:35:41 +0200 Subject: typo on http://gpg4win.org/download.html In-Reply-To: <53679E60.2010304@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 05 May 2014 10:21:20 -0400") References: <53679E60.2010304@fifthhorseman.net> Message-ID: <87zjiv6kle.fsf@vigenere.g10code.de> On Mon, 5 May 2014 16:21, dkg at fifthhorseman.net said: > I think you want to change "Does" to "Do" to turn the note into an > imperative: Sure. I'll fix it. > > Please note: Do not use portable applications - especially crypto > applications - on potentially infected systems. > > If the gpg4win web site is under revision control someplace, i'd be > happy to send a diff for future edits like this. If so, please let know > where i should look for it. http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;h=refs/heads/website Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From subscribernamegoeshere at gmail.com Tue May 6 19:10:28 2014 From: subscribernamegoeshere at gmail.com (subscriber name) Date: Tue, 6 May 2014 19:10:28 +0200 Subject: Newbie Q, simple shared-use single-address email workflow with pgp key (small company or small # of people in a group) Message-ID: Newbie Q, simple shared-use single-address email workflow with pgp key (small company or small # of people in a group) Good day pgp/gnupg participants. I am looking for answers to maybe a common setup of email on a single email address, residing on a single but shared machine (windows), that is being operated by a smallish group of multiple people (e.g. small group, foundation, company, business), that needs to do secured emails to and from the outside world (e.g. mailing privacy sentivie emails, documents). Was thinking about using Thunderbird on Windows with GnuPG extension for it (enigmail). How would I create the private key and key-ring, also to protect it somewhat from being spread to the outside by mostly unknowing mis-use of the windows machine or by accident of the non-tech savvy users of that machine and so on? Basic task is that the single email address needs to be able to send and receive encrypted emails. As most of the world out there are familiar with emails and email addresses, using a pgp public key with the currently still low number of other email partners of this address would be a way to master this task? Any hints on securing or handling the private key (keyring) and other hints to this setup and scenario? Omitting the passphrase alltogether? Any way of making it easy for the windows machine's users to not mess too much with the pgp level of things there? Can the enigmail layer be simplified to really easy levels as to simple buttons if to encrypt or not to encrypt the email and similar? I guess there is no simple solution in dealing with all those public keys of the remote senders and recipients though. Thanks for some hints and experience. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas.cole at gmail.com Wed May 7 19:23:34 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed, 7 May 2014 18:23:34 +0100 Subject: Trust Signature REs Message-ID: If I tell gnupg to make a trust signature limited to the domain: nowhere.com it converts this into <[^>]+[@.]nowhere\\x5c.com>$ I see the logic. However, if I am trying to copy this re from one signature to another, and I tell gnupg to limit a trust signature to " <[^>]+[@.]nowhere\\x5c.com>$ ", it does not recognise this as a regular expression, but instead converts it to " <[^>]+[@.]\x5c<\x5c[\x5c^\x5c>\x5c]\x5c+\x5c[\x5c@\x5c.\x5c]nowhere\x5c\x5cx5c\x5c.com\x5c>\x5c$>$ " Is there any way to tell gnupg that I am actually entering a raw re and do not wish it to do any conversion? Best wishes, N. From cloos at jhcloos.com Wed May 7 22:38:43 2014 From: cloos at jhcloos.com (James Cloos) Date: Wed, 07 May 2014 16:38:43 -0400 Subject: Access to www.gnupg.org only via TLS In-Reply-To: <87k3a7gt7q.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 30 Apr 2014 09:41:13 +0200") References: <87k3a7gt7q.fsf@vigenere.g10code.de> Message-ID: Out of curiosity, why a 307 temp redirect rather than a 301 perm redirect? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From wk at gnupg.org Thu May 8 14:20:30 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 May 2014 14:20:30 +0200 Subject: Access to www.gnupg.org only via TLS In-Reply-To: (James Cloos's message of "Wed, 07 May 2014 16:38:43 -0400") References: <87k3a7gt7q.fsf@vigenere.g10code.de> Message-ID: <87d2fo31ip.fsf@vigenere.g10code.de> On Wed, 7 May 2014 22:38, cloos at jhcloos.com said: > Out of curiosity, why a 307 temp redirect rather than a 301 perm redirect? I first want to check whether the box is fast enough for all TLS. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From florian at florian-wolters.de Thu May 8 23:46:51 2014 From: florian at florian-wolters.de (Florian Wolters) Date: Thu, 08 May 2014 23:46:51 +0200 Subject: GPG V2.0 Smartcard and Nautilus SFTP Sessions Message-ID: <536BFB4B.8080100@florian-wolters.de> Hi @ll, maybe a little off topic, but I wonder how to get nautilus as a file manager to authenticate a SFTP connection with a smartcard. Has anyone a working setup on this? I replaced the gnome-keyring daemons with gpg-agent in order to get that working on the console. File encryption in nautilus works and correctly asks for the smartcard PIN. But when I try to connect to my SFTP server it throws some error message saying that I do not have the correct permissions to access that location. Any help greatly appreciated. Best 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 faramir.cl at gmail.com Fri May 9 05:00:49 2014 From: faramir.cl at gmail.com (Faramir) Date: Thu, 08 May 2014 23:00:49 -0400 Subject: a bit OT: pgpdump binaries? Message-ID: <536C44E1.9090807@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I hope this is not much off-topic. I was looking for pgpdump binaries, and the one I have is for version 0.20, I downloaded it on september 2011. But in the website, the current version is 0.28, from june 2013. Does somebody know where I can get a binary file for windows? Maybe one day I'll learn to compile stuff, but for now I'd rather use a binary. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTbEThAAoJEMV4f6PvczxAFKkH/2kFTJ/M5PkmwzjHG2QxVLMB 3JFtvA8GjgmT3Xjhzn1A9jkCPxKrYzfwNf97yU7vjHRNZikWH062XptRcXsRU536 PeR7xs1/h+2uOL2CUXlmFmRiiNbMuDIsa0QLD57LP6JnYGf7i3KfI0zqSK9EFL7F GgQE+4U13fxPHgA9GIKn/Lg0ERUbfbNEBDp5pWRPie0QsXl4/DVArXLHnpe8fsdD 6+vQlT5fT2zyYluEDaIs8VGjU9mH2FNSzzUTAgZpgCj9Y8MqGnLw7oqn414cKhxQ jvdtd8qhAcziYTEof+5IpwLpoVyUnTF66INye7X09g3tqbyY1bVqtibWXLDaLCs= =sauL -----END PGP SIGNATURE----- From ben at adversary.org Fri May 9 07:09:15 2014 From: ben at adversary.org (Ben McGinnes) Date: Fri, 09 May 2014 15:09:15 +1000 Subject: a bit OT: pgpdump binaries? In-Reply-To: <536C44E1.9090807@gmail.com> References: <536C44E1.9090807@gmail.com> Message-ID: <536C62FB.40700@adversary.org> On 9/05/14 1:00 PM, Faramir wrote: > Hello, > I hope this is not much off-topic. I was looking for pgpdump > binaries, and the one I have is for version 0.20, I downloaded it on > september 2011. But in the website, the current version is 0.28, > from june 2013. Does somebody know where I can get a binary file for > windows? Maybe one day I'll learn to compile stuff, but for now I'd > rather use a binary. I don't know about a Windows binary, but it appears that someone has ported it to Python, so if you have that language installed you might be able to get it to do what you want. https://pypi.python.org/pypi/pgpdump/1.5 I haven't played with it (yet, I suspect that will change in the not too distant future) because I normally use the C version (and compile the source, but I only have Linux and OS X systems here so I can't roll you one unfortunately). That said, it doesn't look to be too large, you might be able to find someone who can compile a Windows binary for you here or maybe even on PGPNET. I'd do it for you, but I haven't had a Windows system for 15 years. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From josef at netpage.dk Fri May 9 10:34:54 2014 From: josef at netpage.dk (Josef Schneider) Date: Fri, 09 May 2014 10:34:54 +0200 Subject: a bit OT: pgpdump binaries? In-Reply-To: <536C9259.6090308@netpage.dk> References: <536C44E1.9090807@gmail.com> <536C62FB.40700@adversary.org> <536C9259.6090308@netpage.dk> Message-ID: <536C932E.9080709@netpage.dk> Hi, something strange happened in my mail client so the signature of the last message was invalid! Here is the same message correctly signed: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, compilation is straightforward, if msys and mingw is installed! pgpdump.c is missing a "#include ", after adding that just a ./configure and make to compile it! I compiled a 64 and a 32 bit version for you! The files are digitally signed using the Microsoft Authenticode stuff. The SHA-512 hashes of the files are: pgpdump64.exe: 80F749B4893507502BE0418D022D4ECBE0018BE8F4DDF4B9ECC8C031962965CF 69C3FF5B83553819E3658C17B40E08A2CD536DD8229FCA2EA23DF0F205FEB364 pgpdump.exe: 771572FB6A1B078EF3E2A4E7EBEE3A2E8BA8817099F4B3DF1FA09E1CBECF174C FDD3138E610A6D62087038AABBBAC6E019A1DE55C8BAE9D3D8253EAC700EB799 You can get them here: http://dl.j0s.eu/pgpdump.zip The files are statically linked to winpthreads, so make sure to read the included license. Best regards, Josef -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (MingW32) - GPGshell v3.78 iQIcBAEBAgAGBQJTbJL+AAoJEDFA6HOb5F7Qu7kP/2qqYck7X83/YupDA+xgEg5P JyHdWUq2vQRXIvDjfqdO0n4e0KxS+cpEx3CitT+X5I666P2ZS+4GVBj4fBKgzA6C qAdzmDIMhqkAat3cdOGDiC7ESSChN711p+90imxQXDoeP95Fg33Gn3HLLzziMtet 1ePO7BVRN1QuWrOPYjp9j1R6LCgfVzoX2YB85ZxD56VlEwokFLql1hmSwsAskpWP j3wXhTpuaBFox6eVWeMunmVXIsDrfBYtY9/GbITvMGkfCCy8jH8N1SA3rwpjkd9B nnXE1Y/m/ytufxDvtLdP10fP85grgilWKQDLPBspYkwGYpB3kpt4NLGbCWnomfRl YGoLowZP90ud5cyUBRkXwmaxuPUGyhE+m8WnV6LouM+CnyNpnhNlTaqjeEVOgxkW 763dY+0pSitp9CVslHpMIVbFexvF7OHlBdBeydONBff8TRAuw+baGAlmejLsXKq/ sRfa29QP5reIsR1jNMnPOxEeWnnbLOmjgmezYgz6gxwtxX3M2Nnw0kYJRCL7CSwa E+Lb1ZWdAteKp6INAxJGDy7SWRaxxEV57C6dTznk5IieB4O/1Sncfs72wmhjXPa7 HUEyw3zXTknJPGJwPGrEkGWnGgfGaUSWUSsk+tKE3DLMcDkEiTIpyXRdsTDDSf/A StGLWwMt2ur4VlryzZvl =StYd -----END PGP SIGNATURE----- From josef at netpage.dk Fri May 9 10:31:21 2014 From: josef at netpage.dk (Josef Schneider) Date: Fri, 09 May 2014 10:31:21 +0200 Subject: a bit OT: pgpdump binaries? In-Reply-To: <536C62FB.40700@adversary.org> References: <536C44E1.9090807@gmail.com> <536C62FB.40700@adversary.org> Message-ID: <536C9259.6090308@netpage.dk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, compilation is straightforward, if msys and mingw is installed! pgpdump.c is missing a "#include ", after adding that just a ./configure and make to compile it! I compiled a 64 and a 32 bit version for you! The files are digitally signed using the Microsoft Authenticode stuff. The SHA-512 hashes of the files are: pgpdump64.exe: 80F749B4893507502BE0418D022D4ECBE0018BE8F4DDF4B9ECC8C031962965CF69C3FF5B83553819E3658C17B40E08A2CD536DD8229FCA2EA23DF0F205FEB364 pgpdump.exe: 771572FB6A1B078EF3E2A4E7EBEE3A2E8BA8817099F4B3DF1FA09E1CBECF174CFDD3138E610A6D62087038AABBBAC6E019A1DE55C8BAE9D3D8253EAC700EB799 You can get them here: http://dl.j0s.eu/pgpdump.zip The files are statically linked to winpthreads, so make sure to read the included license. Best regards, Josef > Ben McGinnes > Freitag, 9. Mai 2014 07:09 > > I don't know about a Windows binary, but it appears that someone has > ported it to Python, so if you have that language installed you might > be able to get it to do what you want. > > https://pypi.python.org/pypi/pgpdump/1.5 > > I haven't played with it (yet, I suspect that will change in the not > too distant future) because I normally use the C version (and compile > the source, but I only have Linux and OS X systems here so I can't > roll you one unfortunately). That said, it doesn't look to be too > large, you might be able to find someone who can compile a Windows > binary for you here or maybe even on PGPNET. I'd do it for you, but I > haven't had a Windows system for 15 years. > > > Regards, > Ben > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Faramir > Freitag, 9. Mai 2014 05:00 > Hello, > I hope this is not much off-topic. I was looking for pgpdump > binaries, and the one I have is for version 0.20, I downloaded it on > september 2011. But in the website, the current version is 0.28, from > june 2013. Does somebody know where I can get a binary file for > windows? Maybe one day I'll learn to compile stuff, but for now I'd > rather use a binary. > > Best Regards > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJTbJJPAAoJEDFA6HOb5F7Q7+MQAMdWc+XRuLg96xOvVPu2bF3v aEdwt7OVADxGReniv/wVnbEDDnzoL+/3tJspooZVOX6dzH2jReK1Zh9Sj0XLK2gR 9RKQ1cJOmjSB8dO6/n8KES5dro498pYJjPhIoiHGHHwwmBC4ZsK3Z6uWHX0HhRFs 8e4miCEmU9Qu1FE39B9jDD/DVLiBSU1+JTl1Fa+d8pMtfdrrDYbFQKSYwnJ2sDLM 6F8LQWakW1uhiVSu4nYKQt3ZgsDs/SLKXIGgC8+Q5Fl150hSV0Th2H7zNi3b4gWl uQY4+ZXLsaRG7Lt2cknBhkIUfjpS+p7a0Rq5srNkI47VZq37DQc7h0oIGy5NWIze gL9Q30d9o65lRJuBLPUWf2Z2JgE2N3Bj+0063oIcZP5wSzf9tMMuJJ1G+Vb7jtgf Yv11jQD6krXFE5XQtP8619QFwELBfr4nfs0sGAuD1rarjnjqAdz3NuNwKjEXSb+F sBaqnyQMWQiit1e9iZAf1nQe9kR1LxR6webOsfakHrmWPwMKtJe78gxkxWp67JIp DzgeffgVmyuIZiFDJ32qP0dKCtIIN+dEy32QRmMF9MWGVwZ3tUoibhC9QU9B/FB5 rR+PvNPqIplCHQa5ZNk6lPcv0IIDVbXfmk6rLnKrtjmveBUrSh8ks+cpyK6NbVok HZbFV3jhEdyo+vBYW2jv =BK2B -----END PGP SIGNATURE----- From tux.tsndcb at free.fr Fri May 9 11:57:58 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Fri, 9 May 2014 11:57:58 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: Message-ID: <77181624.186995084.1399629478677.JavaMail.root@zimbra33-e6.priv.proxad.net> Hi Thomas, I believe this blog article could be a useful reference: https://blog.kumina.nl/2010/07/two-factor-luks-using-ubuntu/ I've tested it on my sid debian with my pinpad reader, but the mean matter, it's on boot my debian failed to acces to my smartcard. Does somebody have sucessfully used it's smartcard to do that ? Thanks in advanced for your return. Best Regards. From taltman1 at stanford.edu Sat May 10 10:23:57 2014 From: taltman1 at stanford.edu (Tomer Altman) Date: Sat, 10 May 2014 01:23:57 -0700 (PDT) Subject: Best practices for securely creating master RSA key In-Reply-To: <195775076.425460.1399709664631.JavaMail.zimbra@stanford.edu> Message-ID: <226057737.427728.1399710237142.JavaMail.zimbra@stanford.edu> To whom it may concern, I recall reading somewhere some best practices for creating one's initial RSA key pair that they intend for building their Web of Trust. I think the recommended steps were: 1. Find a computer that you think is relatively free of malware 2. Download a Live Linux distro CD/DVD/USB, and verify its signatures to make sure you are not installing a tainted version 3. Launch the verified Linux distro. 4. Use GnuPG to create private RSA key, and two subkeys (signing & encrypting) 5. Strip the master private key from the keychain, saving on an encrypted medium (e.g., encrypted USB stick) 6. Create necessary revocation certificates, also save on encrypted USB stick 7. Copy over GnuPG keychain without master private key to work computer, personal laptop, etc. 8. Store encrypted USB stick somewhere safe Can people comment on what I recalled correctly, and what needs to be added/modified? Thanks, ~T From kloecker at kde.org Sat May 10 16:59:47 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 10 May 2014 16:59:47 +0200 Subject: Best practices for securely creating master RSA key In-Reply-To: <226057737.427728.1399710237142.JavaMail.zimbra@stanford.edu> References: <226057737.427728.1399710237142.JavaMail.zimbra@stanford.edu> Message-ID: <2160202.coz7lNQrsn@thufir.ingo-kloecker.de> On Saturday 10 May 2014 01:23:57 Tomer Altman wrote: > To whom it may concern, > > I recall reading somewhere some best practices for creating one's > initial RSA key pair that they intend for building their Web of > Trust. I think the recommended steps were: > > 1. Find a computer that you think is relatively free of malware > 2. Download a Live Linux distro CD/DVD/USB, and verify its signatures > to make sure you are not installing a tainted version > 3. Launch the verified Linux distro. > 4. Use GnuPG to create private RSA key, and two subkeys (signing & > encrypting) > 5. Strip the master private key from the keychain, saving on an > encrypted medium (e.g., encrypted USB stick) And/or store it on a smart card. > 6. Create necessary revocation certificates, also save on encrypted > USB stick Storing the revocation certificate together with the master private key is suboptimal. If you lose the USB stick or it stops working then you won't be able to revoke your master key. I suggest printing the revocation certificate on a piece of paper and storing it at a safe place. You could even print multiple copies and store them in different safe locations to reduce the risk of losing it through fire/water/theft/whatever. The worst that can happen if somebody gets hold of one of the copies is that he can revoke your key. That'd be annoying, but your data would still be protected. > 7. Copy over GnuPG keychain without master private key to work > computer, personal laptop, etc. And/or copy the private subkeys to a smart card. > 8. Store encrypted USB stick somewhere safe 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 ben at adversary.org Sat May 10 20:08:57 2014 From: ben at adversary.org (Ben McGinnes) Date: Sun, 11 May 2014 04:08:57 +1000 Subject: a bit OT: pgpdump binaries? In-Reply-To: <536C932E.9080709@netpage.dk> References: <536C44E1.9090807@gmail.com> <536C62FB.40700@adversary.org> <536C9259.6090308@netpage.dk> <536C932E.9080709@netpage.dk> Message-ID: <536E6B39.1080403@adversary.org> On 9/05/14 6:34 PM, Josef Schneider wrote: > Hi, > > something strange happened in my mail client so the signature of the > last message was invalid! I'm sure we've all had that happen at some point. Anyway, thanks, I'm sure Faramir will appreciate these and I can probably think of a few other people who woud like them, so I might just mirror them. ;) Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sat May 10 18:06:38 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 10 May 2014 13:06:38 -0300 Subject: Best practices for securely creating master RSA key In-Reply-To: <226057737.427728.1399710237142.JavaMail.zimbra@stanford.edu> References: <226057737.427728.1399710237142.JavaMail.zimbra@stanford.edu> Message-ID: <536E4E8E.7040900@fifthhorseman.net> Hi Tomer-- On 05/10/2014 05:23 AM, Tomer Altman wrote: > 1. Find a computer that you think is relatively free of malware > 2. Download a Live Linux distro CD/DVD/USB, and verify its signatures to make sure you are not installing a tainted version > 3. Launch the verified Linux distro. > 4. Use GnuPG to create private RSA key, and two subkeys (signing & encrypting) > 5. Strip the master private key from the keychain, saving on an encrypted medium (e.g., encrypted USB stick) > 6. Create necessary revocation certificates, also save on encrypted USB stick > 7. Copy over GnuPG keychain without master private key to work computer, personal laptop, etc. > 8. Store encrypted USB stick somewhere safe > > Can people comment on what I recalled correctly, and what needs to be added/modified? Your steps above seem pretty sensible to me, especially if you don't already have a trust-worthy, trusted machine that runs gpg. I would only adjust the creation and storage of the revocation certificate(s). first: i think you only need one revocation certificate, not several; in particular, you should make a generic "this key has been compromised" certificate for your primary key. This certificate is capable of invalidating all your user IDs and subkeys. second: I don't think it makes sense to store the revocation certificate on the same medium (the encrypted USB stick) as the primary secret key. If you need to revoke, and the encrypted USB stick is still available to you, then you can just use the primary secret key to generate a new revocation certificate (which can even be clearer about the specific reason for revocation, if you want it to be. If you need to revoke, and the encrypted USB stick is not available (e.g. it is physically lost, destroyed, or you no longer have access to the passphrase), then you won't be able to get to the revocation certificate. So that suggests that you probably want to store the revocation certificate someplace else. I'd argue that you probably want it to be *more* available than your master secret key. If your revocation certificate is compromised, the worst that an attacker can do is invalidate your key. This is a bad thing, but not nearly as bad as what a compromise of the master secret key could do. You could print out the revocation certificate and store it in a safe place, or entrust it to a technically-proficient and responsible friend. Or do both :) When printing, you could use plain ascii text (the armored certificate) or you could pass it through a tool like optar (or other machine-readable encoding mechanisms) to make it more easily recoverable from paper. I'm not sure that the machine-readability is particularly useful. It's a lot of work to type in an ascii revocation certificate by hand (esp. with large RSA keys), but if you ever have good cause to use your revocation certificate, you will probably have much more work to do (repairing your digital identity) and typing in a dozen lines of base64 will seem simple by comparison :P All the best, --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 tux.tsndcb at free.fr Sun May 11 20:32:41 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Sun, 11 May 2014 20:32:41 +0200 (CEST) Subject: =?utf-8?Q?cyberJack=C2=AE_RFID_komfort_works_fine_with_pinpad_=3F?= In-Reply-To: <1064592255.112549990.1397662830669.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <1890653961.193720172.1399833161251.JavaMail.root@zimbra33-e6.priv.proxad.net> Hi all, Before buy it, I wanted to know if someone use a cyberJack? RFID komfort or cyberJack? go plus smartcard reader and can confirm to me than pinpad works fine with gnupg-ccid driver. Thanks in advanced for your return Best Regards From faramir.cl at gmail.com Mon May 12 00:18:27 2014 From: faramir.cl at gmail.com (Faramir) Date: Sun, 11 May 2014 18:18:27 -0400 Subject: Best practices for securely creating master RSA key In-Reply-To: <226057737.427728.1399710237142.JavaMail.zimbra@stanford.edu> References: <226057737.427728.1399710237142.JavaMail.zimbra@stanford.edu> Message-ID: <536FF733.1040407@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 10-05-2014 4:23, Tomer Altman escribi?: > To whom it may concern, > > I recall reading somewhere some best practices for creating one's > initial RSA key pair that they intend for building their Web of > Trust. I think the recommended steps were: > > 1. Find a computer that you think is relatively free of malware 2. > Download a Live Linux distro CD/DVD/USB, and verify its signatures > to make sure you are not installing a tainted version 3. Launch the > verified Linux distro. 4. Use GnuPG to create private RSA key, and > two subkeys (signing & encrypting) 5. Strip the master private key > from the keychain, saving on an encrypted medium (e.g., encrypted > USB stick) 6. Create necessary revocation certificates, also save > on encrypted USB stick 7. Copy over GnuPG keychain without master > private key to work computer, personal laptop, etc. 8. Store > encrypted USB stick somewhere safe You need to create the revocation certificates before removing the primary key, since it is needed to create them. Also, I'd use paperkey to print my secret keys, I'd have them protected by an easy to remember passphrase, since by the time you need the paper backup, you may have changed your passphrase several times, so... also, malware can't steal the printed key, so the passphrase doesn't necessarily need to be bruteforce-proof (now, if you think somebody may want you secret key so bad to do burglary... then it must be a strong passphrase). To remove the primary key, what you do is to export the secret subkeys, then backup your keys (and store them somewhere safe), delete the key, and import the subkeys. If you are working on a live CD, the only malware that may interfere is a tainted bios, something most people doesn't have to worry about (but again, some people DO need to worry about it, I've heard a hint about a non profit CA got a donated computer, and when they checked it before using it, they found something nasty in the bios). I've been thinking maybe I should designate a revocation key (somebody I can trust), but so far, I don't know anyone I know to 1.- Be willing to be my designated revoker. 2.- Know how to keep his key safe until I need him to revoke my key. 3.- Be careful enough to don't revoke my key by mistake. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTb/czAAoJEMV4f6PvczxA3xcH/AzVrmqLNb9DBOGcHFd6l39+ SqeycMRQvmBUp4AcWle4HM1+2uxwsaeY2gCr+cxaM1CTjYN4HuN+bAJ/0ot86/sT w9eysPD3yRS8mVj2q0ORj0Ic3lTXk3NdxNgWf0J/cL8LD2yfreWzLjeURK2cKk5b 8Q6PAX4p8u9XNPwvmw8PrwWTTyMBL9eVmq0VbNK/+K3k1qyxyPj+eFqB0PWD8TZB 43wQ2aL3gUHRP9d4y28LNtOgSKKtXKWgeQ7K9Pn/Fj+kBm0WdZGgUZYQlscYx9jv rhCQQavRP0Lue+EOc6oJlZNvmfVrInsTsdku+tOz+6DfjeHyDpa1Cj6N0D2rza0= =JNHf -----END PGP SIGNATURE----- From faramir.cl at gmail.com Mon May 12 01:15:29 2014 From: faramir.cl at gmail.com (Faramir) Date: Sun, 11 May 2014 19:15:29 -0400 Subject: a bit OT: pgpdump binaries? In-Reply-To: <536C932E.9080709@netpage.dk> References: <536C44E1.9090807@gmail.com> <536C62FB.40700@adversary.org> <536C9259.6090308@netpage.dk> <536C932E.9080709@netpage.dk> Message-ID: <53700491.9020701@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 09-05-2014 4:34, Josef Schneider escribi?: ... > Hi, > > compilation is straightforward, if msys and mingw is installed! > pgpdump.c is missing a "#include ", after adding that > just a ./configure and make to compile it! I compiled a 64 and a > 32 bit version for you! The files are digitally signed using the > Microsoft Authenticode stuff. Hello Josef, Thank you, as Ben said, I appreciate your effort and already downloaded the binary files. I tried to verify the digital signature, but something failed, however, the hash values match the ones you provided, plus virustotal battery of 52 antivirus agree the file is safe, so I'm puzzled but not worried about the signature. Thanks again Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTcASRAAoJEMV4f6PvczxAc4EH/13GrC8VToFOZNAoQsKh6Ltx 3HsMeWWNDB5J8IW9JlFtyzQQ+9bG925AhGaLboOsF7S/12TdPJQRrOHqO4jXgA5q rE5GW7AArgaKMSwseNJy97S0m7Y7ma8yEG7f3NqiQbxI2tXLzUiFbat0fXVDcufK Di0HD5qdfnz41vma7GzuW47qhvYxc2Aga7TYcW8B4hs76R00c0xQmAOw3M0K9pNb 1oDJOCw5M2QTEbcw0M7p9tlydwMLhNyt7gNR1b6m5OrjbY0EIi94E6V6bt0JwmPS 58upWqECqPgq9uyD/p4yGLMJvzjqIUh3LrUCIMZpVh2zIpb0YL2ni50WlLXh0D4= =2keJ -----END PGP SIGNATURE----- From cai.0407 at gmail.com Mon May 12 07:57:25 2014 From: cai.0407 at gmail.com (Kosuke Kaizuka) Date: Mon, 12 May 2014 14:57:25 +0900 Subject: a bit OT: pgpdump binaries? In-Reply-To: <53700491.9020701@gmail.com> References: <536C44E1.9090807@gmail.com> <536C62FB.40700@adversary.org> <536C9259.6090308@netpage.dk> <536C932E.9080709@netpage.dk> <53700491.9020701@gmail.com> Message-ID: <537062C5.2070705@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Thank you Josef for binary files! On Sun, 11 May 2014 19:15:29 -0400, Faramir wrote: >> compilation is straightforward, if msys and mingw is installed! >> pgpdump.c is missing a "#include ", after adding that >> just a ./configure and make to compile it! I compiled a 64 and >> a 32 bit version for you! The files are digitally signed using >> the Microsoft Authenticode stuff. > > Hello Josef, Thank you, as Ben said, I appreciate your effort and > already downloaded the binary files. I tried to verify the digital > signature, but something failed, however, the hash values match > the ones you provided, plus virustotal battery of 52 antivirus > agree the file is safe, so I'm puzzled but not worried about the > signature. I have downloaded and checked binary files. ? pgpdump64.exe SHA-512: match Microsoft Authenticode: verified (Name: Josef Schneider, Email address: josef.schneider at gmail.com, Signed on: ?2014?/05?/09? 17:12:04) check by Norton: passed pgpdump.exe SHA-512: match Microsoft Authenticode: verified (Name: Josef Schneider, Email address: josef.schneider at gmail.com, Signed on: ?2014?/05?/09? 17:16:36) check by Norton: passed Authenticode certificate is issued by StartCom Class 2 Primary Intermediate Object CA. - -- Kosuke Kaizuka -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBCgAGBQJTcGLFAAoJEFI91dNOjkjZ3hQQANC+fpVL3pWiDvxzG2b1wTZO e1wR1fsgd6P5vyyTmkANo9LXwoCJsrUysF3JykTKceROnJtUp6lHbE3woNwlTPrp 5Idyh7v0RQ2kWywntrCuBX2dTQNA1NFqhol63rp7zFa7vdWJw7bUOVz6J3hVVSyK mjpPU2QIULQBW2Gb4cZTyjVvwuvSg9PfEzdEvohmEYV2stlPRtNJH1HhFL0qeYEY 2Tw0PYFBa8gBzb+on3NFxyoTGIB7hjBqLE1b5Ze08VGkjCT1tlkiyg7X3TYMkINn Oz+hFlMP/Kjs4b+Oyd4DoccUT9jLgxjm46heUCyyg36XqaSqsG1VbDA6xIHvVDzz KddHUAbXo3hyhFs7gdVI3HJpQYMw0aNwuTFvRw4PZWLeo11TYM8FuXs50ZtWytVR FOQCko+TE4j+N8hGcLvK0HnGQQlbYuMgxXMI3zi0HADvHRuR7YtU9KQTEKR5vvjZ lqSii3wRf68/xcXS7J6xU9soRdDqjcyhGW+OFcwWqkwRBnjkZ/EdfMrFZuNanS11 CaDyoj9123uym5Yl7ECWAA2M2qFIQ1OX+v8Ap0qW4KbrLtk8YJXSQlbimPvCik10 nTUvvSjqxm7Kfj8DT8SH7gK0PsUYaL75AhYiFIZ2ukRJ464WWqFDGT5p6I/BlWGa idpADBVEzEFuG4SV/SZo =I88e -----END PGP SIGNATURE----- From taltman1 at stanford.edu Mon May 12 09:35:16 2014 From: taltman1 at stanford.edu (Tomer Altman) Date: Mon, 12 May 2014 00:35:16 -0700 (PDT) Subject: Best practices for securely creating master RSA key In-Reply-To: <536E4E8E.7040900@fifthhorseman.net> References: <226057737.427728.1399710237142.JavaMail.zimbra@stanford.edu> <536E4E8E.7040900@fifthhorseman.net> Message-ID: <1335283472.29354.1399880116107.JavaMail.zimbra@stanford.edu> Hi dkg & Josef, Thank you very much for your replies. I appreciate it. Below please find my revised steps to follow, as per your advice. dkg, I had a few questions: You recommend creating a revocation certificate against the private key, but the GPG documentation seems to recommend creating the revocation certificate against the public (sub-)key: https://www.gnupg.org/gph/en/manual.html#REVOCATION What are the pluses and minuses of the two approaches? Also, do you know if such a set of recommended steps is documented somewhere. I *swear* that I saw it somewhere on the myriad GPG webpages, but now I can't seem to find it. If it does not exist, do you think it would be worthwhile to add it somewhere, perhaps as a FAQ entry? Thanks again, ~Tomer --- 1. Find a computer that you think is relatively free of malware 2. Download a Live Linux distro CD/DVD/USB, and verify its signatures to make sure you are not installing a tainted version 3. Launch the verified Linux distro 3.1 Make sure the distro is completely disconnected from any network connection before proceeding 4. Use GnuPG to create private RSA key, and two subkeys (signing & encrypting) 4.1 Set expiration date on (public) sub-key 4.2 Create both a paper and digital backup of master private key Store the backups in two different physical locations, so no single point of failure 4.3 Create a revocation certificate for the public encrypting sub-key 4.4 Create both a paper and digital backup of the revocation certificate Store the backups in two different physical locations, so no single point of failure 5. Strip the master private key from the keychain. 6. Copy over GnuPG keychain without master private key to work computer, personal laptop, etc. --- ----- Original Message ----- From: "Daniel Kahn Gillmor" To: "Tomer Altman" , gnupg-users at gnupg.org Sent: Saturday, May 10, 2014 9:06:38 AM Subject: Re: Best practices for securely creating master RSA key Hi Tomer-- On 05/10/2014 05:23 AM, Tomer Altman wrote: > 1. Find a computer that you think is relatively free of malware > 2. Download a Live Linux distro CD/DVD/USB, and verify its signatures to make sure you are not installing a tainted version > 3. Launch the verified Linux distro. > 4. Use GnuPG to create private RSA key, and two subkeys (signing & encrypting) > 5. Strip the master private key from the keychain, saving on an encrypted medium (e.g., encrypted USB stick) > 6. Create necessary revocation certificates, also save on encrypted USB stick > 7. Copy over GnuPG keychain without master private key to work computer, personal laptop, etc. > 8. Store encrypted USB stick somewhere safe > > Can people comment on what I recalled correctly, and what needs to be added/modified? Your steps above seem pretty sensible to me, especially if you don't already have a trust-worthy, trusted machine that runs gpg. I would only adjust the creation and storage of the revocation certificate(s). first: i think you only need one revocation certificate, not several; in particular, you should make a generic "this key has been compromised" certificate for your primary key. This certificate is capable of invalidating all your user IDs and subkeys. second: I don't think it makes sense to store the revocation certificate on the same medium (the encrypted USB stick) as the primary secret key. If you need to revoke, and the encrypted USB stick is still available to you, then you can just use the primary secret key to generate a new revocation certificate (which can even be clearer about the specific reason for revocation, if you want it to be. If you need to revoke, and the encrypted USB stick is not available (e.g. it is physically lost, destroyed, or you no longer have access to the passphrase), then you won't be able to get to the revocation certificate. So that suggests that you probably want to store the revocation certificate someplace else. I'd argue that you probably want it to be *more* available than your master secret key. If your revocation certificate is compromised, the worst that an attacker can do is invalidate your key. This is a bad thing, but not nearly as bad as what a compromise of the master secret key could do. You could print out the revocation certificate and store it in a safe place, or entrust it to a technically-proficient and responsible friend. Or do both :) When printing, you could use plain ascii text (the armored certificate) or you could pass it through a tool like optar (or other machine-readable encoding mechanisms) to make it more easily recoverable from paper. I'm not sure that the machine-readability is particularly useful. It's a lot of work to type in an ascii revocation certificate by hand (esp. with large RSA keys), but if you ever have good cause to use your revocation certificate, you will probably have much more work to do (repairing your digital identity) and typing in a dozen lines of base64 will seem simple by comparison :P All the best, --dkg From wk at gnupg.org Mon May 12 12:14:02 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 May 2014 12:14:02 +0200 Subject: =?utf-8?Q?cyberJack=C2=AE?= RFID komfort works fine with pinpad ? In-Reply-To: <1890653961.193720172.1399833161251.JavaMail.root@zimbra33-e6.priv.proxad.net> (tux tsndcb's message of "Sun, 11 May 2014 20:32:41 +0200 (CEST)") References: <1890653961.193720172.1399833161251.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <87wqdrxq1h.fsf@vigenere.g10code.de> On Sun, 11 May 2014 20:32, tux.tsndcb at free.fr said: > Before buy it, I wanted to know if someone use a cyberJack? RFID > komfort or cyberJack? go plus smartcard reader and can confirm to me Better buy a different reader. Readers from that company are riddled with proprietary extensions and don't comply with the CCID standard. They might work on Windows using their drivers. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jhs at berklix.com Mon May 12 12:58:45 2014 From: jhs at berklix.com (Julian H. Stacey) Date: Mon, 12 May 2014 12:58:45 +0200 Subject: =?utf-8?Q?cyberJack=C2=AE?= RFID komfort works fine with pinpad ? In-Reply-To: Your message "Mon, 12 May 2014 12:14:02 +0200." <87wqdrxq1h.fsf@vigenere.g10code.de> Message-ID: <201405121058.s4CAwj4q047785@fire.js.berklix.net> Werner Koch wrote: > On Sun, 11 May 2014 20:32, tux.tsndcb at free.fr said: > > > Before buy it, I wanted to know if someone use a cyberJack?? RFID > > komfort or cyberJack?? go plus smartcard reader and can confirm to me > > Better buy a different reader. Readers from that company are riddled > with proprietary extensions and don't comply with the CCID standard. > They might work on Windows using their drivers. > > > Salam-Shalom, > > Werner Some FreeBSD people inc. me have same or similar products, http://lists.freebsd.org/pipermail/freebsd-usb/2014-February/012813.html Click through on "Next message" until end of thread in Feb. Then here: http://lists.freebsd.org/pipermail/freebsd-usb/2014-March/012849.html Dont ask me questions though, all I know is posted, others there know more. Cheers, Julian -- Julian Stacey, BSD Linux Unix'78 C Sys Eng Consultant Munich http://berklix.com Interleave replies Below like a play script. Indent old text with "> ". Google breach privacy http://berklix.com/jhs/adverts/ From tux.tsndcb at free.fr Mon May 12 14:00:43 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Mon, 12 May 2014 14:00:43 +0200 (CEST) Subject: =?utf-8?Q?REINERSCT_cyberJack=C2=AE_go_plus_works_fi?= =?utf-8?Q?ne_with_pinpad_=3F_Thanks_to_confirm_it.?= In-Reply-To: <201405121058.s4CAwj4q047785@fire.js.berklix.net> Message-ID: <1878530998.195788058.1399896043502.JavaMail.root@zimbra33-e6.priv.proxad.net> Hi, Thanks for your answers (Werner and Julian), so maybe the good choise should be the other : cyberJack? go plus, CCID compliance as I've can read, isn't it ? SCM SPR 532, KAAN Advanced and Cherry ST2000 are too big for a nomade usage and the last : Vasco DigiPASS 920, seems no longer be sold If someone use a cyberJack? go plus thanks to confirm than pinpad works fine. PS I change the title to cyberJack? go plus Thanks in advanced for your return. Best Regards From wk at gnupg.org Mon May 12 15:07:40 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 May 2014 15:07:40 +0200 Subject: REINERSCT =?utf-8?Q?cyberJack=C2=AE?= go plus works fine with pinpad ? Thanks to confirm it. In-Reply-To: <1878530998.195788058.1399896043502.JavaMail.root@zimbra33-e6.priv.proxad.net> (tux tsndcb's message of "Mon, 12 May 2014 14:00:43 +0200 (CEST)") References: <1878530998.195788058.1399896043502.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <87lhu7w3fn.fsf@vigenere.g10code.de> > Thanks for your answers (Werner and Julian), so maybe the good choise > should be the other : cyberJack? go plus, CCID compliance as I've can > read, isn't it ? SCM SPR 532, KAAN Advanced and Cherry ST2000 are too My KAAN Advanced does not work with 2048 bit cards. I used that device some years ago up until I switched to a 2048 bit key. SPR 532 works fine - I have used several of them over the last decade. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Mon May 12 18:52:47 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 12 May 2014 12:52:47 -0400 Subject: Best practices for securely creating master RSA key In-Reply-To: <1335283472.29354.1399880116107.JavaMail.zimbra@stanford.edu> References: <226057737.427728.1399710237142.JavaMail.zimbra@stanford.edu> <536E4E8E.7040900@fifthhorseman.net> <1335283472.29354.1399880116107.JavaMail.zimbra@stanford.edu> Message-ID: <5370FC5F.1070603@fifthhorseman.net> On 05/12/2014 03:35 AM, Tomer Altman wrote: > You recommend creating a revocation certificate against the private key, but the GPG documentation seems to recommend creating the revocation certificate against the public (sub-)key: > > https://www.gnupg.org/gph/en/manual.html#REVOCATION > > What are the pluses and minuses of the two approaches? I think they're not different approaches. you need the secret key to make a revocation certificate, but it applies to the full OpenPGP certificate anchored by the primary key. there are different kinds of revocations that you can make: a revocation that revokes a subkey or a user ID is narrower than a revocation that revokes a primary key. If you still have exclusive access to the primary key, then you can always issue one of the narrower certifications yourself directly. So the only thing you need a revocation certificate for is for the primary key. Does that make sense? > Also, do you know if such a set of recommended steps is documented somewhere. I *swear* that I saw it somewhere on the myriad GPG webpages, but now I can't seem to find it. If it does not exist, do you think it would be worthwhile to add it somewhere, perhaps as a FAQ entry? There are indeed lots of documents in existence that touch on these ideas, but that's understandable since there is no one single best way to create an OpenPGP certificate for ever: too many circumstances that have different goals and requirements. I think it's entirely legitimate to write up a high-quality reasonable suggestion for a common use case though, which is what it sounds like you're aiming for. And maybe some (or all) of it should go in the FAQ, but i'll let Robert (who maintains the FAQ, iirc) weigh in on that. 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 rjh at sixdemonbag.org Mon May 12 19:21:04 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 12 May 2014 10:21:04 -0700 Subject: Best practices for securely creating master RSA key In-Reply-To: <5370FC5F.1070603@fifthhorseman.net> References: <226057737.427728.1399710237142.JavaMail.zimbra@stanford.edu> <536E4E8E.7040900@fifthhorseman.net> <1335283472.29354.1399880116107.JavaMail.zimbra@stanford.edu> <5370FC5F.1070603@fifthhorseman.net> Message-ID: <20140512102104.Horde.qoyK403HQPCFH5QmFm0NkA1@mail.sixdemonbag.org> > And maybe some (or all) of it should go in the FAQ, but i'll let Robert > (who maintains the FAQ, iirc) weigh in on that. I feel as if I should apologize in advance here, because this is going to be a little bit ranty -- Daniel is making a good point, though, and any incoherent fist-shaking at the universe that I may do is definitely not directed at him. The GnuPG community is prone to bikeshedding on a truly mind-blowing scale. It often seems to me that although there's general consensus on 90% of a subject, nobody can quite agree on what that 90% is. If I present a ten-step process as being a good practice, I can rely on the vast majority of opinions being "this seems pretty good on these nine points, but this tenth one absolutely has to go because it's wrong wrong wrong" -- and no agreement whatsoever on which nine points are good and which tenth one must go. Further, there is an unfortunate subset of the community that believes it has a monopoly on truth and that any disagreement is Jeoparding The Security Of The Entire Internet -- I capitalize that phrase because their emails to me often have that sense to them, as if every word was being emphasized just to make sure that I "got it". For that reason I'm generally not all that fond of weighing in on certain subjects, because they are so phenomenally divisive and generate so much more heat than light. (Case in point: PGP/MIME, which resulted in *so* much flamefesting in my inbox that rather than give a single answer on the subject I threw up my hands, said "to hell with it," and the FAQ entry basically says "whatever you think, half the community will say you're wrong.") Anyway: yes, this probably does warrant a FAQ entry, and I'll do my best to make changes and send Werner a revised version. Look for it by the end of the week. It may take a bit longer, depending on how quickly Amazon is able to ship me a new pair of asbestos longjohns... From davidq at lelantos.org Tue May 13 18:03:03 2014 From: davidq at lelantos.org (David Q.) Date: Tue, 13 May 2014 16:03:03 -0000 Subject: GPG's vulnerability to quantum cryptography Message-ID: GPG encrypted data (using RSA) can be collected today and easily decrypted after 50-100 years using a quantum computer. See: https://en.wikipedia.org/wiki/Shor%27s_algorithm For this reason, what I do today is share long keys with people I know *in person*. We then use regular AES-256 to encrypt/decrypt our messages back and forth. Every 6 months we meet in person to renew our keys. (To be more secure, we actually create the keys in portions via in-person at different places, OTR, SMS, landline phone, mobile phone, and snail mail.) AES-256 is not vulnerable to quantum cryptography as RSA is, so we feel much safer this way. What are your thoughts on these issues? Why do you keep using GPG, knowing that your data may easily end up out in the open on Google or The Pirate Bay a few decades from now? Are there any plans for added security measures in GPG given how vulnerable it is? For instance, any plans for adding quantum safe public key crypto alternatives to RSA? From rjh at sixdemonbag.org Tue May 13 20:00:34 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 13 May 2014 11:00:34 -0700 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: References: Message-ID: <20140513110034.Horde.HErSM6IORQe33JKyek73kg1@mail.sixdemonbag.org> > What are your thoughts on these issues? Why do you keep using GPG, knowing > that your data may easily end up out in the open on Google or The Pirate > Bay a few decades from now? Bluntly, my thoughts are that 99% of the people who talk about quantum computation couldn't identify a Hadamard transformation if they tripped over its brakets. Shor's Algorithm requires 2N qubits, where N is the size in bits of the composite you wish to factor. So for a 2048-bit certificate that requires 4096 qubits, representing a state space of over 10^1100. That's a quantum computer so ludicrously powerful that if one were to exist it would transform the world in ways we literally cannot imagine. This is a quantum computer so powerful that it defies even the dreams of science fiction authors. I literally lack the skill in the English language to describe just how eye-popping this thing is. The best analogy I can think of is that we're a bunch of primitive hominids just beginning to learn how to knap obsidian into knife blades, and you're saying "What are your thoughts on how obsolete these knives will be once we develop thermonuclear bombs? I mean, they're going to make these knife blades just ... *obsolete*." > What are your thoughts on these issues? Why do you keep using GPG, knowing > that your data may easily end up out in the open on Google or The Pirate > Bay a few decades from now? If that happens, I'll have much bigger things to worry about. I'll let you worry about the thermonuclear age: for now, I'd rather focus on the advent of the Bronze Age. From fizzlifax at posteo.net Tue May 13 18:58:42 2014 From: fizzlifax at posteo.net (Fizzlifax) Date: Tue, 13 May 2014 18:58:42 +0200 Subject: Result of the crowdfounding Message-ID: <0953a88eb35f87847659de717002daed@posteo.de> Hi freaks, Hi Werner, I was now looking at the results of the last goteo-campain and I am a little bit shocked about the costs for such a campaign. I am shure, that everybody did his best and for better understanding would like to submit some questions: - there ist a position of: Campaign manager 5390,-- ? and an other of: Goteo fee 2939,-- ? What for is this campaign manager? - Is this a part of goteo or of gnupg or somebody else? another question ist the VAT for about 5212,-- ? What are these taxes for? - I thought the vat of the t-shirts and stickers would be included? or is it as supplement for the goteo fee? Nevertheless - there are for a for a result of 37270,-- ? Costs in an amout of 50%! Means that of every euro arrives to the goal only 1/2 an euro. My question now: Would'nt it be better to put every year some "Index" in the top of the gnupg-website with the actual need for the runnig year and beg for direkt donations? 1.) we would save all the stress and stuff of a campaign 2.) there would be much less costs and less need to spend. or 3.) more money for the objectives... I think the rebuild of the website should include such a feature and if not some of the rest of the money should be used for realizing it for. best wishes Ralf From rjh at sixdemonbag.org Tue May 13 20:53:02 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 13 May 2014 11:53:02 -0700 Subject: Result of the crowdfounding In-Reply-To: <0953a88eb35f87847659de717002daed@posteo.de> References: <0953a88eb35f87847659de717002daed@posteo.de> Message-ID: <20140513115302.Horde.9W3IyFAuPp4J1fgb9wjkuw6@mail.sixdemonbag.org> > Goteo fee 2939,-- ? Goteo charges an amount proportional to the funds that are raised. 2939 euros on 37270 is about an eight percent overhead. Seems reasonable to me. > My question now: Would'nt it be better to put every year some > "Index" in the top of the gnupg-website with the actual need for the > runnig year and beg for direkt donations? It would be better if it worked. It doesn't, so the GnuPG folks tried something different, which turned out to work better despite the increased overheads. If funding increases by a factor of ten, then even if overhead eats up half that funding is still increased by a factor of five. > I think the rebuild of the website should include such a feature and > if not some of the rest of the money should be used for realizing it > for. Donating to GnuPG is already quick and easy. Yet despite this, people overwhelmingly tend not to do it. From 2014-667rhzu3dc-lists-groups at riseup.net Tue May 13 20:57:02 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 13 May 2014 19:57:02 +0100 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: References: Message-ID: <1728508555.20140513195702@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 13 May 2014 at 5:03:03 PM, in , David Q. wrote: > GPG encrypted data (using RSA) can be collected today > and easily decrypted after 50-100 years using a quantum > computer. I'm not likely to be alive by then. > Why do you keep > using GPG, knowing that your data may easily end up out > in the open on Google or The Pirate Bay a few decades > from now? It's better than not using GPG, and knowing things could easily be in the open a few *hours* from now. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Was time invented by an Irishman named O'Clock? -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlNyawZXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pv60EAKib9zr71D2315lArxy9GrmfrubY4PRPT8q7 Gi0DZl/Jq9DYpbldL6pBpeUxSzU1lV6eRhxyYt7f/BinTdidNP+hihJ4h4B15PM0 mik1wT0Fl4Lr4zuzhGywycWBi+/wHx8aCF/+TYS2iq2xyXIEHAzUqkzFwD7X8Nkj z7iaM8RF =4683 -----END PGP SIGNATURE----- From aaron.toponce at gmail.com Wed May 14 01:15:57 2014 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Tue, 13 May 2014 17:15:57 -0600 Subject: "gpg --with-fingerprint $FILE" is not listing the keyfingerprint in some cases Message-ID: <20140513231555.GD4493@irc.ae7.st> I don't know if this is a bug, or if I am doing something wrong, so I might as well ask here. I ran the following command from my terminal, and cannot retrieve the fingerprint from the file: $ gpg --output 0xBB065B251FF4945B.gpg --export 0xBB065B251FF4945B $ gpg --with-colons --with-fingerprint 0xBB065B251FF4945B.gpg pub:-:2048:1:BB065B251FF4945B:2008-07-27:::f: uid:::::::::Daniel T. Hagan : sub:-:2048:1:6BA86443C0C6CDA2:2008-07-27:::: sub:-:2048:1:16C018D9B89B420A:2008-07-27:::: There should exist an "^fpr" line in the output. Compare to: $ gpg --output 0x4713D527ECE16009.gpg --export 0x4713D527ECE16009 $ gpg --with-colons --with-fingerprint 0x4713D527ECE16009.gpg pub:-:1024:17:4713D527ECE16009:2005-06-06:::f:George Hacker (GLS) : fpr:::::::::8BFD3F436366D9820E9EAB2F4713D527ECE16009: uid:::::::::George Hacker : uid:::::::::George Hacker : uat:::::::::1 2493: sub:-:1024:16:0D94CF6C0C8C2F1B:2005-06-06:::: Of the 453 keys in my public keyring, this happens on 8 of them (about 2%): 0x072DC7442B89BD45 0x14774C7B9958256C 0x4B2A4897D39DA0E3 0x63E42BD8C58C753A 0x677A7DE8CC9A6F67 0x6FA1B04BB6724E04 0x9710B89BCA57AD7C 0xBB065B251FF4945B Any ideas what is going on? Thanks, -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: not available URL: From frase at frase.id.au Wed May 14 03:32:07 2014 From: frase at frase.id.au (Fraser Tweedale) Date: Wed, 14 May 2014 11:32:07 +1000 Subject: "gpg --with-fingerprint $FILE" is not listing the keyfingerprint in some cases In-Reply-To: <20140513231555.GD4493@irc.ae7.st> References: <20140513231555.GD4493@irc.ae7.st> Message-ID: <20140514013207.GF62147@bacardi.hollandpark.frase.id.au> On Tue, May 13, 2014 at 05:15:57PM -0600, Aaron Toponce wrote: > I don't know if this is a bug, or if I am doing something wrong, so I might as > well ask here. I ran the following command from my terminal, and cannot > retrieve the fingerprint from the file: > > $ gpg --output 0xBB065B251FF4945B.gpg --export 0xBB065B251FF4945B > $ gpg --with-colons --with-fingerprint 0xBB065B251FF4945B.gpg > pub:-:2048:1:BB065B251FF4945B:2008-07-27:::f: > uid:::::::::Daniel T. Hagan : > sub:-:2048:1:6BA86443C0C6CDA2:2008-07-27:::: > sub:-:2048:1:16C018D9B89B420A:2008-07-27:::: > > There should exist an "^fpr" line in the output. Compare to: > > $ gpg --output 0x4713D527ECE16009.gpg --export 0x4713D527ECE16009 > $ gpg --with-colons --with-fingerprint 0x4713D527ECE16009.gpg > pub:-:1024:17:4713D527ECE16009:2005-06-06:::f:George Hacker (GLS) : > fpr:::::::::8BFD3F436366D9820E9EAB2F4713D527ECE16009: > uid:::::::::George Hacker : > uid:::::::::George Hacker : > uat:::::::::1 2493: > sub:-:1024:16:0D94CF6C0C8C2F1B:2005-06-06:::: > > Of the 453 keys in my public keyring, this happens on 8 of them (about 2%): > > 0x072DC7442B89BD45 > 0x14774C7B9958256C > 0x4B2A4897D39DA0E3 > 0x63E42BD8C58C753A > 0x677A7DE8CC9A6F67 > 0x6FA1B04BB6724E04 > 0x9710B89BCA57AD7C > 0xBB065B251FF4945B > > Any ideas what is going on? > This behaviour also occurs for me in 2.0.22. Instead of exporting the key, you could use --list-keys, which works for me: % gpg2 --with-colons --with-fingerprint --list-keys 0xBB065B251FF4945B tru::1:1400030831:0:3:1:5 pub:-:2048:1:BB065B251FF4945B:1217137867:::-:::scESC: rvk:::1::::::F7701DA413DC6B981706EF5314774C7B9958256C:80: fpr:::::::::F630376527F0512BF2A661DDBB065B251FF4945B: uid:-::::1364072645::12B7BA95C2486E8FE4309E7A9A64799703020225::Daniel T. Hagan : sub:-:2048:1:6BA86443C0C6CDA2:1217137868::::::e: sub:-:2048:1:16C018D9B89B420A:1217137868::::::s: Cheers, Fraser > Thanks, > > -- > . o . o . o . . o o . . . o . > . . o . o o o . o . o o . . o > o o o . o . . o o o o . o o o > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From dshaw at jabberwocky.com Wed May 14 05:30:21 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 13 May 2014 23:30:21 -0400 Subject: "gpg --with-fingerprint $FILE" is not listing the keyfingerprint in some cases In-Reply-To: <20140513231555.GD4493@irc.ae7.st> References: <20140513231555.GD4493@irc.ae7.st> Message-ID: On May 13, 2014, at 7:15 PM, Aaron Toponce wrote: > I don't know if this is a bug, or if I am doing something wrong, so I might as > well ask here. I ran the following command from my terminal, and cannot > retrieve the fingerprint from the file: > > $ gpg --output 0xBB065B251FF4945B.gpg --export 0xBB065B251FF4945B > $ gpg --with-colons --with-fingerprint 0xBB065B251FF4945B.gpg > pub:-:2048:1:BB065B251FF4945B:2008-07-27:::f: > uid:::::::::Daniel T. Hagan : > sub:-:2048:1:6BA86443C0C6CDA2:2008-07-27:::: > sub:-:2048:1:16C018D9B89B420A:2008-07-27:::: > > There should exist an "^fpr" line in the output. Compare to: > > $ gpg --output 0x4713D527ECE16009.gpg --export 0x4713D527ECE16009 > $ gpg --with-colons --with-fingerprint 0x4713D527ECE16009.gpg > pub:-:1024:17:4713D527ECE16009:2005-06-06:::f:George Hacker (GLS) : > fpr:::::::::8BFD3F436366D9820E9EAB2F4713D527ECE16009: > uid:::::::::George Hacker : > uid:::::::::George Hacker : > uat:::::::::1 2493: > sub:-:1024:16:0D94CF6C0C8C2F1B:2005-06-06:::: > > Of the 453 keys in my public keyring, this happens on 8 of them (about 2%): > > 0x072DC7442B89BD45 > 0x14774C7B9958256C > 0x4B2A4897D39DA0E3 > 0x63E42BD8C58C753A > 0x677A7DE8CC9A6F67 > 0x6FA1B04BB6724E04 > 0x9710B89BCA57AD7C > 0xBB065B251FF4945B > > Any ideas what is going on? Looks like a bug. Note that on each of the keys that didn't work there is a direct signature on the key. This is not very common, and is usually used for a designated revoker (i.e. "I permit so-and-so to revoke my key for me"). I suspect there is a bug printing the fingerprints on a key from a key file (rather than from a keyring) for keys with a direct signature. David From micha137 at gmx.de Wed May 14 09:47:11 2014 From: micha137 at gmx.de (Michael Anders) Date: Wed, 14 May 2014 09:47:11 +0200 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: References: Message-ID: <1400053631.2723.26.camel@micha137-myAMD-CM1740> > > GPG encrypted data (using RSA) can be collected today and easily decrypted > after 50-100 years using a quantum computer. See: > https://en.wikipedia.org/wiki/Shor%27s_algorithm Well let's see. Usually in a new technology, once you are really going to apply it in the real world, new problems not thought of before are going to pop up. (Think of fusion energy from the tokamak, which is always predicted to be here in 20 years from "now" - since more than 40 years.) > > For this reason, what I do today is share long keys with people I know *in > person*. We then use regular AES-256 to encrypt/decrypt our messages back > and forth. Every 6 months we meet in person to renew our keys. (To be more > secure, we actually create the keys in portions via in-person at different > places, OTR, SMS, landline phone, mobile phone, and snail mail.) > > AES-256 is not vulnerable to quantum cryptography as RSA is, so we feel > much safer this way. > There is another quantum algorithm called Grovers Algorithm that would reduce the effort to crack 256 bit key AES to the effort necessary to crack 128 bit key AES. Since the well known agency from Baltimore uses its influence to have crypto standards coast close to the limit of the brute-forceable, 128 bit AES will be insecure not too far in the future. So if you are worried about the quantum computer, using AES as is directly won't help you a lot. You'd also need symmetric algorithms with at least 512 bit keys and at least 256 bit block size to retain the same security margin as in the pre quantum computer era. Large block and key size algorithms surely do exist. 50 years from now, I'm going to be 105. So if I 'll be alive then, I'll be grateful to be able to ask quantum computer equipped Baltimore for help on recovering my old secrets which might have slipped from my memory by then ;-) From mailinglisten at hauke-laging.de Wed May 14 09:55:19 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 14 May 2014 09:55:19 +0200 Subject: encryption information in a signature Message-ID: <1959299.rSBFVPEOsB@inno> Hello, I would like to suggest a probably easier alternative to my proposal "sign encrypted emails": http://lists.gnupg.org/pipermail/gnupg-users/2014-January/048681.html The purpose is that the recipient can be sure that the message has left the sending system encrypted (and: encrypted for a certain key) ? as it is easily possible for a MitM to encrypt an unencrypted message without being noticed, deluding the recipient about the confidentiality of the message. Nearly the same effect as that by my former suggestion may be reached by defining a notation which says: "This message is sent encrypted only. It will be encrypted for this key / these keys: ..." There is no reason not to trust the sending system about 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 peter at digitalbrains.com Wed May 14 11:12:12 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 14 May 2014 11:12:12 +0200 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: <1400053631.2723.26.camel@micha137-myAMD-CM1740> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> Message-ID: <5373336C.5070307@digitalbrains.com> On 14/05/14 09:47, Michael Anders wrote: > Since the well known agency from Baltimore uses its influence to have > crypto standards coast close to the limit of the brute-forceable, 128 > bit AES will be insecure not too far in the future. Brute-forcing a 128 bits key is, as far as we know, impossible without destroying a large part of the earth in the process. https://www.gnupg.org/faq/gnupg-faq.html#brute_force Also, you're really broadening from "some things are suspect" to "all things are suspect", but let's not delve into that too deep. I might have to ask Robert how comfortable his new asbestos longjohns are. 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 wk at gnupg.org Wed May 14 11:50:54 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 May 2014 11:50:54 +0200 Subject: Result of the crowdfounding In-Reply-To: <0953a88eb35f87847659de717002daed@posteo.de> (fizzlifax@posteo.net's message of "Tue, 13 May 2014 18:58:42 +0200") References: <0953a88eb35f87847659de717002daed@posteo.de> Message-ID: <87y4y4u1s1.fsf@vigenere.g10code.de> On Tue, 13 May 2014 18:58, fizzlifax at posteo.net said: > What for is this campaign manager? - Is this a part of goteo or of > gnupg or somebody else? This is what I had to pay to Sam for his work on the campaign. My friends at the FSFE suggested that I should run a campaign as soon as possible and suggested that I hire Sam to manage it. Sam was a part time employee with the FSFE back than and thus had some spare time. He did the video, wrote blog entries, and managed the Twitter stuff. > another question ist the VAT for about 5212,-- ? The legal entity behind GnuPG is my company g10 code. This is a commercial entity and we have to pay VAT on all donations (19% from the amount we received from Goteo; i.e. without the Goteo and Paypal costs). The VAT we pay on the material procured for the rewards (about 500 Euro) reduces our depth to the tax office (not yet included in the overview). Given that the majority of costs at g10 code are currently my salary, which is not subject to VAT, the VAT issue is indeed a bit unfortunate. There is no easy solution for this; however I am thinking about a solution. > Nevertheless - there are for a for a result of 37270,-- ? Costs in an > amout of 50%! :-( I realized too late that the published costs calculation was not correct from the beginning. For example the Goteo fee was given only at about 50% of the actual value and VAT was completely missing. It was my fault to no ask Sam to have me check the numbers before publishing. Changing them later was not possible. > My question now: Would'nt it be better to put every year some "Index" > in the top of the gnupg-website with the actual need for the runnig > year and beg for direkt donations? That is indeed the plan. But it takes some more time. The campaign helped to raise awareness and allowed me to keep on working on the project. I am currently working with a web guy on a new structure for the site. I am also about to redo the donation page, move it from g10code.com to gnupg.org, and allow for non-Paypal donations. Salam-Shalom, Werner From aaron.toponce at gmail.com Wed May 14 14:29:47 2014 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Wed, 14 May 2014 06:29:47 -0600 Subject: "gpg --with-fingerprint $FILE" is not listing the keyfingerprint in some cases In-Reply-To: <20140514013207.GF62147@bacardi.hollandpark.frase.id.au> References: <20140513231555.GD4493@irc.ae7.st> <20140514013207.GF62147@bacardi.hollandpark.frase.id.au> Message-ID: <20140514122945.GE4493@irc.ae7.st> On Wed, May 14, 2014 at 11:32:07AM +1000, Fraser Tweedale wrote: > This behaviour also occurs for me in 2.0.22. Instead of exporting > the key, you could use --list-keys, which works for me: Yeah, I'm not interesting in running it from the keyring, as I am assuming that the key is not imported, but only the file is available. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: not available URL: From aaron.toponce at gmail.com Wed May 14 14:51:39 2014 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Wed, 14 May 2014 06:51:39 -0600 Subject: "gpg --with-fingerprint $FILE" is not listing the keyfingerprint in some cases In-Reply-To: References: <20140513231555.GD4493@irc.ae7.st> Message-ID: <20140514125138.GF4493@irc.ae7.st> On Tue, May 13, 2014 at 11:30:21PM -0400, David Shaw wrote: > Looks like a bug. Note that on each of the keys that didn't work there is a > direct signature on the key. This is not very common, and is usually used > for a designated revoker (i.e. "I permit so-and-so to revoke my key for me"). > I suspect there is a bug printing the fingerprints on a key from a key file > (rather than from a keyring) for keys with a direct signature. Ah. Interesting. Should I file a proper bug against GnuPG then? -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: not available URL: From rjh at sixdemonbag.org Wed May 14 18:21:36 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 14 May 2014 12:21:36 -0400 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: <1400053631.2723.26.camel@micha137-myAMD-CM1740> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> Message-ID: <53739810.5050409@sixdemonbag.org> > Since the well known agency from Baltimore uses its influence to have > crypto standards coast close to the limit of the brute-forceable, 128 > bit AES will be insecure not too far in the future. No. https://www.gnupg.org/faq/gnupg-faq.html#brute_force From wk at gnupg.org Wed May 14 18:26:31 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 May 2014 18:26:31 +0200 Subject: "gpg --with-fingerprint $FILE" is not listing the keyfingerprint in some cases In-Reply-To: <20140514125138.GF4493@irc.ae7.st> (Aaron Toponce's message of "Wed, 14 May 2014 06:51:39 -0600") References: <20140513231555.GD4493@irc.ae7.st> <20140514125138.GF4493@irc.ae7.st> Message-ID: <87tx8ss4w8.fsf@vigenere.g10code.de> On Wed, 14 May 2014 14:51, aaron.toponce at gmail.com said: > Ah. Interesting. Should I file a proper bug against GnuPG then? Please do that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From aaron.toponce at gmail.com Wed May 14 19:39:51 2014 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Wed, 14 May 2014 11:39:51 -0600 Subject: "gpg --with-fingerprint $FILE" is not listing the keyfingerprint in some cases In-Reply-To: <87tx8ss4w8.fsf@vigenere.g10code.de> References: <20140513231555.GD4493@irc.ae7.st> <20140514125138.GF4493@irc.ae7.st> <87tx8ss4w8.fsf@vigenere.g10code.de> Message-ID: <20140514173947.GK4493@irc.ae7.st> On Wed, May 14, 2014 at 06:26:31PM +0200, Werner Koch wrote: > > Ah. Interesting. Should I file a proper bug against GnuPG then? > > Please do that. Done. https://bugs.g10code.com/gnupg/issue1640 Thanks, -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: not available URL: From rjh at sixdemonbag.org Wed May 14 20:26:16 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 14 May 2014 11:26:16 -0700 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: <5373336C.5070307@digitalbrains.com> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <5373336C.5070307@digitalbrains.com> Message-ID: <20140514112616.Horde.BgyShX_SUZ7GM-tkZs9yUw3@mail.sixdemonbag.org> > I might have to ask Robert how comfortable his new asbestos longjohns are. Rather, as evidenced by my willingness to try and tackle this one. To a first approximation, trust is confidence in the future's predictability. My friends who grew up in dictatorships tell me the uncertainty was far worse than the oppression -- or, more to the point, that pervasive uncertainty is its own unique form of oppression. They didn't know which of their loved ones were reporting on them to the state security forces. They didn't know if the police officer they saw on the street was going to obey the dictator's law or decide his truncheon and gun gave him the right to enact his own law. They didn't... etc., etc. To defend against this, they smiled and moved forwards. Some turned to religion: "God will provide. God will keep me safe." Some turned to optimism: "Tomorrow will be better. I won't get shaken down by the authorities tomorrow." But they all worked to create their own confidence in the predictability of the future, and in so doing managed to keep their psychological health intact. That health helped them prevail against their situation. So, my answer to whether "some things are suspect" or "all things are suspect" is the true state of affairs is this: does it really matter? Regardless of whether "some" or "all" are suspect, a smile and faith in tomorrow seem to be much more important. Don't despair. Tomorrow's looking good. Embrace that, and then you might find the answers to other questions come more easily. :) From sin.trenton at riseup.net Wed May 14 15:35:54 2014 From: sin.trenton at riseup.net (Sin Trenton) Date: Wed, 14 May 2014 15:35:54 +0200 Subject: Future inclusion of Threefish in Gnupg? Message-ID: <5373713A.4030504@riseup.net> Hello everyone, Just out of curiousity, are there any plans for including Threefish into GnuPG? Or does it have to be incorprorated into the OpenPGP standard first and *then* perhaps baked into GnuPG? In simple curiousity and because I have a soft spot for Twofish[1] Sin Trenton [1] Soft spots are also known as chinks in your armour, I know, I know... -- Random notes at https://sintrenton.wordpress.com Twitter: @SinTrenton PGP Key: 0xC233169488515CE5 From ekleog at gmail.com Wed May 14 21:22:26 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Wed, 14 May 2014 21:22:26 +0200 Subject: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography] In-Reply-To: <53739810.5050409@sixdemonbag.org> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> Message-ID: <20140514192226.GA14584@leortable> On Wed, May 14, 2014 at 12:21:36PM -0400, Robert J. Hansen wrote: > > Since the well known agency from Baltimore uses its influence to have > > crypto standards coast close to the limit of the brute-forceable, 128 > > bit AES will be insecure not too far in the future. > > No. > > https://www.gnupg.org/faq/gnupg-faq.html#brute_force I unfortunately have to object to this FAQ article. (Please note I'm not using any information beyond what Wikipedia provides -- and I may be wrong in my undertanding of it.) First, the Margolus-Levitin limit: "6.10^33 ops.J^{-1}.s^{-1} maximum" So, dividing the 2^128 by 6.10^33 gives me a bit less than 57000 J.s (assuming testing an AES key is a single operation). So, that's less than 1min for 1kJ. Pretty affordable, I believe. Then, Landauer's principle: "energy k T ln 2". Again, assuming testing an AES key is a single bit flip, as k is approx. 10^{-23}, this gives an overall energy (per kelvin) of 2^128 . 10^{-23} . ln 2 J.K^{-1}, which is approx. equal to 10^16 J.K^{-1} (overestimated, as k was underestimated). According to Wikipedia still, the lowest temperature recorded on Earth is 10^{-10} K. This makes for a total of 10^6 J, if the computation is done at that temperature. According to http://hypertextbook.com/facts/2009/VickieWu.shtml ; the human body uses approx. 6MJ (ie. 6 . 10^6 J) per day. As a consequence, the process would consume less than a day of a human body. Granted, this is still far from possible : Here I assumed testing an AES key was a single bit flip, and that the computation was entirely done at the coldest temperature ever recorded in a laboratory. Anyway, the former is a not-so-huge constant (ie. less than 10^5, I'm almost sure of that), and multiplying the results by this constant still yields an "imaginably possible" lower bound. And the latter already has been recorded, despite my believing no computation has been done at that temperature, it is still possible in a foreseeable future. So, despite bruteforcing being obviously impossible in this day and age, and most likely impossible in the near future, it seems to me that the following statement is exaggerated: "The results are profoundly silly: it?s enough to boil the oceans and leave the planet as a charred, smoking ruin." The impossibility of bruteforce, to me, lies with current physical computation capabilities, more than with theoretical lower bounds, that are far below current prowesses. Hoping I didn't miscompute, Leo From dshaw at jabberwocky.com Wed May 14 21:40:47 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 14 May 2014 15:40:47 -0400 Subject: Future inclusion of Threefish in Gnupg? In-Reply-To: <5373713A.4030504@riseup.net> References: <5373713A.4030504@riseup.net> Message-ID: <287ECE86-E427-48DB-B3C2-CF95808CEE4C@jabberwocky.com> On May 14, 2014, at 9:35 AM, Sin Trenton wrote: > Hello everyone, > > Just out of curiousity, are there any plans for including Threefish into GnuPG? > Or does it have to be incorprorated into the OpenPGP standard first and *then* perhaps baked into GnuPG? Yes. GnuPG follows the OpenPGP standard, so any new algorithms would need to go through that process first. David From fizzlifax at posteo.net Wed May 14 21:49:57 2014 From: fizzlifax at posteo.net (Fizzlifax) Date: Wed, 14 May 2014 21:49:57 +0200 Subject: Result of the crowdfounding In-Reply-To: <87y4y4u1s1.fsf@vigenere.g10code.de> References: <0953a88eb35f87847659de717002daed@posteo.de> <87y4y4u1s1.fsf@vigenere.g10code.de> Message-ID: <5373C8E5.1020609@posteo.net> Hi Werner, thanks a lot for Your freely explications! - This was really interesting for me... another question ist the VAT for about 5212,-- ? > The legal entity behind GnuPG is my company g10 code. This is a > commercial entity and we have to pay VAT on all donations (19% from the > amount we received from Goteo; i.e. without the Goteo and Paypal costs). > The VAT we pay on the material procured for the rewards (about 500 Euro) > reduces our depth to the tax office (not yet included in the overview). > Given that the majority of costs at g10 code are currently my salary, > which is not subject to VAT, the VAT issue is indeed a bit unfortunate. > There is no easy solution for this; however I am thinking about a > solution. You see here for ex. one important reason for a non profit-Organisation as "juridic subject" of the goals... another one for any- or -bigger donations - would be exoneration of tax for the donator... - so we pay actually twice taxes.. ;-( > I am currently working with a web guy on a new structure for the site. > I am also about to redo the donation page, move it from g10code.com to > gnupg.org, and allow for non-Paypal donations. Next problem we have often seen, when open-Source Projects in reason of private-ownership turned suddenly in closed source...! whats quite annoying after it... Best would be something like a foundation (Stiftung). With the Participation of several gov-institutions there would also be some interesting support for employment however the most problem is still the lazyness and anxious of the peoples to use encryption... or loose the passphrase or even private key... There for I would be happy if there would be a possibilty to involve some identy-card with nfc-able smartphones... - but this is another subject... Nevertheless if foundation there would may be more possibiltities to enlarge the range of security tools...? I think after all NSA-Problems there could be some interest it for outsides of the friends in the west-overseas-countries... Salam Shalom Ralf From rjh at sixdemonbag.org Wed May 14 22:15:40 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 14 May 2014 13:15:40 -0700 Subject: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography] In-Reply-To: <20140514192226.GA14584@leortable> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> Message-ID: <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> > First, the Margolus-Levitin limit: "6.10^33 ops.J^{-1}.s^{-1} maximum" > So, dividing the 2^128 by 6.10^33 gives me a bit less than 57000 J.s > (assuming testing an AES key is a single operation). So, that's less > than 1min for 1kJ. Pretty affordable, I believe. No. But since I'm going to be giving a lot of explanation here about how you're misusing the Landauer Bound, I'm going to leave how you're misusing the Margolus-Levitin Limit as a homework exercise. :) > Again, assuming testing an AES key is a single bit flip It's not. You have to rekey the cipher. This multiplies the energy by about a large factor. To make the math easier, let's call it a million. > According to Wikipedia still, the lowest temperature recorded on Earth is > 10^{-10} K. If you want to run the temperature lower than the ambient temperature of the cosmos (3.2K), you have to add energy to run the heat pump -- and the amount of energy required to run that heat pump will bring your energy usage *above* that which you would've had if you'd just run it in deep space at 3.2K. So multiply your previous estimate by a factor of ten billion, in order to reflect running it at ambient temperature. 10^10 * 10^6 = 10^16. So far your estimate is off by a factor of a thousand trillion. > So, despite bruteforcing being obviously impossible in this day and age, and > most likely impossible in the near future, it seems to me that the following > statement is exaggerated: "The results are profoundly silly: it?s > enough to boil the oceans and leave the planet as a charred, smoking > ruin." Assuming you could do AES in a single bitflip, it would require liberating as heat as a strategic nuclear warhead. Every additional bitflip adds another strategic nuclear warhead. By the time you're flipping 1000 bits for each rekeying, you're basically inflicting World War Three on the earth just to brute-force a cipher. I stand by my predictions of ecological catastrophe if anyone ever brute-forces a 128-bit cipher. From rjh at sixdemonbag.org Wed May 14 22:36:33 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 14 May 2014 13:36:33 -0700 Subject: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography] In-Reply-To: <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> Message-ID: <20140514133633.Horde.sK6esc3AhaU516mO2NUcyw2@mail.sixdemonbag.org> > 10^10 * 10^6 = 10^16. So far your estimate is off by a factor of a > thousand trillion. *Ten* thousand trillion. Sorry, that one's entirely my error. From ekleog at gmail.com Thu May 15 00:11:12 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Thu, 15 May 2014 00:11:12 +0200 Subject: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography] In-Reply-To: <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> Message-ID: <20140514221112.GA15835@leortable> On Wed, May 14, 2014 at 01:15:40PM -0700, Robert J. Hansen wrote: > >First, the Margolus-Levitin limit: "6.10^33 ops.J^{-1}.s^{-1} maximum" > >So, dividing the 2^128 by 6.10^33 gives me a bit less than 57000 J.s > >(assuming testing an AES key is a single operation). So, that's less than > >1min for 1kJ. Pretty affordable, I believe. > > No. But since I'm going to be giving a lot of explanation here about how > you're misusing the Landauer Bound, I'm going to leave how you're misusing > the Margolus-Levitin Limit as a homework exercise. :) Well... Apart from the assumption I stated just below (ie. single bit flip for AES), I cannot begin to think about an error I might have done with this one, apart from misunderstanding Wikipedia's statement that "The processing rate cannot be higher than 6.10^33 operations per second per joule of energy". (I must say I was more confident about the Margolus-Levitin limit than the Landauer bound.) > >Again, assuming testing an AES key is a single bit flip > > It's not. You have to rekey the cipher. This multiplies the energy by > about a large factor. To make the math easier, let's call it a million. You may have noticed that, lower in my message, I stated the factor could be 10^5 and it would not matter much. You're calling it a million, why not? I must admit I thought I overestimated the 10^5 bit flip cost, since I thought AES-128 was like 7 rounds of something like 5 128-bit changeovers, for approx. 5000 ops in total. But I may have mixed up my recollection of AES with another algorithm. Looking up on Wikipedia : Apparently, my evaluation of rounds and changes was little off, but I think your weighty "rekey" operation might be the optimization described, that involved a 4kB table -- but it might be more energy-efficient (or even time-efficient) not to precompute the table if running through lots of different keys. > >According to Wikipedia still, the lowest temperature recorded on Earth is > >10^{-10} K. > > If you want to run the temperature lower than the ambient temperature of the > cosmos (3.2K), you have to add energy to run the heat pump -- and the amount > of energy required to run that heat pump will bring your energy usage > *above* that which you would've had if you'd just run it in deep space at > 3.2K. Sorry for my ignorance, but... if you have enough time to explain me, how do you derive this? > So multiply your previous estimate by a factor of ten billion, in order to > reflect running it at ambient temperature. > > 10^10 * 10^6 = 10^16. So far your estimate is off by a factor of a thousand > trillion. > > >So, despite bruteforcing being obviously impossible in this day and age, and > >most likely impossible in the near future, it seems to me that the following > >statement is exaggerated: "The results are profoundly silly: it?s enough > >to boil the oceans and leave the planet as a charred, smoking ruin." > > Assuming you could do AES in a single bitflip, it would require liberating > as heat as a strategic nuclear warhead. Every additional bitflip adds > another strategic nuclear warhead. By the time you're flipping 1000 bits > for each rekeying, you're basically inflicting World War Three on the earth > just to brute-force a cipher. BTW: AFAICT, a nuclear warhead (depending on the warhead, ofc.) does not release so much energy, it just releases it in a deadly way. So, I stated one could bruteforce at 10^6J (overestimated). You're adding 10^16, for a total of 10^22J. A nuclear reactor generates approx. 1000MW [1], ie. 10^9W. This makes 10^22J every 10^13s. So, 300000 nuclear reactors generate enough energy to bruteforce a key in a year. There are approx. 500 nuclear reactors active on earth (assuming those under construction in 2012 are now built). Actually, counting total energy production (13000 Mtoe [3], so 13000.10^6.11.10^6 Wh, ie. 14.10^16 Wh, that is 5.10^20 J per year), that makes a total of 20 years. Counting only 5000 bit operations per rekey (see upper for details), this "only" makes 1 year. OK, you're right. Sounds like nothing to fear (for the time being, at least -- energy production is steadily increasing). > I stand by my predictions of ecological catastrophe if anyone ever > brute-forces a 128-bit cipher. But I have a few objections of my own about your use of Landauer's principle: * You state the energy would be released (or did I misunderstand?). Wikipedia states it is a "minimum possible amount of energy required to change one bit of information" So no ecological catastrophe (not counting nuclear waste, CO2, etc) * You state it is a lower bound on the energy consumed/generated by bruteforcing. Having a closer look at the Wikipedia page, I just found this sentence: "If no information is erased, computation may in principle be achieved which is thermodynamically reversible, and require no release of heat." I do not know anything about reversible computing. But it seems to me that an AES-performing algorithm does not necessarily have to erase a full bit of information on each flipped bit. Actually, IIUC, flipping a bit is a reversible operation, and so the landauer principle does not apply. And AES being a 1-to-1 mapping (as the data to be decrypted is fixed, it is a 128-bit keyblock -- to -- 128-bit cleartext mapping), it seems to me that AES is theoretically a reversible program (even though our current implementations might not be, as they are 2-to-1 mappings, not knowing the cleartext). So it might be that Landauer's principle just does not apply to AES-128 Please note I'm not saying bruteforce is, or will ever be, technically feasible. I'm just saying your estimate might be a bit too much. (Not saying the FAQ article should be updated either, it makes a wonderful argument to bash people relentlessly talking about bruteforcing.) And, message to everyone reading: Please stop saying "Anyway I'll be dead by then". According to Ray K. (I'm not going to say what I think about him), we are all going to be immortal by 2050 (IIRC). So this is also your problem! (Or you'd better die quick.) Hoping it wasn't such a boring message, as it was already long enough, Leo [1] http://hypertextbook.com/facts/1997/JasminMarin.shtml [2] https://www.euronuclear.org/info/encyclopedia/n/nuclear-power-plant-world-wide.htm [3] http://yearbook.enerdata.net/#energy-primary-production.html From rjh at sixdemonbag.org Thu May 15 01:31:26 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 14 May 2014 19:31:26 -0400 Subject: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography] In-Reply-To: <20140514221112.GA15835@leortable> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> Message-ID: <5373FCCE.1040101@sixdemonbag.org> On 5/14/2014 6:11 PM, Leo Gaspard wrote: > Well... Apart from the assumption I stated just below (ie. single > bit flip for AES), I cannot begin to think about an error I might > have done with this one, apart from misunderstanding Wikipedia's > statement that "The processing rate cannot be higher than 6.10^33 > operations per second per joule of energy". That's why it's a homework problem. >> If you want to run the temperature lower than the ambient >> temperature of the cosmos (3.2K), you have to add energy to run >> the heat pump -- and the amount of energy required to run that >> heat pump will bring your energy usage *above* that which you >> would've had if you'd just run it in deep space at 3.2K. > > Sorry for my ignorance, but... if you have enough time to explain > me, how do you derive this? $dS = \frac{\delta Q}{T}$ The Second Law of Thermodynamics says there ain't no such thing as a free lunch. You want to lower the heat (entropy) in one place, you have to (a) move that entropy elsewhere and (b) pay an entropic price on top of it. If you're moving a million units of entropy from A to B, you're going to be be paying at least a million and one units of energy. That's a gross simplification, but close enough for government work. You want to lower the temperature (heat, entropy, whatever) to 10^-10 K? Okay, fine: pay the price. But you will *always* be paying more than if you were to just run the machine at 3.2K, and that's a consequence of $dS = \frac{\delta Q}{T}$. To put it in terms that we all can understand -- your air conditioner runs on electricity. Moving heat from inside your house to outside requires energy be added to the overall system. The hotter the day, the more energy your air conditioner needs to move the heat around. > BTW: AFAICT, a nuclear warhead (depending on the warhead, ofc.) does > not release so much energy, it just releases it in a deadly way. A one-megaton nuke releases a *petajoule* of energy. That's a lot. When people start using the phrase "peta-" to describe things, I suddenly become very interested in their Health & Safety compliance. This is a petawatt laser. This is a petawatt reactor. This is a petajoule of energy. This is Peta Wilson.[1] (I trust that Ms. Wilson will forgive my asking, "uh, do we have someone certified for operating her, and where's the nearest Health & Safety card?" without getting too, well, petulant.[2] ) [1] http://en.wikipedia.org/wiki/Peta_Wilson [2] http://instantrimshot.com/index.php?sound=rimshot&play=true > * You state the energy would be released (or did I misunderstand?). > Wikipedia states it is a "minimum possible amount of energy required > to change one bit of information" So no ecological catastrophe (not > counting nuclear waste, CO2, etc) You're beginning to make me a little irate here: the Wikipedia page answers this in the second sentence of its first paragraph. "Any logically irreversible manipulation of information ... must be accompanied by a corresponding entropy increase." Key phrase: Entropy increase. Layman's translation: Heat increase. The Landauer Bound gives not just a minimum amount of energy necessary to change a bit of information, but how much heat must be liberated by that computation. And I repeat, this is in the second sentence of the first paragraph of the Wikipedia article... > * You state it is a lower bound on the energy consumed/generated by > bruteforcing. Having a closer look at the Wikipedia page, I just > found this sentence: "If no information is erased, computation may > in principle be achieved which is thermodynamically reversible, and > require no release of heat." Yeah, adiabatic computing. Give me a call as soon as we have an adiabatic computer: I'll be deeply fascinated. Right now that's even more theoretical than quantum computing -- we've actually observed quantum computation in the lab on a small scale, while adiabatic computing is so far a complete no-go, AFAIK. (Then again, it's been a few years since I've dived into the literature on it -- if you can find a paper demonstrating real-world adiabatic, energy- and entropy-free computing, I will be deeply fascinated. I wasn't kidding about that.) > information on each flipped bit. Actually, IIUC, flipping a bit is a > reversible operation, and so the landauer principle does not apply. Look! A bit of information: ___ That's what it was before. Of course, it's now carrying the value '1'. So, tell me: you say bit flips are reversible, so what was the value before it was 1? I promise, I generated these two bits with a fair coin (heads = 0, tails = 1). "Reversible" means "we can recover previous state without guessing." Current computing systems are not reversible. > So it might be that Landauer's principle just does not apply to > AES-128 No. From rjh at sixdemonbag.org Thu May 15 15:14:55 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 15 May 2014 09:14:55 -0400 Subject: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography] In-Reply-To: References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> Message-ID: <5374BDCF.6050601@sixdemonbag.org> On 5/15/2014 8:30 AM, gnupg-users at gnupg.org wrote: > The save of 64 bits to 1 bit loses you 6 bits exponential complexity, > the increase of the expected number of tries increases it again by 1 > bit, so you have saved 2^5 = 32 = 10^1.5 on the numbers Rob gives. When > I'm quickly reading through the calculations, it seems we changed it > from 100 nuclear warheads to only 3, to scan the whole keyspace. Huh: neat! It doesn't surprise me that there are interesting ways to tweak the numbers: my calculation is something that would have to assume vast pretensions of standing just to be considered worthy to go on the back of a bar napkin. :) > The thing I'm saying is: the explanation for taking 10^2 as the amount > of bitflips for a single try doesn't seem convincing. It makes it seem > that you can actually save computation by linearly searching your keyspace. Point. If/when I make a revision of it I'll review it. :) From mwood at IUPUI.Edu Thu May 15 15:25:00 2014 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Thu, 15 May 2014 09:25:00 -0400 Subject: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography] In-Reply-To: <5373FCCE.1040101@sixdemonbag.org> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> Message-ID: <20140515132500.GA5173@IUPUI.Edu> On Wed, May 14, 2014 at 07:31:26PM -0400, Robert J. Hansen wrote: > On 5/14/2014 6:11 PM, Leo Gaspard wrote: [snip] > > * You state it is a lower bound on the energy consumed/generated by > > bruteforcing. Having a closer look at the Wikipedia page, I just > > found this sentence: "If no information is erased, computation may > > in principle be achieved which is thermodynamically reversible, and > > require no release of heat." > > Yeah, adiabatic computing. Give me a call as soon as we have an > adiabatic computer: I'll be deeply fascinated. Right now that's even > more theoretical than quantum computing -- we've actually observed > quantum computation in the lab on a small scale, while adiabatic > computing is so far a complete no-go, AFAIK. > > (Then again, it's been a few years since I've dived into the literature > on it -- if you can find a paper demonstrating real-world adiabatic, > energy- and entropy-free computing, I will be deeply fascinated. I > wasn't kidding about that.) > > > information on each flipped bit. Actually, IIUC, flipping a bit is a > > reversible operation, and so the landauer principle does not apply. > > Look! A bit of information: ___ > > That's what it was before. Of course, it's now carrying the value '1'. > So, tell me: you say bit flips are reversible, so what was the value > before it was 1? I promise, I generated these two bits with a fair coin > (heads = 0, tails = 1). > > "Reversible" means "we can recover previous state without guessing." > Current computing systems are not reversible. I notice that the Wikipedia article refers here to "thermodynamically reversible" which is perhaps not the same thing as computationally reversible. So I looked up "thermodynamically reversible" and found http://www.brighthubengineering.com/thermodynamics/4616-what-are-reversible-and-irreversible-processes/ which gives the interesting summary: thermodynamically reversible processes are theoretical and don't occur in the real world. These seem to live in the same realm with 100% frictionless surfaces and insulation with infinite R-factor. That article seems confused as to whether a reversible process must be infinitely slow or infinitely fast, but Wikipedia says the former: http://en.wikipedia.org/wiki/Reversible_process_%28thermodynamics%29 But I'm way, way out of my depth here so I'll shut up. -- 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 sin.trenton at riseup.net Thu May 15 10:51:08 2014 From: sin.trenton at riseup.net (Sin Trenton) Date: Thu, 15 May 2014 10:51:08 +0200 Subject: Future inclusion of Threefish in Gnupg? In-Reply-To: <287ECE86-E427-48DB-B3C2-CF95808CEE4C@jabberwocky.com> References: <5373713A.4030504@riseup.net> <287ECE86-E427-48DB-B3C2-CF95808CEE4C@jabberwocky.com> Message-ID: <53747FFC.2060600@riseup.net> On 2014-05-14 21:40, David Shaw wrote: > On May 14, 2014, at 9:35 AM, Sin Trenton wrote: > >> Hello everyone, >> >> Just out of curiousity, are there any plans for including Threefish into GnuPG? >> Or does it have to be incorprorated into the OpenPGP standard first and *then* perhaps baked into GnuPG? > > Yes. GnuPG follows the OpenPGP standard, so any new algorithms would need to go through that process first. > > David > > As I suspected. Time to join a lobbying group, then. ;) Thank you. Sin T. From peter at digitalbrains.com Thu May 15 17:44:47 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 15 May 2014 17:44:47 +0200 Subject: GPG's vulnerability to brute force In-Reply-To: References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> Message-ID: <98dbf101dcf483be1ca201773229e6b6@butters.digitalbrains.com> On 2014-05-15 14:30, gnupg-users at gnupg.org wrote: > Leo called it 10^5, Rob called it 10^3. If you save 63 bitflips on a > total of a million, that doesn't change the final numbers in the > least. > Pull out some hairs and you still have a beard: 10^3 - 63 = 10^3. > Incidentally, we went from 100 nuclear warheads to 3 to 1000[3]. Whoops, I mixed up one million and one thousand. Always makes me realise I don't do physics calculations often enough, and feel a bit ashamed :). Let me slightly redo that: Leo called it 10^5, Rob called it 10^6. Let's take the more conservative one for argument's sake. If you save 63 bitflips on a total of one hundred thousand, that doesn't change the final numbers in the least. Pull out some hairs and you still have a beard: 10^5 - 63 = 10^5. Incidentally, we went from 100 nuclear warheads to 3 to 100,000[3]. Peter. [3] Or a million depending on whether 2^128 is better approximated by 10^38 or 10^39, when you're really nitpicking. Which you shouldn't do when discussing exponential complexity. Let's say that with exponential complexity, your fingers are too large to pick a nit. -- 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 Thu May 15 18:23:10 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 15 May 2014 09:23:10 -0700 Subject: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography] In-Reply-To: <20140515132500.GA5173@IUPUI.Edu> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> <20140515132500.GA5173@IUPUI.Edu> Message-ID: <20140515092310.Horde.iBa2QsqJpscHsUI-ryLAhA1@mail.sixdemonbag.org> > I notice that the Wikipedia article refers here to "thermodynamically > reversible" which is perhaps not the same thing as computationally > reversible. So I looked up "thermodynamically reversible" and found At the level we're talking about, the distinction between thermodynamics and computational theory gets a little hazy. Seriously -- we're talking about the deepest magics of math and physics, where in order to get peak efficiency from our CPUs we have to exploit the Bekenstein limits of the event horizons of black holes. So, "perhaps not the same thing" is absolutely true. Perhaps a lot more similar than we think. At this level of theory, things get pretty wacky. I studied quantum computation and quantum information theory some in grad school. My takeaway from it was that by the standards of the field I am basically a dog who's learned to shake hands, sitting at a table listening to Deutsch and Witten and Susskind argue and thinking that I'm really smart just because I can recognize one word every few minutes. Every now and again they look over my way, realize I'm paying attention, say "good boy!" and scratch my ears and I bark and think I'm making a real contribution to the discussion. Yes, I am *that far* out of my depth here -- Scott Aronson I ain't. Please be careful about thinking I'm any kind of an authority here. > which gives the interesting summary: thermodynamically reversible > processes are theoretical and don't occur in the real world. Yep. Second Law again: entropy must always increase, meaning nothing is truly thermodynamically reversible. But if adiabatic computing *did* exist, man, it would be cool -- as I said, if someone's able to demonstrate it I'll be deeply fascinated. (And then I'll try to see if I can leverage it to travel back in time. Because hey, once the Second Law no longer limits you, the world's your oyster.) > That article seems confused as to whether a reversible process must be > infinitely slow or infinitely fast, but Wikipedia says the former: > > http://en.wikipedia.org/wiki/Reversible_process_%28thermodynamics%29 The closer you approach energy-free computing, the slower the process goes -- this is a consequence of several different things, including the Margolus-Levitin theorem, which says that a bit can't be flipped faster than h/4E seconds. The less energy you put in, the slower the flip goes. From rjh at sixdemonbag.org Thu May 15 18:25:40 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 15 May 2014 09:25:40 -0700 Subject: GPG's vulnerability to brute force In-Reply-To: <98dbf101dcf483be1ca201773229e6b6@butters.digitalbrains.com> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> <98dbf101dcf483be1ca201773229e6b6@butters.digitalbrains.com> Message-ID: <20140515092540.Horde.9nfniglUr9GhiEiMs04Sqw8@mail.sixdemonbag.org> > Incidentally, we went from 100 nuclear warheads to 3 to 100,000[3]. So, I can put you down as solidly in the eco-catastrophe camp, then? :) From peter at digitalbrains.com Thu May 15 18:55:08 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 15 May 2014 18:55:08 +0200 Subject: GPG's vulnerability to brute force In-Reply-To: <20140515092540.Horde.9nfniglUr9GhiEiMs04Sqw8@mail.sixdemonbag.org> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> <98dbf101dcf483be1ca201773229e6b6@butters.digitalbrains.com> <20140515092540.Horde.9nfniglUr9GhiEiMs04Sqw8@mail.sixdemonbag.org> Message-ID: On 2014-05-15 18:25, Robert J. Hansen wrote: > So, I can put you down as solidly in the eco-catastrophe camp, then? > :) Oh, definitely. Unless our understanding of computing at the physical limits drastically changes, I think blunt-force cryptanalysis is way better than brute-force. Decryption using a wrench rather than a key; http://xkcd.com/538/ (don't forget the on-hover text!) 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 2014-667rhzu3dc-lists-groups at riseup.net Fri May 16 11:25:36 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 16 May 2014 10:25:36 +0100 Subject: GPG's vulnerability to brute force In-Reply-To: References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> <98dbf101dcf483be1ca201773229e6b6@butters.digitalbrains.com> <20140515092540.Horde.9nfniglUr9GhiEiMs04Sqw8@mail.sixdemonbag.org> Message-ID: <196690674.20140516102536@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 15 May 2014 at 5:55:08 PM, in , Peter Lebbing wrote: > Decryption using a wrench rather than a key; > http://xkcd.com/538/ (don't forget the on-hover text!) I guess I never hovered over the picture before. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net If you save the world too often, it begins to expect it -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlN12Z5XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pdIgEAMWYGgmFIEGuLwk9lR3csrbMzsQ4pGkOhhTS 1dMEeQcVzy07GEqcqaVKSgObh8hKC4W6ws1XfGSNMbexEVQALq98ykpSQDWSAQpK rRry4j8VbKx0PMjxPLMl3MCi+2+Rs6WqbjOQKgBoX+u7k4oEqqjJzazVrO1HYuUO 1Hy/+FZR =x0hL -----END PGP SIGNATURE----- From micha137 at gmx.de Fri May 16 14:37:22 2014 From: micha137 at gmx.de (Michael Anders) Date: Fri, 16 May 2014 14:37:22 +0200 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: References: Message-ID: <1400243842.2722.23.camel@micha137-myAMD-CM1740> On Wed, 2014-05-14 at 22:26 +0200, gnupg-users-request at gnupg.org wrote: > If you want to run the temperature lower than the ambient > temperature > of the cosmos (3.2K), you have to add energy to run the heat pump -- > and the amount of energy required to run that heat pump will bring > your energy usage *above* that which you would've had if you'd just > run it in deep space at 3.2K. Now where did you calculate that from? In fact arriving at a realistic estimate for the energy needed to brute force AES is really hard work. (Besides: Who can say for sure that we cannot get some bits from cryptoanalytic progress(two bits already crumbled). The cracking of DES was indeed a combination of analyzing some bits and the finishing up the rest by brute force.) IMHO you can run the calculations entirely at low temperature, whatever technology you use to get there. Then you only need contact to the warm world once to transmit the result(for negligible effort!). Look at it this way: A hypothetical nuclear organism in the sun might communicate with us about a result we calculate for it in order to crack some stellar cryptosystem. This doesn't force us to heat our computers to 10000 K and burn all this energy needed for calculating at high temperature. We could e.g. communicate the result to that being via pulsed gamma rays.... These discussions tend to get an interesting quasi-religious setting: 1.) We don't have anything other than AES (At least many people think so.) so one type of character says: We don't have anything else so it must be safe and we must defend that conviction against heresy. the other type (me) is equally mazed and says: They don't want to give us anything else, so it must be unsafe. Relying on them is heresy... May be I should switch sides entirely and go with the very practical asbestos longjohns. I really like the picture :-) From rjh at sixdemonbag.org Fri May 16 15:56:55 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 16 May 2014 09:56:55 -0400 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: <1400243842.2722.23.camel@micha137-myAMD-CM1740> References: <1400243842.2722.23.camel@micha137-myAMD-CM1740> Message-ID: <53761927.8050700@sixdemonbag.org> > Now where did you calculate that from? $dS = \frac{\delta Q}{T}$ Second Law of Thermodynamics, which you just broke. Have a nice day. And no, I am not going to explain this further. My reason for this is simple: you need to take college-level courses in differential and integral calculus, partial differential equations, statistics, and statistical physics in order to get in-depth here. This is a mailing list, not the first two years of university. But, just so you don't think I'm pulling this out of nowhere: http://en.wikipedia.org/wiki/Limits_to_computation Look at bullet point two. > IMHO you can run the calculations entirely at low temperature, whatever > technology you use to get there. Then you only need contact to the warm > world once to transmit the result(for negligible effort!). You're entitled to your opinion, but not your own facts. You are claiming you can violate the Second Law. My response: prove it. From tux.tsndcb at free.fr Fri May 16 16:06:03 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Fri, 16 May 2014 16:06:03 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <77181624.186995084.1399629478677.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <1420766566.10747225.1400249163068.JavaMail.root@zimbra33-e6.priv.proxad.net> Hi all, I answer my self, after, many many tests done, in fact it isn't actually possible to do it under sid debian => root cause bug on systemd : Debian Bug report logs - #618862 systemd: ignores keyscript in crypttab link here : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862 Best Regards From rjh at sixdemonbag.org Fri May 16 16:07:25 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 16 May 2014 10:07:25 -0400 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: <1400243842.2722.23.camel@micha137-myAMD-CM1740> References: <1400243842.2722.23.camel@micha137-myAMD-CM1740> Message-ID: <53761B9D.5050103@sixdemonbag.org> > Now where did you calculate that from? Forgot one more reference -- look at Schneier's _Applied Cryptography_, where he talks about the physical limits of the cosmos. He has a physicist's error in his presentation (he's off by a factor of ln 2), but he confirms the Second Law necessity of a heat pump that would offset any benefit from running at a lower temperature. (By "a physicist's error", physicists think of hypothetical computers that run in base e [2.71828], while computer scientists think of real ones that run in base 2. A physicist's hypothetical computer needs kT joules to clear a nat, while a real computer uses kT ln 2 to clear a bit. Schneier's text talks in terms of bits, but he does the math in terms of nats ... which makes a kind of sense, given he has a graduate degree in physics.) Now, can we put this ridiculous talk of "of course we can break the Second Law!" to rest? "If someone points out to you that your pet theory of the universe is in disagreement with Maxwell's equations -- then so much the worse for Maxwell's equations. If it is found to be contradicted by observation -- well, these experimentalists do bungle things sometimes. But if your theory is found to be against the second law of thermodynamics I can give you no hope; there is nothing for it but to collapse in deepest humiliation." -- Arthur Eddington From peter at digitalbrains.com Fri May 16 16:48:10 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 16 May 2014 16:48:10 +0200 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: <1400243842.2722.23.camel@micha137-myAMD-CM1740> References: <1400243842.2722.23.camel@micha137-myAMD-CM1740> Message-ID: <5376252A.90006@digitalbrains.com> On 16/05/14 14:37, Michael Anders wrote: > In fact arriving at a realistic estimate for the energy needed to brute > force AES is really hard work. (Besides: Who can say for sure that we > cannot get some bits from cryptoanalytic progress(two bits already > crumbled). You cannot get bits of cryptanalytic progress for brute-force. Brute-force is by definition completely independent of such things. And nobody here claimed a realistic estimate. All that was claimed was a lower bound. > 1.) We don't have anything other than AES (At least many people think > so.) What does the specific cipher used have to do with anything? Since I don't see where in the thread you replied, I'm not sure if we're still debating quantum cryptography or that we're discussing brute-forcing. Quantum cryptography was only discussed relating either to asymmetric crypto, which AES isn't, or in relation to Grover's algorithm, which is used to brute-force an algo. When brute-forcing, the choice of algorithm is irrelevant by definition. AES is simply used as an example, but the stuff discussed so far would go for any symmetric algorithm with a 128-bit key. Only the number of bitflips per trial would vary, which was never really established anyway, but tentatively put at "quite a lot". 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 rjh at sixdemonbag.org Fri May 16 17:24:54 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 16 May 2014 08:24:54 -0700 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: <5376252A.90006@digitalbrains.com> References: <1400243842.2722.23.camel@micha137-myAMD-CM1740> <5376252A.90006@digitalbrains.com> Message-ID: <20140516082454.Horde.1AeTeSuXFwh7Ma_TQR0YWw2@mail.sixdemonbag.org> > Quantum cryptography was only discussed relating either to asymmetric > crypto, which AES isn't, or in relation to Grover's algorithm, which is > used to brute-force an algo. Peter is correct, but a little clarification may be in order. Grover's is not a brute-forcing algorithm: it's a search algorithm. To turn Grover's into a brute-forcer you treat the entire keyspace as an extremely large database and you're searching through it to find one particular entry -- the key. If you get into more depth in quantum computation you'll see Grover's appear in lots of different contexts. It's an important and fundamental algorithm that has applicability far beyond crypto. Let me repeat: Peter is completely correct. I just want to make sure people understand that although Grover's can be used to help brute-force a cipher, it is not itself a cryptographic algorithm. :) From ab at riseup.net Fri May 16 17:34:53 2014 From: ab at riseup.net (ab) Date: Fri, 16 May 2014 12:34:53 -0300 Subject: Some broken links on the openpgp website Message-ID: <20140516153453.GA18609@-> Hello, i'm new to this list/community so I hope this is the place to report such things. * Links for list pages are broken in https://lists.gnupg.org/: there's a port (8002) in the urls which if you remove will take you to the correct pages. These links are ok in https://www.gnupg.org/documentation/mailing-lists.html * Also, the links to portuguese and japanese gnupg pages are broken in https://www.gnupg.org/documentation/sites.html. Pt seems to not exist anymore, and Jp might be going through some configuration hard times. If this is not the place, can someone point me to the correct place to report these? Thanks for the nice piece of software! ab. From ekleog at gmail.com Sat May 17 01:12:09 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Sat, 17 May 2014 01:12:09 +0200 Subject: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography] In-Reply-To: <5373FCCE.1040101@sixdemonbag.org> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> Message-ID: <20140516231208.GA458@leortable> First: I agree with everything skipped in the quotes. On Wed, May 14, 2014 at 07:31:26PM -0400, Robert J. Hansen wrote: > On 5/14/2014 6:11 PM, Leo Gaspard wrote: > > BTW: AFAICT, a nuclear warhead (depending on the warhead, ofc.) does > > not release so much energy, it just releases it in a deadly way. > > A one-megaton nuke releases a *petajoule* of energy. That's a lot. > When people start using the phrase "peta-" to describe things, I > suddenly become very interested in their Health & Safety compliance. > This is a petawatt laser. This is a petawatt reactor. This is a > petajoule of energy. This is Peta Wilson.[1] Well... A nuclear reactor produces 1GW, and thus produces 1PJ in 10^6 s, that is approx. 11 days 14 hrs. Sure, you may be very interested in Health & Safety compliance of nuclear reactors, but... > > * You state the energy would be released (or did I misunderstand?). > > Wikipedia states it is a "minimum possible amount of energy required > > to change one bit of information" So no ecological catastrophe (not > > counting nuclear waste, CO2, etc) > > You're beginning to make me a little irate here: the Wikipedia page > answers this in the second sentence of its first paragraph. "Any > logically irreversible manipulation of information ... must be > accompanied by a corresponding entropy increase." > > Key phrase: Entropy increase. > > Layman's translation: Heat increase. > > The Landauer Bound gives not just a minimum amount of energy necessary > to change a bit of information, but how much heat must be liberated by > that computation. And I repeat, this is in the second sentence of the > first paragraph of the Wikipedia article... Well... Currently, at a French equivalent of undergrad level (CPGE), we're learning entropy is a theoretical quantity, that has no real-world meaning -- thus not creating heat. Actually, its unit (J.K^{-1}) does seem to validate this interpretation: contrarily to e.g. enthalpy, it's not an energy. Perhaps are we oversimplifying, or perhaps did I completely misunderstand the teachers, but if this is true there is no heat release. OTOH there would be heat absorption through the need to move the entropy out of the system -- provided AES is not reversible (see below for my case against that point). > > information on each flipped bit. Actually, IIUC, flipping a bit is a > > reversible operation, and so the landauer principle does not apply. > > Look! A bit of information: ___ > > That's what it was before. Of course, it's now carrying the value '1'. > So, tell me: you say bit flips are reversible, so what was the value > before it was 1? I promise, I generated these two bits with a fair coin > (heads = 0, tails = 1). Well... If the operation the bit just underwent was a bitflip (and, knowing the bruteforcing circuit, it's possible to know that), the bit was a '0'. I believe I must have misunderstood your challenge! (Or, just coming to my mind: maybe was I unclear: when saying bitflip I did not mean setting a bit, but rather setting its value as 1 - old value.) > "Reversible" means "we can recover previous state without guessing." > Current computing systems are not reversible. I do not state that physically our processors are reversible. I do not even state any processors might ever be, or adiabatic computers might ever exist. I just state the theoretical application going from the set of 128-bit keys to the set of 128-bit cleartexts (with the 128-bit ciphertext fixed) is a bijection (or so I hope -- unless many keys produce the same ciphertext from the same cleartext, which would be an attack on AES and ease bruteforce naturally). As a consequence, I cannot see where a bit of information was lost, and thus where Landauer's bound is supposed to apply. But maybe am I the one lost here! Thanks for your previous and hopefully future answers, Leo From rjh at sixdemonbag.org Sat May 17 02:05:40 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 16 May 2014 20:05:40 -0400 Subject: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography] In-Reply-To: <20140516231208.GA458@leortable> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> <20140516231208.GA458@leortable> Message-ID: <5376A7D4.8090007@sixdemonbag.org> This is the last I will be saying on the subject. I am not interested in teaching a course on thermodynamics. > Well... A nuclear reactor produces 1GW, and thus produces 1PJ in > 10^6 s, that is approx. 11 days 14 hrs. Sure, you may be very > interested in Health & Safety compliance of nuclear reactors, but... But what? This in the same ballpark as you'd get from releasing a half-kilogram of antimatter on the world. It's big. There are no "but..."s about it. > Well... Currently, at a French equivalent of undergrad level (CPGE), > we're learning entropy is a theoretical quantity, that has no > real-world meaning There are two equivalent ways to define entropy, one using thermodynamics and one using statistical mechanics. When using the statistical mechanics definition it's easy to forget you're talking about the real world instead of just juggling around a lot of numbers and probabilities. When using the thermodynamic definition you get your fingers burned and that reminds you you're talking about *thermodynamics* -- how heat moves around in a system. > Well... If the operation the bit just underwent was a bitflip (and, > knowing the bruteforcing circuit, it's possible to know that), the > bit was a '0'. It was actually a 1. The two bits were 1 and 1. Knowing the second value was a 1 is of no help whatsoever in recovering the previous state. The previous state could have been anything. The bit has no memory of what it was before: that information is lost to the universe, and there is a corresponding increase in entropy (heat) associated with it. From peter at digitalbrains.com Sat May 17 10:51:40 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 17 May 2014 10:51:40 +0200 Subject: GPG's vulnerability to brute force In-Reply-To: <20140516231208.GA458@leortable> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> <20140516231208.GA458@leortable> Message-ID: <5377231C.5020303@digitalbrains.com> On 17/05/14 01:12, Leo Gaspard wrote: > Well... If the operation the bit just underwent was a bitflip (and, knowing the > bruteforcing circuit, it's possible to know that), the bit was a '0'. I admit this is beyond my knowledge, but maybe the following is rather intuitive and not too incorrect. "Flipping one bit" is not enough. You don't make any progress toward a solution if you only keep flipping the same bit. At the least, you need to decide to flip which bit. That is also information, information that is not stored in the resultant bit array where you flipped one bit. More in general, I agree with Rob that this is not a physics course, and this is just a thought I had and wanted to share. You can't object to scientific theories on the basis that you did not study them properly. It might have a bit of a Socratic feel to it, but it quite falls short of the real thing. Physics and computation at this level are pretty unintuitive, I think. Maybe my little attempt to introduce some intuition about information content is grossly wrong, and maybe it's a folly to attempt intuition at all. 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 Thu May 15 14:30:55 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 15 May 2014 14:30:55 +0200 Subject: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography] In-Reply-To: <5373FCCE.1040101@sixdemonbag.org> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> Message-ID: (This mail originally got dropped by the list managing software because I had accidentally misused a new webmail plugin. I'm resending it with all original identifiers so it hopefully threads correctly. I'm also completely ignoring section 3.6.6 of RFC 2822, but who cares? ;) ------- I suddenly realised something about Rob's Crypto FAQ[1]. You state that you need 64 bitflips per attempt, because otherwise your attacker can simply adapt his key to the order in which you try them. But to save on those 64 bitflips, you could also simply do the whole keyspace in order[2]. Your expected number of computations does rise from 2^127 to 2^128, because obviously everybody will then use the key 2^128-1, which is the last one you try ;). The save of 64 bits to 1 bit loses you 6 bits exponential complexity, the increase of the expected number of tries increases it again by 1 bit, so you have saved 2^5 = 32 = 10^1.5 on the numbers Rob gives. When I'm quickly reading through the calculations, it seems we changed it from 100 nuclear warheads to only 3, to scan the whole keyspace. However, this whole thing completely falls apart. We were able to save 63 bitflips per trial in exchange for a twofold increase in total work. In the math done in [1], this changes the feel of the numbers radically, because to us, the difference between 3 and 100 is big (it's not when discussing exponential complexity). But that is because (at least) one very large source of bitflips is not looked at: the number of bitflips one trial of a key actually takes. Leo called it 10^5, Rob called it 10^3. If you save 63 bitflips on a total of a million, that doesn't change the final numbers in the least. Pull out some hairs and you still have a beard: 10^3 - 63 = 10^3. Incidentally, we went from 100 nuclear warheads to 3 to 1000[3]. The thing I'm saying is: the explanation for taking 10^2 as the amount of bitflips for a single try doesn't seem convincing. It makes it seem that you can actually save computation by linearly searching your keyspace. Peter. [1] http://sixdemonbag.org/cryptofaq.xhtml#entropy [2] Actually, make that Gray code order, which actually achieves 1 bitflip changes per succession, unlike normal binary encoding. [3] Or 10,000 depending on whether 2^128 is better approximated by 10^38 or 10^39, when you're really nitpicking. Which you shouldn't do when discussing exponential complexity. Let's say that with exponential complexity, your fingers are too large to pick a nit. -- 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 Sat May 17 15:28:33 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 17 May 2014 09:28:33 -0400 Subject: GPG's vulnerability to brute force In-Reply-To: <5377231C.5020303@digitalbrains.com> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> <20140516231208.GA458@leortable> <5377231C.5020303@digitalbrains.com> Message-ID: <53776401.5050104@sixdemonbag.org> > I admit this is beyond my knowledge, but maybe the following is rather > intuitive and not too incorrect. Another way of looking at it: RAM is normally implemented as a flipflop. (The EEs insist on calling them "bi-stable multivibrators," [1] but I think that's just too kinky for a family-friendly mailing list.) The way a flipflop works, the contents are refreshed and/or changed with each clock cycle. Each and every clock, the former contents are replaced with whatever the current state should be. If a bit held 1 before and it holds 1 now, that still counts as a bit erasure for thermodynamic purposes. [1] No, I'm not kidding. See, e.g., http://en.wikipedia.org/wiki/Bistable_multivibrator > Physics and computation at this level are pretty unintuitive, I think. *Very* unintuitive, yeah. You flat-out can't trust your intuition: you have to take refuge in math and physics. To really understand computation at the limits of physics requires general relativity (Riemann geometries, tensors, really high-end calculus), quantum mechanics (matrices, Dirac brakets, eigenvalues, probabilities), computational theory (discrete math, state transforms, etc), statistical entropy, thermodynamic entropy, Shannon entropy, and more. It's hard. I wasn't kidding about this field making me feel like a dog sitting at a table with Ed Witten and David Deutsch. Woof woof. Niels Bohr is supposed to have said anyone who is not shocked by quantum mechanics clearly has not understood it. The same can be said about computational limits. From micha137 at gmx.de Sat May 17 15:49:27 2014 From: micha137 at gmx.de (Michael Anders) Date: Sat, 17 May 2014 15:49:27 +0200 Subject: Gnupg-users Digest, Vol 128, Issue 24 In-Reply-To: References: Message-ID: <1400334567.2898.8.camel@micha137-samsung-ubuntu> > nt-Type: text/plain; charset=ISO-8859-1 > > > Now where did you calculate that from? > > $dS = \frac{\delta Q}{T}$ > > Second Law of Thermodynamics, which you just broke. Have a nice day. > The (cold) system where the calculation is done and the (hot) system the result is transferred only exchange negligible energy and entropy. No oceans to be boiled off. Citing the second law of thermodynamics in this context is wrong. Besides, just citing a physical law and selling that as reasoning is not the way we argue in physics. :-) From peter at digitalbrains.com Sat May 17 18:51:28 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 17 May 2014 18:51:28 +0200 Subject: GPG's vulnerability to brute force In-Reply-To: <53776401.5050104@sixdemonbag.org> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> <20140516231208.GA458@leortable> <5377231C.5020303@digitalbrains.com> <53776401.5050104@sixdemonbag.org> Message-ID: <935c9c2c2b326153a0133d1116a7ae07@butters.digitalbrains.com> On 2014-05-17 15:28, Robert J. Hansen wrote: > Another way of looking at it: RAM is normally implemented as a > flipflop. I think the register bank in a processor is still implemented as flipflops, and all computation ends up there (on a register machine)[1], so your statement is correct in that respect. A register bank is a RAM. However, the word "normally" is not quite apt. What you normally call the RAM of your computer is DRAM, and DRAM is implemented by a charge on a capacitor. This achieves much higher densities on a chip than SRAM, but is also slower. HTH, Peter. [1] Alternatively, in the registers between pipeline stages of the processor. If somebody knows about the latest CPU techniques and disagrees, by all means, enlighten me :). My knowledge pretty much ends at basic pipeline design, and is not up to speed with current CPU technology. -- 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 Sat May 17 19:52:07 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 17 May 2014 13:52:07 -0400 Subject: GPG's vulnerability to brute force In-Reply-To: <935c9c2c2b326153a0133d1116a7ae07@butters.digitalbrains.com> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> <20140516231208.GA458@leortable> <5377231C.5020303@digitalbrains.com> <53776401.5050104@sixdemonbag.org> <935c9c2c2b326153a0133d1116a7ae07@butters.digitalbrains.com> Message-ID: <5377A1C7.9070305@sixdemonbag.org> > However, the word "normally" is not quite apt. What you normally call > the RAM of your computer is DRAM, and DRAM is implemented by a charge on > a capacitor. This achieves much higher densities on a chip than SRAM, > but is also slower. Point, but I think it's equivalent: whether it's a flipflop getting a signal or a microcapacitor that's charging/discharging, in both cases previous state is getting obliterated and the entropic cost accrues. :) Thank you for the correction, though! From rjh at sixdemonbag.org Sat May 17 19:53:18 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 17 May 2014 13:53:18 -0400 Subject: Gnupg-users Digest, Vol 128, Issue 24 In-Reply-To: <1400334567.2898.8.camel@micha137-samsung-ubuntu> References: <1400334567.2898.8.camel@micha137-samsung-ubuntu> Message-ID: <5377A20E.6000704@sixdemonbag.org> > The (cold) system where the calculation is done and the (hot) system the > result is transferred only exchange negligible energy and entropy. Go build this system, demonstrate you can break Landauer, and collect your Nobel. Seriously. From peter at digitalbrains.com Sat May 17 20:09:16 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 17 May 2014 20:09:16 +0200 Subject: GPG's vulnerability to brute force In-Reply-To: <5377A1C7.9070305@sixdemonbag.org> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> <20140516231208.GA458@leortable> <5377231C.5020303@digitalbrains.com> <53776401.5050104@sixdemonbag.org> <935c9c2c2b326153a0133d1116a7ae07@butters.digitalbrains.com> <5377A1C7.9070305@sixdemonbag.org> Message-ID: <1bd05fe7e57e39f0cde8392ea6f56461@butters.digitalbrains.com> On 2014-05-17 19:52, Robert J. Hansen wrote: > Point, but I think it's equivalent: whether it's a flipflop getting a > signal or a microcapacitor that's charging/discharging, in both cases > previous state is getting obliterated and the entropic cost accrues. > :) Absolutely, no argument there. In fact, currently, we can't make transistors work without capacitance, and a flipflop is built of transistors, so the parallels go even further. 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 Sun May 18 13:52:52 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 18 May 2014 13:52:52 +0200 Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <1420766566.10747225.1400249163068.JavaMail.root@zimbra33-e6.priv.proxad.net> References: <1420766566.10747225.1400249163068.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <53789F14.9030608@digitalbrains.com> On 16/05/14 16:06, tux.tsndcb at free.fr wrote: > I answer my self, after, many many tests done, in fact it isn't > actually possible to do it under sid debian => root cause bug on > systemd : That's a pity it doesn't work on sid. I've been meaning to look into this since you brought it up, and I finally made some time to do it. Since I think Sid is a nasty kid who plays much too roughly with my toys, I used Jessie, and it does work there. Looking at the Debian bug, I think they'll fix it. What I would really like, by the way, is if you clicked an unopened encrypted volume in your file manager, and it would prompt for your PIN through pinentry. But that doesn't work yet. Unlocking the root filesystem and other filesystems that are unlocked on boot does work. You can check out what I did on . I haven't tried it on Wheezy yet (I will), but I think it will work there as well. 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 tux.tsndcb at free.fr Sun May 18 14:56:12 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Sun, 18 May 2014 14:56:12 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <53789F14.9030608@digitalbrains.com> Message-ID: <1710957568.16742251.1400417772105.JavaMail.root@zimbra33-e6.priv.proxad.net> Hi Peter, ----- Mail original ----- De: "Peter Lebbing" ?: "tux tsndcb" , gnupg-users at gnupg.org Envoy?: Dimanche 18 Mai 2014 12:52:52 Objet: Re: gnupg smartcard on boot for LUKS on sid debian howto ? On 16/05/14 16:06, tux.tsndcb at free.fr wrote: > I answer my self, after, many many tests done, in fact it isn't > actually possible to do it under sid debian => root cause bug on > systemd : That's a pity it doesn't work on sid. I've been meaning to look into this since you brought it up, and I finally made some time to do it. Since I think Sid is a nasty kid who plays much too roughly with my toys, I used Jessie, and it does work there. Looking at the Debian bug, I think they'll fix it. Many thanks for your return. This Week-end I've done new tests, and the tempory solution than I've applied is to install sysvinit-core that remove systemd-sysv and now under sid debian, keyfile is ok on boot to decrypt LUKS FS, but I haven't already test it with smartcard (just with encrypt keyfile with gpg). Yes this will be probably fix, because it should be on the standard stable Jessie install What I would really like, by the way, is if you clicked an unopened encrypted volume in your file manager, and it would prompt for your PIN through pinentry. But that doesn't work yet. Unlocking the root filesystem and other filesystems that are unlocked on boot does work. Actually the problem for me is on boot. You can check out what I did on . I haven't tried it on Wheezy yet (I will), but I think it will work there as well. I will test this on Jessie and sid (now it's same than Jessie with sysvinit-core). I give you my return ASAP about it. Best Regards From tux.tsndcb at free.fr Sun May 18 18:51:34 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Sun, 18 May 2014 18:51:34 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <1710957568.16742251.1400417772105.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <1006010512.17198596.1400431894797.JavaMail.root@zimbra33-e6.priv.proxad.net> Hi Peter, My first return on jessie, on boot ask me PIN to decrypt but failed, but it is normal, here messages : Performing GPG key decryption Enter Smartcard PIN or passphrase for key /etc/keys/cryptkey.gpg gpg pcsc_establish_context failed : no service (0x8010001d) gpgh card reader not available But it's normal because I use PINPAD reader and I can only use gnupg_ccid driver so pcscd is not installed on my PC. I need to check to use gnupg_ccid instead pcsc on your script Best Regards From nanooq at nanooq.org Sun May 18 20:13:48 2014 From: nanooq at nanooq.org (nanooq) Date: Sun, 18 May 2014 20:13:48 +0200 Subject: Diffie-Hellman Key Establishment Message-ID: <1400436598-sup-3387@cassiopeia.uberspace.de> Hello gnupg-users, how can I look further into how gpg-handles the diffie-hellman key establishment? I would like to use randomness created by shaking a device and introduce this to the key establishment part. I would be very thankful if anyone could point me either to the correct answer or mailinglist. Regards, nanooq From peter at digitalbrains.com Sun May 18 22:04:18 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 18 May 2014 22:04:18 +0200 Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <1006010512.17198596.1400431894797.JavaMail.root@zimbra33-e6.priv.proxad.net> References: <1006010512.17198596.1400431894797.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <53791242.1040002@digitalbrains.com> On 18/05/14 18:51, tux.tsndcb at free.fr wrote: > I need to check to use gnupg_ccid instead pcsc on your script pcscd is not installed in the initramfs :). So your reader should be supported by the internal driver of GnuPG for it to work. You might have noticed you can optionally put a gpg.conf in /etc/keys (or wherever your key is) and it will be copied and used in the initramfs. Good luck, 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 tux.tsndcb at free.fr Sun May 18 22:25:33 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Sun, 18 May 2014 22:25:33 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <53791242.1040002@digitalbrains.com> Message-ID: <837409345.17758748.1400444733785.JavaMail.root@zimbra33-e6.priv.proxad.net> Hi Peter, Thanks for your answer ----- Mail original ----- De: "Peter Lebbing" ?: "tux tsndcb" Cc: gnupg-users at gnupg.org Envoy?: Dimanche 18 Mai 2014 22:04:18 Objet: Re: gnupg smartcard on boot for LUKS on sid debian howto ? On 18/05/14 18:51, tux.tsndcb at free.fr wrote: > I need to check to use gnupg_ccid instead pcsc on your script pcscd is not installed in the initramfs :). So your reader should be supported by the internal driver of GnuPG for it to work. Yes it is support by gnupg_ccid driver You might have noticed you can optionally put a gpg.conf in /etc/keys (or wherever your key is) and it will be copied and used in the initramfs. I will test with it PS : I've done new tests with update-initramfs -u -vv -k all to have verbose generated initramfs, but I see no /etc/keys/secring.gpg or /etc/keys/cryptkey.gpg, is it normal ? but I see well : Calling hook cryptgnupg_sc and Calling hook cryptgnupg_sc Best Regards. From peter at digitalbrains.com Sun May 18 22:31:20 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 18 May 2014 22:31:20 +0200 Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <837409345.17758748.1400444733785.JavaMail.root@zimbra33-e6.priv.proxad.net> References: <837409345.17758748.1400444733785.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <53791898.7060802@digitalbrains.com> On 18/05/14 22:25, tux.tsndcb at free.fr wrote: > PS : I've done new tests with update-initramfs -u -vv -k all to have > verbose generated initramfs, but I see no /etc/keys/secring.gpg or > /etc/keys/cryptkey.gpg, is it normal ? but I see well : Calling hook > cryptgnupg_sc and Calling hook cryptgnupg_sc No, that means something is wrong. It will always call the hook, even when you don't use encrypted volumes at all. But when the hook determines it has nothing to do, it will exit without any messages. So apparently the hook thinks you don't need it to do anything. That's bad, mm'kay. HTH, Peter. PS: Yeah, scripts don't think. I think. I /hope/. I kill those things sometimes. -- 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 Mon May 19 12:32:05 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 May 2014 12:32:05 +0200 Subject: Some broken links on the openpgp website In-Reply-To: <20140516153453.GA18609@-> (ab@riseup.net's message of "Fri, 16 May 2014 12:34:53 -0300") References: <20140516153453.GA18609@-> Message-ID: <87d2fanjoa.fsf@vigenere.g10code.de> On Fri, 16 May 2014 17:34, ab at riseup.net said: > * Links for list pages are broken in https://lists.gnupg.org/: there's a port > (8002) in the urls which if you remove will take you to the correct pages. > These links are ok in https://www.gnupg.org/documentation/mailing-lists.html Boa weirdness: Boa sends a redirect if the URL does not end in a slash. lists.gnupg.org runs Boa on port 8002 behind the pound proxy. Fixed by changing the links; need to implement a better solution, though. > * Also, the links to portuguese and japanese gnupg pages are broken in > https://www.gnupg.org/documentation/sites.html. Pt seems to not exist > anymore, and Jp might be going through some configuration hard times. Noted. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tux.tsndcb at free.fr Mon May 19 18:51:46 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Mon, 19 May 2014 18:51:46 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <53791898.7060802@digitalbrains.com> Message-ID: <907704947.20997680.1400518306846.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello Peter, First good news, as I tell you during initramfs generation, I see no trace for /etc/key/cryptkey.gpg, but this file is obligatory OK because passphrase works on boot (with gpg.conf in /etc/keys) (may be it it's because my test is for /data/test encrypted FS and not /) But I've always : gpg: pcsc_etablish_context failed: no service (0x8010001d) gpg: card reader not evailable may be it's problem on boot with 60-gnupg.rules file ? This file works fine after boot because smartcard redaer works fine. Best Regards From peter at digitalbrains.com Mon May 19 20:01:38 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 19 May 2014 20:01:38 +0200 Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <907704947.20997680.1400518306846.JavaMail.root@zimbra33-e6.priv.proxad.net> References: <907704947.20997680.1400518306846.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <537A4702.2030704@digitalbrains.com> Hello, > First good news, as I tell you during initramfs generation, I see no > trace for /etc/key/cryptkey.gpg, but this file is obligatory OK > because passphrase works on boot (with gpg.conf in /etc/keys) (may be > it it's because my test is for /data/test encrypted FS and not /) Indeed you will only get the messages when it's the root drive you want to unlock. I haven't tested other configurations. I think it ought to work for other volumes that are unlocked on boot. > But I've always : > > gpg: pcsc_etablish_context failed: no service (0x8010001d) gpg: card > reader not evailable > > may be it's problem on boot with 60-gnupg.rules file ? This file > works fine after boot because smartcard redaer works fine. Is your card reader supported by GnuPG's internal CCID driver or do you need pcscd for the smartcard to work? Related question: Is pcscd usually running? As I said, your smartcard reader really needs to be supported by GnuPG's internal driver, it will not work if pcscd is needed. The messages seem to indicate that pcscd is needed. 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 tux.tsndcb at free.fr Mon May 19 20:21:06 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Mon, 19 May 2014 20:21:06 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <537A4702.2030704@digitalbrains.com> Message-ID: <1343593457.21405380.1400523666310.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello Peter ----- Mail original ----- De: "Peter Lebbing" ?: "tux tsndcb" Cc: gnupg-users at gnupg.org Envoy?: Lundi 19 Mai 2014 20:01:38 Objet: Re: gnupg smartcard on boot for LUKS on sid debian howto ? > But I've always : > > gpg: pcsc_etablish_context failed: no service (0x8010001d) gpg: card > reader not evailable > > may be it's problem on boot with 60-gnupg.rules file ? This file > works fine after boot because smartcard redaer works fine. Is your card reader supported by GnuPG's internal CCID driver or do you need pcscd for the smartcard to work? Related question: Is pcscd usually running? As I said, your smartcard reader really needs to be supported by GnuPG's internal driver, it will not work if pcscd is needed. The messages seem to indicate that pcscd is needed. Yes of course, it's for that than I'm very surprise to see pcsc invocated, my smartcard reader is a Vega Alpha supported by gnupg internal drivers, on my debians I don't install pcscd and libccid because it is not necessary, works fine with PINPAD only with gnupg internal drivers with this smartcard reader It's officially confirmed at this link : http://wiki.gnupg.org/CardReader/PinpadInput?highlight=%28vega%29 On debian (jessie and sid) I can sign, encrypt use ssh support and poldi with this reader and my smartcard and use PINPAD fully supported. Best Regards From p.h.delgado at xoxy.net Mon May 19 16:56:18 2014 From: p.h.delgado at xoxy.net (p.h.delgado at xoxy.net) Date: Mon, 19 May 2014 14:56:18 +0000 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: References: Message-ID: <537A1B92.5040803@mail.ru> On 05/13/2014 04:03 PM, David Q. wrote: > For this reason, what I do today is share long keys with people I know *in > person*. We then use regular AES-256 to encrypt/decrypt our messages back > and forth. Every 6 months we meet in person to renew our keys. You are right, but, in my opinion, for the wrong reasons. I agree with the poster above who is quite skeptical about the quantum computing. I do however believe that factoring a product of two large prime numbers might either be the subject of a sudden mathematical breakthrough, or that the solution is already known to my adversaries but this fact has been kept secret. While this view might be somewhat extreme, it is much more realistic than doubt in the security of any modern, well researched symmetric block cipher. Public key cryptography has it's place, but anybody that is in a position to exchange via a secure method a symmetric crypto key, is well advised to avoid public key cryptography. After all, GPG is nothing but a method to exchange a symmetric key for those that lack the opportunity to do so via an alternative, more secure method. Looking at the crypto primitives as the links in a chain that breaks when the weakest link breaks, asymmetric/symmetric hybrids (such as GPG) have three links: public key algorithm, random number generator and private key algorithm. In contrast, symmetric key only systems avoids first two of those potentially weak links altogether. dekgado From rjh at sixdemonbag.org Mon May 19 22:16:38 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 19 May 2014 13:16:38 -0700 Subject: GPG's vulnerability to quantum cryptography In-Reply-To: <537A1B92.5040803@mail.ru> References: <537A1B92.5040803@mail.ru> Message-ID: <20140519131638.Horde.Qk58l-9UrkbhZU539k8IBA1@mail.sixdemonbag.org> > I do however believe that factoring a product of two large > prime numbers might either be the subject of a sudden mathematical > breakthrough, or that the solution is already known to my > adversaries but this fact has been kept secret. tl;dr summary of the rest of this email -- don't focus on factorization, and be careful of thinking about a post-RSA future. I can't comment on this (for the most pedestrian of reasons: I can't predict the future, and if anyone currently knows how to do it they sure haven't told me), but a little commentary might be appropriate: 1. We would like integer factorization to belong to complexity class NP-Complete, but there are good reasons to think it's not. If its NP-Completeness could be proven, then so much of mathematics would be transformed that I'm not sure continued confidence in *anything* involving computers would be warranted. 2. If someone could prove IFP was in P, that would be ... breathtaking, to say the least. Same thing: if it could be proven, that would be such a seismic shift -- and would foment such revolutions in mathematics -- as to jeopardize confidence for years until the repercussions of it were fully understood. 3. If IFP is NP-intermediate, as it's currently conjectured to be, then nothing short of quantum computation will endanger it. 4. But RSA is not the same as the IFP, and Dan Boneh has written a great paper showing that it may be possible to break RSA without needing to factor anything. We don't know how to do it, we don't even have *hints* about how to do it, just a good paper from Dan Boneh showing that it may in fact be possible to do it. But this, too, would be such a breakthrough as to jeopardize confidence, etc., etc. 5. If and when RSA gets broken, all bets are off. From koen.vanimpe at cudeso.be Mon May 19 23:11:05 2014 From: koen.vanimpe at cudeso.be (Koen Van Impe) Date: Mon, 19 May 2014 23:11:05 +0200 Subject: recv-keys on e-mail instead of keyid Message-ID: <537A7369.9060406@cudeso.be> Hi, I have a list of email addresses and I want to query the keyservers if a keyid exists for them. "recv-keys" expects a keyid ... what's the best way to check -scripted?- if a key exists for an email address? Key verification etc. will be done afterwards via OoB. thanks, koen From peter at digitalbrains.com Tue May 20 11:09:13 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 20 May 2014 11:09:13 +0200 Subject: recv-keys on e-mail instead of keyid In-Reply-To: <537A7369.9060406@cudeso.be> References: <537A7369.9060406@cudeso.be> Message-ID: <537B1BB9.8010705@digitalbrains.com> On 19/05/14 23:11, Koen Van Impe wrote: > "recv-keys" expects a keyid ... what's the best way to check -scripted?- > if a key exists for an email address? I think you're looking for the command --search-keys. 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 Tue May 20 11:20:18 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 20 May 2014 11:20:18 +0200 Subject: Diffie-Hellman Key Establishment In-Reply-To: <1400436598-sup-3387@cassiopeia.uberspace.de> References: <1400436598-sup-3387@cassiopeia.uberspace.de> Message-ID: <537B1E52.4000202@digitalbrains.com> On 18/05/14 20:13, nanooq wrote: > how can I look further into how gpg-handles the diffie-hellman key > establishment? What DH key establishment do you mean? Are you referring to ElGamal subkeys? > I would like to use randomness created by shaking a > device and introduce this to the key establishment part. That sounds like random number generation, which is applicable to all secrets, not just DH. I wouldn't trust myself devising a random number generator, though[1]. HTH, Peter. [1] At least, not one I would protect secrets with. One to replace my dice for a board game is fine ;). -- 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 tux.tsndcb at free.fr Tue May 20 16:03:58 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Tue, 20 May 2014 16:03:58 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <537A4702.2030704@digitalbrains.com> Message-ID: <1209409668.24731871.1400594638854.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello Peter, If I done : gpg --card-status --debug-ccid-driver => I have no error, so normaly it is good, isn't it ? and if I done : echo scd getinfo reader_list | gpg-connect-agent --decode | awk '/^D/ {print $2}' answer 0982:0008:000000F5:0 it is well my smartcard reader with my smartcard detected. so do you have an idea with it's wrong on boot ? Here /etc/keys files : -rw-r--r-- 1 root root 769 mai 18 17:43 cryptkey.gpg -rw------- 1 root root 4975 mai 18 18:05 pubring.gpg~ -rw------- 1 root root 4975 mai 18 18:05 pubring.gpg -rw------- 1 root root 5050 mai 18 18:05 secring.gpg -rw------- 1 root root 7807 mai 19 18:29 gpg.conf Here my gpg.conf file : utf8-strings keyserver hkp://keys.gnupg.net auto-key-locate local verbose default-key {YOURKEY} require-cross-certification Do I've missing an option in this gpg.conf file ? Thanks in advanced for your return Best Regard From tux.tsndcb at free.fr Tue May 20 17:28:20 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Tue, 20 May 2014 17:28:20 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <1209409668.24731871.1400594638854.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <1052341767.25114174.1400599700948.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello Peter, More informations may be help you to help me : If I boot on rescue mode, same issue during boot phase : - PIN code wrong (not asked on my smartcard reader, and if I write it on keyborad => wrong) but passphase OK. After boot if I enter on "root" mode after type root password (so console mode). If I type the same commands : gpg --card-status --debug-ccid-driver => I have no error, so normaly it is good, isn't it ? and if I done : echo scd getinfo reader_list | gpg-connect-agent --decode | awk '/^D/ {print $2}' answer 0982:0008:000000F5:0 same good result. If I try : gpg --card-edit admin verify PIN code is well asked on my smartcard reader and works well. So is it possible to add a "debug mod" on your script to have more informations during boot phase ? Thanks in advance for your help Best Regards ----- Mail original ----- De: "tux tsndcb" ?: "Peter Lebbing" Cc: gnupg-users at gnupg.org Envoy?: Mardi 20 Mai 2014 16:03:58 Objet: Re: gnupg smartcard on boot for LUKS on sid debian howto ? Hello Peter, If I done : gpg --card-status --debug-ccid-driver => I have no error, so normaly it is good, isn't it ? and if I done : echo scd getinfo reader_list | gpg-connect-agent --decode | awk '/^D/ {print $2}' answer 0982:0008:000000F5:0 it is well my smartcard reader with my smartcard detected. so do you have an idea with it's wrong on boot ? Here /etc/keys files : -rw-r--r-- 1 root root 769 mai 18 17:43 cryptkey.gpg -rw------- 1 root root 4975 mai 18 18:05 pubring.gpg~ -rw------- 1 root root 4975 mai 18 18:05 pubring.gpg -rw------- 1 root root 5050 mai 18 18:05 secring.gpg -rw------- 1 root root 7807 mai 19 18:29 gpg.conf Here my gpg.conf file : utf8-strings keyserver hkp://keys.gnupg.net auto-key-locate local verbose default-key {YOURKEY} require-cross-certification Do I've missing an option in this gpg.conf file ? Thanks in advanced for your return Best Regard _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From wk at gnupg.org Wed May 21 09:57:28 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 May 2014 09:57:28 +0200 Subject: [Announce] GPGME 1.5.0 released Message-ID: <87d2f71s47.fsf@vigenere.g10code.de> Hello! I am pleased to announce version 1.5.0 of GPGME. GnuPG Made Easy (GPGME) is a C language library that allows to add support for cryptography to a program. It is designed to make access to public key crypto engines as included in GnuPG easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification, and key management. * Noteworthy changes in version 1.5.0 (2014-05-21) - On Unices the engine file names are not not anymore hardwired but located via the envvar PATH. All options to set the name of the engines for the configure run are removed. - If GPGME finds the gpgconf binary it defaults to using gpg2 or whatever gpgconf tells as name for the OpenPGP engine. If gpgconf is not found, GPGME looks for an engine named "gpg". - New feature to use the gpgme I/O subsystem to run arbitrary commands. - New flag to use encryption without the default compression step. - New function to access "gpg-conf --list-dirs" - New configure option --enable-fixed-path for use by Android. - Support ECC algorithms. - Interface changes relative to the 1.4.3 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gpgme_get_dirinfo NEW. gpgme_op_spawn_start NEW. gpgme_op_spawn NEW. GPGME_PROTOCOL_SPAWN NEW. GPGME_SPAWN_DETACHED NEW. GPGME_SPAWN_ALLOW_SET_FG NEW. GPGME_ENCRYPT_NO_COMPRESS NEW. GPGME_PK_ECC NEW. GPGME_MD_SHA224 NEW. gpgme_subkey_t EXTENDED: New field curve. GPGME_STATUS_PLAINTEXT_LENGTH NEW. GPGME_STATUS_MOUNTPOINT NEW. GPGME_STATUS_PINENTRY_LAUNCHED NEW. GPGME_STATUS_ATTRIBUTE NEW. GPGME_STATUS_BEGIN_SIGNING NEW. GPGME_STATUS_KEY_NOT_CREATED NEW. * Download You may download this library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.5.0.tar.bz2 (942k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.5.0.tar.bz2.sig GZIP compressed tarballs are also available: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.5.0.tar.gz (1214k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.5.0.tar.gz.sig As an alternative you may use a patch file to upgrade the previous version of the library: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.3-1.5.0.diff.bz2 (51k) SHA-1 checksums are: 690df6d692be36923b9b28530afb2b4854f2435d gpgme-1.5.0.tar.bz2 3f6d34b4a9a2cce67891fef384f59a0d8ec7a2d5 gpgme-1.5.0.tar.gz 7138547fa8f0ba71810aee4a5a0d3e0612df8c2a gpgme-1.4.3-1.5.0.diff.bz2 * Support Please send questions regarding the use of GPGME to the gnupg-devel mailing list: http://lists.gnupg.org/mailman/listinfo/gnupg-devel/ If you need commercial support, you may want to consult this listing: http://www.gnupg.org/service.html The driving force behind the development of the GnuPG system is my company g10 Code. Maintenance and improvement of GnuPG and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Happy hacking, 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: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Wed May 21 10:47:55 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 May 2014 10:47:55 +0200 Subject: Trust Signature REs In-Reply-To: (Nicholas Cole's message of "Wed, 7 May 2014 18:23:34 +0100") References: Message-ID: <8761kz1ps4.fsf@vigenere.g10code.de> On Wed, 7 May 2014 19:23, nicholas.cole at gmail.com said: > Is there any way to tell gnupg that I am actually entering a raw re > and do not wish it to do any conversion? No. FWIW, here is a comment describing how gpg uses the RE: /* There are basically two commonly-used regexps here. GPG and most versions of PGP use "<[^>]+[@.]example\.com>$" and PGP (9) command line uses "example.com" (i.e. whatever the user specfies, and we can't expect users know to use "\." instead of "."). So here are the rules: we're allowed to start with "<[^>]+[@.]" and end with ">$" or start and end with nothing. In between, the only legal regex character is ".", and everything else gets escaped. Part of the gotcha here is that some regex packages allow more than RFC-4880 requires. For example, 4880 has no "{}" operator, but GNU regex does. Commenting removes these operators from consideration. A possible future enhancement is to use commenting to effectively back off a given regex to the Henry Spencer syntax in 4880. -dshaw */ I have no concerns on adding an option to allow setting an arbitrary RE. The easiest way of implementing this would be by prepending a flag to the prompt. For example Your selection? |raw|<[^>]+[@.]nowhere\.com>$ A leading '|' is not a valid special character nor a valid mailbox or domain character. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From e1ven at e1ven.com Tue May 20 14:56:45 2014 From: e1ven at e1ven.com (Colin Davis) Date: Tue, 20 May 2014 08:56:45 -0400 Subject: Trying to compile gnupg 2.1 on OSX Message-ID: <8AD4BB19-5231-4549-87D7-B1F84B81FB72@e1ven.com> Good Morning, I'm trying to compile/test gnupg git master on OS X 10.9, but I've been running into some difficulty and wondered if anyone might have a word of advice. I'm using automake 1.11.6, and I've pulled the git versions of libgpg-error, libgcrypt, libassuan, libksba, and npth. (The exact config I'm using is available at https://gist.github.com/e1ven/a7f6b04c40fe7b006578) When I try to run make, I get the error- gcc -I/Users/e1ven/tmp/gpg-src/libgcrypt/inst/include -I/Users/e1ven/tmp/gpg-src/libgpg-error/inst/include -I/Users/e1ven/tmp/gpg-src/libassuan/inst/include -I/Users/e1ven/tmp/gpg-src/libgpg-error/inst/include -I/Users/e1ven/tmp/gpg-src/gnupg/../libksba/inst/include -I/Users/e1ven/tmp/gpg-src/libgpg-error/inst/include -g -O2 -O3 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith -lresolv -L/usr/local/Cellar/readline/6.3.5//lib -o t-sexputil t-sexputil.o libcommon.a ../gl/libgnu.a -L/Users/e1ven/tmp/gpg-src/libgcrypt/inst/lib -lgcrypt -L/Users/e1ven/tmp/gpg-src/libgpg-error/inst/lib -lgpg-error -L/Users/e1ven/tmp/gpg-src/libassuan/inst/lib -lassuan -L/Users/e1ven/tmp/gpg-src/libgpg-error/inst/lib -lgpg-error -L/Users/e1ven/tmp/gpg-src/libgpg-error/inst/lib -lgpg-error -liconv Undefined symbols for architecture x86_64: "_default_errsource", referenced from: _parse_ber_header in libcommon.a(libcommon_a-tlv.o) _parse_sexp in libcommon.a(libcommon_a-tlv.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [t-sexputil] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I've tried some simple debugging - Using different versions of the libs, moving from llvm to gcc48, building in 32-bit mode, etc, but I'm not sure where it's getting hung-up. I'm sure I'm doing something foolish in my env, but any pointers would be helpful :/ -CPD From daniel at axtens.net Wed May 21 12:02:14 2014 From: daniel at axtens.net (Daniel Axtens) Date: Wed, 21 May 2014 20:02:14 +1000 Subject: Trying to compile gnupg 2.1 on OSX In-Reply-To: <8AD4BB19-5231-4549-87D7-B1F84B81FB72@e1ven.com> References: <8AD4BB19-5231-4549-87D7-B1F84B81FB72@e1ven.com> Message-ID: <919630E3-1D6D-4B1A-BB93-3295FB717B92@axtens.net> I had this error as well. I eventually fixed it by going with the latest stable version of libgpg-error rather than the git HEAD. Yours, -- d On 20/05/2014, at 10:56 PM, Colin Davis wrote: > Good Morning, > > I'm trying to compile/test gnupg git master on OS X 10.9, but I've been running into some difficulty and wondered if anyone might have a word of advice. > > I'm using automake 1.11.6, and I've pulled the git versions of libgpg-error, libgcrypt, libassuan, libksba, and npth. > (The exact config I'm using is available at https://gist.github.com/e1ven/a7f6b04c40fe7b006578) > > When I try to run make, I get the error- > > gcc -I/Users/e1ven/tmp/gpg-src/libgcrypt/inst/include -I/Users/e1ven/tmp/gpg-src/libgpg-error/inst/include -I/Users/e1ven/tmp/gpg-src/libassuan/inst/include -I/Users/e1ven/tmp/gpg-src/libgpg-error/inst/include -I/Users/e1ven/tmp/gpg-src/gnupg/../libksba/inst/include -I/Users/e1ven/tmp/gpg-src/libgpg-error/inst/include -g -O2 -O3 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith -lresolv -L/usr/local/Cellar/readline/6.3.5//lib -o t-sexputil t-sexputil.o libcommon.a ../gl/libgnu.a -L/Users/e1ven/tmp/gpg-src/libgcrypt/inst/lib -lgcrypt -L/Users/e1ven/tmp/gpg-src/libgpg-error/inst/lib -lgpg-error -L/Users/e1ven/tmp/gpg-src/libassuan/inst/lib -lassuan -L/Users/e1ven/tmp/gpg-src/libgpg-error/inst/lib -lgpg-error -L/Users/e1ven/tmp/gpg-src/libgpg-error/inst/lib -lgpg-error -liconv > Undefined symbols for architecture x86_64: > "_default_errsource", referenced from: > _parse_ber_header in libcommon.a(libcommon_a-tlv.o) > _parse_sexp in libcommon.a(libcommon_a-tlv.o) > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > make[3]: *** [t-sexputil] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > I've tried some simple debugging - Using different versions of the libs, moving from llvm to gcc48, building in 32-bit mode, etc, but I'm not sure where it's getting hung-up. > I'm sure I'm doing something foolish in my env, but any pointers would be helpful :/ > > -CPD > > > > > > > > _______________________________________________ > 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 nicholas.cole at gmail.com Wed May 21 12:54:50 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed, 21 May 2014 11:54:50 +0100 Subject: Trust Signature REs In-Reply-To: <8761kz1ps4.fsf@vigenere.g10code.de> References: <8761kz1ps4.fsf@vigenere.g10code.de> Message-ID: On Wed, May 21, 2014 at 9:47 AM, Werner Koch wrote: > On Wed, 7 May 2014 19:23, nicholas.cole at gmail.com said: > >> Is there any way to tell gnupg that I am actually entering a raw re >> and do not wish it to do any conversion? > > No. > > FWIW, here is a comment describing how gpg uses the RE: > > /* There are basically two commonly-used regexps here. GPG and most > versions of PGP use "<[^>]+[@.]example\.com>$" and PGP (9) > command line uses "example.com" (i.e. whatever the user specfies, > and we can't expect users know to use "\." instead of "."). So > here are the rules: we're allowed to start with "<[^>]+[@.]" and > end with ">$" or start and end with nothing. In between, the > only legal regex character is ".", and everything else gets > escaped. Part of the gotcha here is that some regex packages > allow more than RFC-4880 requires. For example, 4880 has no "{}" > operator, but GNU regex does. Commenting removes these operators > from consideration. A possible future enhancement is to use > commenting to effectively back off a given regex to the Henry > Spencer syntax in 4880. -dshaw */ > > I have no concerns on adding an option to allow setting an arbitrary RE. > The easiest way of implementing this would be by prepending a flag to > the prompt. For example > Dear Werner, Thanks for this. The comment in the code was very helpful, and I used it to construct a way to reverse-engineer the original domain and then feed that back to gpg which works fine. All the same, a leading way to say |raw| would be even better. Best wishes, N. From tux.tsndcb at free.fr Wed May 21 15:24:30 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Wed, 21 May 2014 15:24:30 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <1052341767.25114174.1400599700948.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <1795727735.28864668.1400678670639.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello Peter, Could you tel me what reader you use ? Thanks in advanced. Best Ragards ----- Mail original ----- De: "tux tsndcb" ?: "Peter Lebbing" Cc: gnupg-users at gnupg.org Envoy?: Mardi 20 Mai 2014 17:28:20 Objet: Re: gnupg smartcard on boot for LUKS on sid debian howto ? Hello Peter, More informations may be help you to help me : If I boot on rescue mode, same issue during boot phase : - PIN code wrong (not asked on my smartcard reader, and if I write it on keyborad => wrong) but passphase OK. After boot if I enter on "root" mode after type root password (so console mode). If I type the same commands : gpg --card-status --debug-ccid-driver => I have no error, so normaly it is good, isn't it ? and if I done : echo scd getinfo reader_list | gpg-connect-agent --decode | awk '/^D/ {print $2}' answer 0982:0008:000000F5:0 same good result. If I try : gpg --card-edit admin verify PIN code is well asked on my smartcard reader and works well. So is it possible to add a "debug mod" on your script to have more informations during boot phase ? Thanks in advance for your help Best Regards ----- Mail original ----- De: "tux tsndcb" ?: "Peter Lebbing" Cc: gnupg-users at gnupg.org Envoy?: Mardi 20 Mai 2014 16:03:58 Objet: Re: gnupg smartcard on boot for LUKS on sid debian howto ? Hello Peter, If I done : gpg --card-status --debug-ccid-driver => I have no error, so normaly it is good, isn't it ? and if I done : echo scd getinfo reader_list | gpg-connect-agent --decode | awk '/^D/ {print $2}' answer 0982:0008:000000F5:0 it is well my smartcard reader with my smartcard detected. so do you have an idea with it's wrong on boot ? Here /etc/keys files : -rw-r--r-- 1 root root 769 mai 18 17:43 cryptkey.gpg -rw------- 1 root root 4975 mai 18 18:05 pubring.gpg~ -rw------- 1 root root 4975 mai 18 18:05 pubring.gpg -rw------- 1 root root 5050 mai 18 18:05 secring.gpg -rw------- 1 root root 7807 mai 19 18:29 gpg.conf Here my gpg.conf file : utf8-strings keyserver hkp://keys.gnupg.net auto-key-locate local verbose default-key {YOURKEY} require-cross-certification Do I've missing an option in this gpg.conf file ? Thanks in advanced for your return Best Regard _______________________________________________ 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 peter at digitalbrains.com Wed May 21 20:58:10 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 21 May 2014 20:58:10 +0200 Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <1795727735.28864668.1400678670639.JavaMail.root@zimbra33-e6.priv.proxad.net> References: <1795727735.28864668.1400678670639.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <537CF742.3060104@digitalbrains.com> On 21/05/14 15:24, tux.tsndcb at free.fr wrote: > Could you tel me what reader you use ? I'm sorry that I currently don't have the time to help you properly. I used an SCM SCR3310 while "developing" the scripts, but on my main PC (which I did not use), I use an SCM SPR532. Yesterday, I suddenly realised that your problem might be related to the fact you have a pinpad. The script uses cryptsetup's askpass program to pass a PIN or passphrase to gpg on stdin; perhaps it goes wrong because this is combined with input from a pinpad, which would be an odd way to call gpg. The scripts are pretty simple bash scripts; you could adapt them or try the invocations done in the script from a root terminal and see what they do. Oh, which reminds me. At least on Jessie, the askpass program disables echoing and never re-enables it, so you can't see what you are typing after calling it. (Blindly) type "reset" and press enter to reset your terminal settings, which re-enables character echoing. I suppose it's a bug and should be reported. 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 tux.tsndcb at free.fr Wed May 21 21:41:16 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Wed, 21 May 2014 21:41:16 +0200 (CEST) Subject: gnupg smartcard on boot for LUKS on sid debian howto ? In-Reply-To: <537CF742.3060104@digitalbrains.com> Message-ID: <1873457816.30285467.1400701276053.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello Peter, Don't worry I can understand. I will look your new way, and yes pinpad usage is may be the problem, I will look for that also (but as I have see on rescue mode after boot PINPAD askpass PIN works fine to pinpad, may be and surely the problem is during boot phase). Many thanks again for your time and your new way (I will give you my result test). Best Regards. From kc9cmt at earthlink.net Wed May 21 22:45:39 2014 From: kc9cmt at earthlink.net (Michael B. Harris) Date: Wed, 21 May 2014 15:45:39 -0500 Subject: Thunderbird--Ubuntu 14.04 Message-ID: <537D1073.7080109@earthlink.net> I have not been able to get OpenPGP to work under Ubuntu 14.04, using Thunderbird. Everything in the setup seems correct. I always get an error message when trying to sign outgoing mail. Note: Everything worked fine under Ubuntu 13.1. Any hints or tips? Error Message: key not found or not valid. -- Sincerely; Michael B. Harris Linux User# 1063 From dougb at dougbarton.us Wed May 21 23:53:12 2014 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 21 May 2014 14:53:12 -0700 Subject: Thunderbird--Ubuntu 14.04 In-Reply-To: <537D1073.7080109@earthlink.net> References: <537D1073.7080109@earthlink.net> Message-ID: <537D2048.4040403@dougbarton.us> On 05/21/2014 01:45 PM, Michael B. Harris wrote: > I have not been able to get OpenPGP to work under Ubuntu 14.04, using > Thunderbird. Everything in the > setup seems correct. I always get an error message when trying to sign > outgoing mail. Note: Everything > worked fine under Ubuntu 13.1. Any hints or tips? > > Error Message: key not found or not valid. Working for me on both platforms. Do you have anything unusual in your gpg setup? Are you locating $GNUPGHOME somewhere other than ~/.gnupg ? Can you do things like 'gpg --list-keys ' on the command line? Doug From marete at toshnix.com Thu May 22 15:46:03 2014 From: marete at toshnix.com (Brian Gitonga Marete) Date: Thu, 22 May 2014 16:46:03 +0300 Subject: On composing scrypt and openpgp s2k key stretching for symmetric encryption Message-ID: Hello all! What would be the security effect of generating a 32 byte key from a passphrase using scrypt and then using that as a "passphrase" for openpgp's symmetric encryption (this 32 byte key will of course then be acted upon by openpgp's s2k algorithm). Specifically, can one expect that this will make brute-forcing a symmetric passphrase (theoretically or practically) harder? (Given the same strong passhrase). Please note that I am asking this from an application point of view and not calling for the inclusion of scrypt into the openpgp standard. Thanks! Brian Gitonga Marete, -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijn.list at gmail.com Thu May 22 19:04:30 2014 From: martijn.list at gmail.com (martijn.list) Date: Thu, 22 May 2014 19:04:30 +0200 Subject: How are primary key binding signatures (0x19) handled by gpg? Message-ID: <537E2E1E.2080904@gmail.com> According to RFC 4880 "For subkeys that can issue signatures, the subkey binding signature MUST contain an Embedded Signature subpacket with a primary key binding signature (0x19) issued by the subkey on the top-level key." The sub key of the following key (key ID 0549B8A5640444E6) is valid for signing (RSA Encrypt or Sign) but it does not contain a primary key binding signature: http://pgp.mit.edu/pks/lookup?search=0x0549B8A5640444E6&op=index Enigmail tells me that the sub key is valid for signing. It might be that I misunderstand the requirement but it seems that in this case the key should not be used for signing since it lacks the primary key binding signature. I know that this requirement is relatively recent so it might be that for this key the current behaviour is for backward compatibility reasons. Is there some documentation on how GPG handles signing sub keys without a valid primary key binding signature? Kind regards, Martijn Brinkers From dkg at fifthhorseman.net Thu May 22 19:26:18 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 22 May 2014 13:26:18 -0400 Subject: How are primary key binding signatures (0x19) handled by gpg? In-Reply-To: <537E2E1E.2080904@gmail.com> References: <537E2E1E.2080904@gmail.com> Message-ID: <537E333A.2010006@fifthhorseman.net> On 05/22/2014 01:04 PM, martijn.list wrote: > The sub key of the following key (key ID 0549B8A5640444E6) is valid for > signing (RSA Encrypt or Sign) but it does not contain a primary key > binding signature: > > http://pgp.mit.edu/pks/lookup?search=0x0549B8A5640444E6&op=index The subkey here (0xC2B1EA06E3BD3FC7) does not have any key usage flags subpacket associated with it at all. As a result, it looks like gpg treats it as having all usage flags available. > Enigmail tells me that the sub key is valid for signing. It might be > that I misunderstand the requirement but it seems that in this case the > key should not be used for signing since it lacks the primary key > binding signature. I know that this requirement is relatively recent so > it might be that for this key the current behaviour is for backward > compatibility reasons. Is there some documentation on how GPG handles > signing sub keys without a valid primary key binding signature? So gnupg treats this key as though the signing usage flag is present, but it's not yet clear to me that it's willing to accept signatures or certifications from it in the absence of a cross-certification. gpg(1) suggests that --require-cross-certification is the default, so signature or certifications made by the subkey should be considered invalid. Do you have signature or certification made by that subkey that you can verify with? --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 dshaw at jabberwocky.com Thu May 22 21:41:37 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 22 May 2014 15:41:37 -0400 Subject: How are primary key binding signatures (0x19) handled by gpg? In-Reply-To: <537E2E1E.2080904@gmail.com> References: <537E2E1E.2080904@gmail.com> Message-ID: <879B4251-DB80-45C0-8C38-D09DC96259DA@jabberwocky.com> On May 22, 2014, at 1:04 PM, martijn.list wrote: > According to RFC 4880 > > "For subkeys that can issue signatures, the subkey binding signature > MUST contain an Embedded Signature subpacket with a primary key binding > signature (0x19) issued by the subkey on the top-level key." > > The sub key of the following key (key ID 0549B8A5640444E6) is valid for > signing (RSA Encrypt or Sign) but it does not contain a primary key > binding signature: > > http://pgp.mit.edu/pks/lookup?search=0x0549B8A5640444E6&op=index > > Enigmail tells me that the sub key is valid for signing. It might be > that I misunderstand the requirement but it seems that in this case the > key should not be used for signing since it lacks the primary key > binding signature. I know that this requirement is relatively recent so > it might be that for this key the current behaviour is for backward > compatibility reasons. Is there some documentation on how GPG handles > signing sub keys without a valid primary key binding signature? When verifying a signature from a subkey without a 0x19 binding signature (aka "backsig"), you should get an error: WARNING: signing subkey XXXXXX is not cross-certified please see http://www.gnupg.org/faq/subkey-cross-certify.html for more information and the signature verification will fail. If you own the key in question, you can add a backsig to it via "gpg --edit-key 0549B8A5640444E6" and then "cross-certify". David From wardhan.v.1.0 at gmail.com Fri May 23 11:29:27 2014 From: wardhan.v.1.0 at gmail.com (war.dhan) Date: Fri, 23 May 2014 14:59:27 +0530 Subject: does gpg & gpg2 use same gpg.conf file in home directory & what are the best practices to create gpg2 signature ? Message-ID: <537F14F7.40504@gmail.com> hi all, i have sent an e-mail to debian-users for generating a new key. a member has suggested to ask directly here. herewith i am sending the e-mail without any much modifications. i am using up to date debian sid. i am planning to create a gpg2 key. i have googled and read some articles & ideas on the web. i have some comprehensions & doubts about creation & use of gpg2 key. i request members to provide your valuable advice & suggestions & if possible warnings [1] i have 2 packages in my system : gnupg 1.4.16-1.1 & gnupg2 2.0.22-3. there is no .gnupg directory. should i create a ~/.gnupg directory along with gpg.conf with the configuration given at [0]. [2] does creation of directory & config file before creation of gpg2 key pose any issues ? i mean when i start to create key, does gpg2 look into my home directory for config file ? [3] does the configuartion file will through up any errors if i try to create a signature [ god forbid ] with gnupg 1.4 version ? [4] do i need to absolutely create another singing only key as mentioned at [1], the link is not more than year old but it seems to be author is creating a key suing gpg 1.4. is creation of a single key with gpg2 is enough ? [5] should i simply follow the advice for creating keys given at [3] ? it makes sense after reading the comment at [4] about " It turns out there is some UK legislation whereby folks are compelled to give a copy of private keys to the UK government if they are used for signatures." [6] i am concerned about the comment "Why a 4096b key? I have had interoperability problems with keys that size in the past so usually do not use more than 2048b. Is there an RSA 2048b compromise you are aware of or are you just being through?" on link [4]. the comment is almost 4 years old & is this still relevant today ? usually adopt the highest number if given a choice blindly. [7] does the article at [5] about "OpenPGP Key IDs are not useful" apply to gpg2 also ? [8] the most important : does merely pasting the of paperkey -v --output printable.txt --secret-key backup.secret a2ps -2 --no-header -o printable.ps printable.txt in email signature or email body is enough for cryptographically protecting ? [0] https://we.riseup.net/riseuplabs+paow/openpgp-best-practices [1] https://alexcabal.com/creating-the-perfect-gpg-keypair/https://alexcabal.com/creating-the-perfect-gpg-keypair/ [3] http://blog.bofh.it/debian/id_437 [4] http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/ [5] https://www.debian-administration.org/users/dkg/weblog/105 regards, war.dhan p.s. please c.c. me. i am not subscribed to mailing list. From tux.tsndcb at free.fr Fri May 23 13:06:04 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Fri, 23 May 2014 13:06:04 +0200 (CEST) Subject: does gpg & gpg2 use same gpg.conf file in home directory & what are the best practices to create gpg2 signature ? In-Reply-To: <537F14F7.40504@gmail.com> Message-ID: <313929820.36693080.1400843164632.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello war, Yes gpg and gpg2 use the same gpg.conf file, the .gnupg directory will be created on your fist usage gpg or gpg2. On debian, the first time you use it a generic gpg.conf file is also generated. Do you use a smartcard ? or do you want to use one ? You can first look at this link : http://www.bootc.net/archives/2013/06/07/generating-a-new-gnupg-key/, seems a pretty good fist guide. Best Regards From wardhan.v.1.0 at gmail.com Fri May 23 13:40:06 2014 From: wardhan.v.1.0 at gmail.com (war.dhan) Date: Fri, 23 May 2014 17:10:06 +0530 Subject: does gpg & gpg2 use same gpg.conf file in home directory & what are the best practices to create gpg2 signature ? In-Reply-To: <313929820.36693080.1400843164632.JavaMail.root@zimbra33-e6.priv.proxad.net> References: <313929820.36693080.1400843164632.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <537F3396.3030800@gmail.com> On Friday 23 May 2014 04:36 PM, tux.tsndcb at free.fr wrote: > Hello war, > > Yes gpg and gpg2 use the same gpg.conf file, the .gnupg directory will be created on your fist usage gpg or gpg2. > > On debian, the first time you use it a generic gpg.conf file is also generated. > > Do you use a smartcard ? or do you want to use one ? hi tux, right now i am concerned about creating a proper key with best settings or any inherent flaws. i don't use a smartcard. but i will decide about after sometime. i have bookmarked the url & will look into on saturday or sunday. thank you. > > You can first look at this link : http://www.bootc.net/archives/2013/06/07/generating-a-new-gnupg-key/, seems a pretty good fist guide. > > Best Regards > From tux.tsndcb at free.fr Fri May 23 14:00:10 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Fri, 23 May 2014 14:00:10 +0200 (CEST) Subject: does gpg & gpg2 use same gpg.conf file in home directory & what are the best practices to create gpg2 signature ? In-Reply-To: <537F3396.3030800@gmail.com> Message-ID: <1340041959.36865803.1400846410046.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello War, Don't worry, part 5 to 8 and are commun for without or with smartcard GunPG key. Part 9 is only for smartcard but don't forgot part 10. Creating a revocation certificate Good reading. Best Regards From rjh at sixdemonbag.org Sun May 25 10:06:12 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 25 May 2014 04:06:12 -0400 Subject: Hotplate Message-ID: <5381A474.2060905@sixdemonbag.org> Over this Memorial Day weekend I've got two major priorities -- one is to add something to the FAQ regarding certificate generation, and the other is to force myself to learn JavaFX [1]. Anyway. I figured to use recent heated -- pardon the pun -- discussions on this list as fodder for a small excursion into JavaFX, and Hotplate is the result. It's a small app that will let you toy around with different numbers and see how they, the Landauer bound, and the Margolus-Levitin limit, affect the time and heat required to brute-force a 128-bit cipher. If you're interested in looking at it, the very first thing you should do is visit http://java.com to get the latest version of the Java virtual machine. Once that's taken care of, you have two choices: 1. Hit http://sixdemonbag.org/Hotplate.jnlp and launch the application through Java Web Start. [2] 2. Download it from http://sixdemonbag.org/Hotplate.jar and double-click to execute. The application is signed in accordance with Java's normal practices. If you get a warning about an invalid signature, don't run it. If you don't trust Java's signing process, you can download a GnuPG-generated clearsig from http://sixdemonbag.org/Hotplate.jar.asc . Full source code is included inside the jarfile, and the entire thing is contributed to the public domain. Enjoy. [1] Not that I'm particularly keen on it, mind you, but the first question hiring managers ask in the DC metro area is, "Are you up with the latest Java technologies?" It pays to learn it just so you can get hired for a job where you'll never use it. [2] Probably the simplest, but not exactly recommended. Java Web Start is a pretty effective malware vector. But if you've got it installed already, well... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From ekleog at gmail.com Sun May 25 12:56:33 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Sun, 25 May 2014 12:56:33 +0200 Subject: GPG's vulnerability to brute force In-Reply-To: <5377231C.5020303@digitalbrains.com> References: <1400053631.2723.26.camel@micha137-myAMD-CM1740> <53739810.5050409@sixdemonbag.org> <20140514192226.GA14584@leortable> <20140514131540.Horde.s1KxOqcBLZl723f9FqUKVg7@mail.sixdemonbag.org> <20140514221112.GA15835@leortable> <5373FCCE.1040101@sixdemonbag.org> <20140516231208.GA458@leortable> <5377231C.5020303@digitalbrains.com> Message-ID: <20140525105633.GA8373@leortable> On Sat, May 17, 2014 at 10:51:40AM +0200, Peter Lebbing wrote: > You can't object to scientific theories on the basis that you did not > study them properly. It might have a bit of a Socratic feel to it, but > it quite falls short of the real thing. Just for the record: I do not feel like I ever objected to a scientific theory on the basis I did not study it properly. I merely object*ed* to Robert's interpretation of them, stating that my objections might be invalid due to my incomplete study of the underlying theories (which turned out to be the case). Thanks for the discussion, Leo From tim at piratemail.se Sun May 25 17:44:17 2014 From: tim at piratemail.se (tim at piratemail.se) Date: Sun, 25 May 2014 11:44:17 -0400 (EDT) Subject: Hotplate Message-ID: <62e589c8-f5f0-cfe6-ad1c-e2a4d9603343@piratemail.se> While this is definitely, definitely, definitely off topic. I, for one, am looking forward to the absolute demise of java. http://zerovm.org and NaCL in general. LLVM -> .p(ortable)exe -> exe in sandbox. The LLVM revolution is coming!! ;-P -tim From tux.tsndcb at free.fr Sun May 25 20:57:09 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Sun, 25 May 2014 20:57:09 +0200 (CEST) Subject: what hardware entropy usb key equivalent Simtec entropy key take ? In-Reply-To: <405770632.5474621.1401043712844.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <844729100.5492749.1401044229910.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello alls, As you know it is not more possible to buy a Simtec entropy usb key since many years, so my question what hardware entropy usb key do you recommend now to replace it (not too expensive) ? PS: need to be compatible with GNU Linux / Debian Thanks in advanced for your return. Best Regards From pete at heypete.com Sun May 25 21:33:30 2014 From: pete at heypete.com (Pete Stephenson) Date: Sun, 25 May 2014 21:33:30 +0200 Subject: what hardware entropy usb key equivalent Simtec entropy key take ? In-Reply-To: <844729100.5492749.1401044229910.JavaMail.root@zimbra33-e6.priv.proxad.net> References: <405770632.5474621.1401043712844.JavaMail.root@zimbra33-e6.priv.proxad.net> <844729100.5492749.1401044229910.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: http://ubld.it/products/truerng-hardware-random-number-generator/ seems to be the closest I've seen in regards to a "USB stick" form factor and price. It doesn't use the ekeyd daemon for adding entropy to the pool, but rather shows up as a virtual serial port and one can use rngd to feed that data into the kernel pool. I have no personal experience with that product, but it would seem that even if the entropy source was compromised in some way, that would not be a major issue -- rngd does tests to detect biasing (which admittedly won't catch more subtle manipulation) and /dev/random would stir the pool with entropy from various sources, so it can only help. While not a direct, drop-in replacement for the Entropy Key, I found that a Raspberry Pi and it's internal hardware random number generator makes a good source. The internal HWRNG in the Pi is extremely fast (>700kbps). I've not personally setup a Pi to share entropy over the network, but I'd imagine this is something that could be reasonably done. I only have the HWRNG generating entropy for local use. Anyone have experience with a network setup? In regards to getting the Pi's HWRNG setup, http://vk5tu.livejournal.com/43059.html has all the details. It's basically three steps: 1. Add "bcm2708_rng" to /etc/modules, then run "modprobe bcm2708_rng" to activate the module. 2. Install the rng-tools package. 3. Edit /etc/defaults/rng-tools to access the HWRNG and feed the kernel pool. My /etc/defaults/rng-tools file looks a bit different than that of the previously-mentioned website. Here's the relevant lines from my file: ### #Specify the HWRNG device HRNGDEVICE=/dev/hwrng # Check the kernel entropy pool once per second, and add HW-generated entropy if it drops below 90%. # You can change these values to whatever you feel would work best for you. RNGDOPTIONS="--fill-watermark=90% --feed-interval=1" ### Please note this assumes that the HWRNG has not been subverted, broken, or doing something unexpected. I hope this helps. Cheers! -Pete On Sun, May 25, 2014 at 8:57 PM, wrote: > Hello alls, > > As you know it is not more possible to buy a Simtec entropy usb key since many years, so my question what hardware entropy usb key do you recommend now to replace it (not too expensive) ? > > PS: need to be compatible with GNU Linux / Debian > > Thanks in advanced for your return. > > Best Regards > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Pete Stephenson From ndk.clanbo at gmail.com Sun May 25 22:26:30 2014 From: ndk.clanbo at gmail.com (NdK) Date: Sun, 25 May 2014 22:26:30 +0200 Subject: what hardware entropy usb key equivalent Simtec entropy key take ? In-Reply-To: <844729100.5492749.1401044229910.JavaMail.root@zimbra33-e6.priv.proxad.net> References: <844729100.5492749.1401044229910.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <538251F6.9080205@gmail.com> Il 25/05/2014 20:57, tux.tsndcb at free.fr ha scritto: > As you know it is not more possible to buy a Simtec entropy usb key since many years, so my question what hardware entropy usb key do you recommend now to replace it (not too expensive) ? > PS: need to be compatible with GNU Linux / Debian You could use gnuk (includes 'quite' secure openpgp card), or only its TRNG NeUg: http://www.fsij.org/gnuk/neug_version1_0 Readily available on seeedstudio (pre-programmed with gnuk, if you only want NeUg you need to flash it yourself). Hope it helps. BYtE, Diego. From tux.tsndcb at free.fr Mon May 26 09:08:32 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Mon, 26 May 2014 09:08:32 +0200 (CEST) Subject: what hardware entropy usb key equivalent Simtec entropy key take ? In-Reply-To: <538251F6.9080205@gmail.com> Message-ID: <1054272374.6724422.1401088112011.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello Diega, Yes it will be probably only for entropy because I use my smartcards GnuPG with PINPAD smartcard card reader and actualy I don't want to use it without PINPAD. I haven't see than you can use it only for Random, I will look more and price is not so expensive. Thanks for the information Best Regards From tux.tsndcb at free.fr Mon May 26 14:26:00 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Mon, 26 May 2014 14:26:00 +0200 (CEST) Subject: Reiner SCT Cyberjack go : Display languge question In-Reply-To: <104365003.7867798.1401106645999.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <1333997266.7892950.1401107160725.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello all, I wanted to know, if people who use this cardreader have english language on display. Because on display I've done this configuration : Menu -> Setting -> Language -> German >English I've selected it but all display messages are in German for exemple when cardreader boot and a smartcard is plug on it : Bitte Karte entnehmen so no in English Other questions : - On display I can see in permanence : Secoder 2 V2.2.1, is it possible to don't see It ? - On my Vega cardreader, when I use it, I can see these : - When no smartcard insert : Insert card - when PIN code is requested : Enter PIN 3 retries left - when I don't put PIN code on time Time Out But with this cardreader I see nothing only PIN when PIN code is requested and nothing for the other things Thanks in advance for your feeback with it. Best Regards From web.development at tcsw.org.uk Mon May 26 15:06:40 2014 From: web.development at tcsw.org.uk (Web Development) Date: Mon, 26 May 2014 13:06:40 +0000 Subject: Cannot configure GPG Message-ID: Hi All, I have been trying to setup GPG. I created the both the keys and uploaded the pubring.gpg to the open athens too. Now when I try to add a user via an ASP site no error comes up but no user is added to the athens. Also it sends me an error saying "The submitted file does not appear to contain encrypted data." via Email. Can anyone help. I have been trying to fix this for a couple of days. Thanks in advance Aby ##################################################################################### Scanned by MailMarshal - M86 Security's comprehensive email content security solution. ##################################################################################### ********************************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email by mistake, please advise the sender immediately by using the reply facility in your email software. Please destroy and delete the message from your computer. Any modification of the contents of this email is strictly prohibited unless expressly authorised by the sender. Although we have taken steps to ensure that this email and attachments are free from any virus, please note no responsibility is accepted by The College of Social Work in this regard and it is for the recipient to carry out such virus and other checks as it considers appropriate to protect its systems and data. *********************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From winniepuul at yahoo.co.uk Tue May 27 11:26:34 2014 From: winniepuul at yahoo.co.uk (winifred quartey-papafio) Date: Tue, 27 May 2014 10:26:34 +0100 (BST) Subject: GnuPG class throwing null pointer exception Message-ID: <1401182794.3884.YahooMailNeo@web171805.mail.ir2.yahoo.com> Hello I'm having a problem encrypting a String text using the GnuPG class. I'm using the encrypt and decrypt class from?http://www.macnews.co.il/mageworks/java/gnupg/sample-code.shtml which is based on the GnuPG class from?http://lists.gnupg.org/pipermail/gnupg-devel/2002-February/018098.html. However I keep getting a null pointer exception. I don't know what I'm doing wrong. I'd appreciate your help with this this is my code: GnuPG pgp = new GnuPG (); result = pgp.encrypt (text, keyID);and this is what throws the null pointer exception in the GnuPG class:public void encrypt(String str, String rcpt) { System.out.print("Encrypting... "); try { p= Runtime.getRuntime().exec(("gpg --armor --batch --encrypt -r "+ rcpt).split("\\s+")); } catch (IOException io) { System.out.println("Error creating process."); } ProcessStreamReader psr_stdout = new ProcessStreamReader("STDIN", p.getInputStream()); ProcessStreamReader psr_stderr = new ProcessStreamReader("STDERR", p.getErrorStream()); .... } -------------- next part -------------- An HTML attachment was scrubbed... URL: From ranshalit at gmail.com Tue May 27 17:53:38 2014 From: ranshalit at gmail.com (ran) Date: Tue, 27 May 2014 08:53:38 -0700 (PDT) Subject: SDD protocol Message-ID: <1401206017986-36500.post@n7.nabble.com> Hi, I have reviewed the faq for GnuPG, but couldn't find the answer so I post the next question... Is SDD protocol supported with GnuPG ? (I see in specification notes that SDA is supported, but no mention of SDD). Thanks! Ran -- View this message in context: http://gnupg.10057.n7.nabble.com/SDD-protocol-tp36500.html Sent from the GnuPG - User mailing list archive at Nabble.com. From rjh at sixdemonbag.org Wed May 28 01:07:30 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 27 May 2014 19:07:30 -0400 Subject: GnuPG class throwing null pointer exception In-Reply-To: <1401182794.3884.YahooMailNeo@web171805.mail.ir2.yahoo.com> References: <1401182794.3884.YahooMailNeo@web171805.mail.ir2.yahoo.com> Message-ID: <53851AB2.7080004@sixdemonbag.org> On 5/27/2014 5:26 AM, winifred quartey-papafio wrote: > I'm having a problem encrypting a String text using the GnuPG class. I'm > using the encrypt and decrypt class > from http://www.macnews.co.il/mageworks/java/gnupg/sample-code.shtml > which is based on the GnuPG class > from http://lists.gnupg.org/pipermail/gnupg-devel/2002-February/018098.html. First, that code is kind of ... ouch. "Bug-ridden" may be an understatement. Take a look at, e.g., how it reads data from GnuPG: class ProcessStreamReader extends Thread { StringBuffer stream; InputStreamReader in; final static int BUFFER_SIZE = 1024; ProcessStreamReader(InputStream in) { super(); this.in = new InputStreamReader(in); this.stream = new StringBuffer(); } public void run() { try { int read; char[] c = new char[BUFFER_SIZE]; while ((read = in.read(c, 0, BUFFER_SIZE - 1)) > 0) stream.append(c, 0, read); if (read < BUFFER_SIZE - 1) break; } } catch (IOException io) { } } String getString() { return stream.toString(); } } So let's say you've got this thread running, and it's cheerfully spinning along adding data to stream. While it's doing this, you call its getString() method... and bam, immediate race condition, because the call to stream.append() is neither atomic nor locked by a mutex, and there's no guarantee that when you read the stream's contents the stream will be in a consistent state! On top of that, getString() really should clear the contents of stream prior to return. Otherwise if you get "abc" the first time you call getString(), the second time you won't get "def" -- you'll get "abcdef". On top of *that*, this thread will quite possibly bail out before it's finished reading data. It loops *fast* -- there's not a single sleep() call in there -- and as soon as it receives less than a full buffer of data, it assumes there's no more and bails out, rather than thinking, "gee, maybe the other end of this communication channel is delayed for disk I/O or somesuch." So, yeah. I would be wary of using this code in a production environment. It does not appear to be ready. > However I keep getting a null pointer exception. I don't know what I'm > doing wrong. I'd appreciate your help with this Happy to help. The first question is, what OS are you running it on, and where is GnuPG located on your machine? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed May 28 02:15:29 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 27 May 2014 20:15:29 -0400 Subject: GnuPG class throwing null pointer exception In-Reply-To: <53851AB2.7080004@sixdemonbag.org> References: <1401182794.3884.YahooMailNeo@web171805.mail.ir2.yahoo.com> <53851AB2.7080004@sixdemonbag.org> Message-ID: <53852AA1.3060501@sixdemonbag.org> On 5/27/2014 7:07 PM, Robert J. Hansen wrote: > So let's say you've got this thread running, and it's cheerfully > spinning along adding data to stream. While it's doing this, you call > its getString() method... and bam, immediate race condition, because the > call to stream.append() is neither atomic nor locked by a mutex, and > there's no guarantee that when you read the stream's contents the stream > will be in a consistent state! Mea culpa: someone just pointed out to me that as of Java 7, StringBuffer is innately threadsafe and all the accessors/modifiers are locked in synchronized blocks. However, since this code dates back to the Java 1.4 error, it would be an error under the JVM spec that existed then. My error -- thanks to the (wishing-anonymity) person who corrected me! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Wed May 28 05:01:48 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 27 May 2014 23:01:48 -0400 Subject: GnuPG class throwing null pointer exception In-Reply-To: <1401182794.3884.YahooMailNeo@web171805.mail.ir2.yahoo.com> References: <1401182794.3884.YahooMailNeo@web171805.mail.ir2.yahoo.com> Message-ID: <5385519C.5040703@guardianproject.info> You might consider using gnupg-for java, we've put a lot of work into it recently since it is the basis for GnuPG for Android: https://github.com/guardianproject/gnupg-for-java .hc On 05/27/2014 05:26 AM, winifred quartey-papafio wrote: > Hello > I'm having a problem encrypting a String text using the GnuPG class. I'm using the encrypt and decrypt class from http://www.macnews.co.il/mageworks/java/gnupg/sample-code.shtml which is based on the GnuPG class from http://lists.gnupg.org/pipermail/gnupg-devel/2002-February/018098.html. However I keep getting a null pointer exception. I don't know what I'm doing wrong. I'd appreciate your help with this > > > this is my code: > GnuPG pgp = new GnuPG (); result = pgp.encrypt (text, keyID);and this is what throws the null pointer exception in the GnuPG class:public void encrypt(String str, String rcpt) { System.out.print("Encrypting... "); try { > p= Runtime.getRuntime().exec(("gpg --armor --batch --encrypt -r "+ rcpt).split("\\s+")); } catch (IOException io) { System.out.println("Error creating process."); } ProcessStreamReader psr_stdout = new ProcessStreamReader("STDIN", p.getInputStream()); ProcessStreamReader psr_stderr = new ProcessStreamReader("STDERR", p.getErrorStream()); > .... > } > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From tux.tsndcb at free.fr Thu May 29 10:03:52 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Thu, 29 May 2014 10:03:52 +0200 (CEST) Subject: Reiner SCT Cyberjack go : Display languge question In-Reply-To: <1333997266.7892950.1401107160725.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <1508751977.17746631.1401350632465.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello All, Here the official Renier SCT support answer : "This product is mainly developed for German market, therefore it is necessary to keep the Secoder2 specs. All PIN messages are definied there, so they will ALWAYS be in German. The cardreader are primary for German Market, so the language will be German. It is not possible to use English Secoder2 text. And we will and can not change this." It's very shame, because if this company done a little effort to translate display messages min in English, not very hard to do it, and little more verbose as normal usage (same as other cardreader), it will be a nice very small pinpad cardreader, but it's the life ... Best Regards ----- Mail original ----- De: "tux tsndcb" ?: gnupg-users at gnupg.org Envoy?: Lundi 26 Mai 2014 14:26:00 Objet: Reiner SCT Cyberjack go : Display languge question Hello all, I wanted to know, if people who use this cardreader have english language on display. Because on display I've done this configuration : Menu -> Setting -> Language -> German >English I've selected it but all display messages are in German for exemple when cardreader boot and a smartcard is plug on it : Bitte Karte entnehmen so no in English Other questions : - On display I can see in permanence : Secoder 2 V2.2.1, is it possible to don't see It ? - On my Vega cardreader, when I use it, I can see these : - When no smartcard insert : Insert card - when PIN code is requested : Enter PIN 3 retries left - when I don't put PIN code on time Time Out But with this cardreader I see nothing only PIN when PIN code is requested and nothing for the other things Thanks in advance for your feeback with it. Best Regards _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From kloecker at kde.org Thu May 29 17:48:31 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 29 May 2014 17:48:31 +0200 Subject: Reiner SCT Cyberjack go : Display languge question In-Reply-To: <1508751977.17746631.1401350632465.JavaMail.root@zimbra33-e6.priv.proxad.net> References: <1508751977.17746631.1401350632465.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <5523723.q2zc9cl8TN@thufir.ingo-kloecker.de> On Thursday 29 May 2014 10:03:52 tux.tsndcb at free.fr wrote: > Hello All, > > Here the official Renier SCT support answer : > > "This product is mainly developed for German market, therefore it is > necessary to keep the Secoder2 specs. All PIN messages are definied > there, so they will ALWAYS be in German. The cardreader are primary > for German Market, so the language will be German. It is not possible > to use English Secoder2 text. And we will and can not change this." > > It's very shame, because if this company done a little effort to > translate display messages min in English, not very hard to do it, > and little more verbose as normal usage (same as other cardreader), > it will be a nice very small pinpad cardreader, but it's the life ... IMHO, the real shame is that this device (as probably most other similar devices) doesn't have an open-sourced Free Firmware. (Or does it?) Regards, Ingo > ----- Mail original ----- > De: "tux tsndcb" > ?: gnupg-users at gnupg.org > Envoy?: Lundi 26 Mai 2014 14:26:00 > Objet: Reiner SCT Cyberjack go : Display languge question > > Hello all, > > I wanted to know, if people who use this cardreader have english > language on display. > > Because on display I've done this configuration : > > Menu -> Setting -> Language -> German > > >English I've selected it > > but all display messages are in German for exemple when cardreader > boot and a smartcard is plug on it : > > Bitte Karte > entnehmen > > so no in English > > Other questions : > > - On display I can see in permanence : Secoder 2 V2.2.1, is it > possible to don't see It ? > > - On my Vega cardreader, when I use it, I can see these : > > - When no smartcard insert : > Insert card > > - when PIN code is requested : > Enter PIN > 3 retries left > > - when I don't put PIN code on time > Time Out > > But with this cardreader I see nothing only PIN when PIN code is > requested and nothing for the other things > > Thanks in advance for your feeback with it. > > Best Regards > > > > > _______________________________________________ > 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 -------------- 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 tux.tsndcb at free.fr Thu May 29 18:17:30 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Thu, 29 May 2014 18:17:30 +0200 (CEST) Subject: Reiner SCT Cyberjack go : Display languge question In-Reply-To: <5523723.q2zc9cl8TN@thufir.ingo-kloecker.de> Message-ID: <1419095133.18904091.1401380250735.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello Ingo > IMHO, the real shame is that this device (as probably most other similar > devices) doesn't have an open-sourced Free Firmware. (Or does it?) Yes I'm totaly agree with you, but unfortunally for us it's not tomorrow .. Best Regards From markoran at eunet.rs Thu May 29 23:07:43 2014 From: markoran at eunet.rs (Marko Randjelovic) Date: Thu, 29 May 2014 23:07:43 +0200 Subject: Getting Passphrase From Encrypted and Unencrypted Secret Key Message-ID: <20140529230743.23041cfe@eunet.rs> If an attacker got my secret key while it wasn't encrypted (no passphrase) and then I put a passphrase, and then the same attacker gets encrypted key, can he find out my passphrase based on difference between non-encrypted and encrypted key? -- http://markorandjelovic.hopto.org Please make your donation for humanitarian aid for flood victims in Serbia: http://www.floodrelief.gov.rs/eng/ From rjh at sixdemonbag.org Fri May 30 00:21:04 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 29 May 2014 18:21:04 -0400 Subject: Getting Passphrase From Encrypted and Unencrypted Secret Key In-Reply-To: <20140529230743.23041cfe@eunet.rs> References: <20140529230743.23041cfe@eunet.rs> Message-ID: <5387B2D0.2050000@sixdemonbag.org> On 5/29/2014 5:07 PM, Marko Randjelovic wrote: > If an attacker got my secret key while it wasn't encrypted (no > passphrase) and then I put a passphrase, and then the same attacker > gets encrypted key, can he find out my passphrase based on difference > between non-encrypted and encrypted key? This is considered "computationally infeasible." That phrase means, "it would require science-fiction technologies to do it." From vedaal at nym.hush.com Fri May 30 00:24:36 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Thu, 29 May 2014 18:24:36 -0400 Subject: Getting Passphrase From Encrypted and Unencrypted Secret Key In-Reply-To: <20140529230743.23041cfe@eunet.rs> Message-ID: <20140529222437.238C920180@smtp.hushmail.com> On 5/29/2014 at 5:54 PM, "Marko Randjelovic" wrote: > >If an attacker got my secret key while it wasn't encrypted (no >passphrase) and then I put a passphrase, and then the same attacker >gets encrypted key, can he find out my passphrase based on >difference >between non-encrypted and encrypted key? ====== The attacker wouldn't need to. The attacker ALREADY has your secret key and can decrypt any messages you have, or ever will have with that key, But in answer to your question, No. The attacker cannot determine your passphrase based on that information. The knowledge of the key without the passphrase protection, is the equivalent of knowing the 'plaintext' of something that will be encrypted symmetrically with a gnupg block cipher, which, if, the attacker had a copy of the secret key with the new encryption, the attacker could just try a passphrase-guessing algorithm on the key with the passphrase. Knowing the un-encrypted copy of the key would not help any. (I don't know how to explain the workings of the block-ciphers in gnupg, but think that they are resistant to known-plaintext attacks.) vedaal From system at ioioioio.eu Fri May 30 12:48:55 2014 From: system at ioioioio.eu (system at ioioioio.eu) Date: Fri, 30 May 2014 12:48:55 +0200 Subject: fulldisc encryption Message-ID: <53886217.1070108@ioioioio.eu> dear mailinglist, as truecrypt gave up developing the software any further, the question raised up, how to encrypt the full disc with gnupg. i looked into the web and found something like https://bbs.archlinux.org/viewtopic.php?id=96994 but iam not pretty sure, if its the best way / best practise to do so. any suggestions ? best TET From johanw at vulcan.xs4all.nl Fri May 30 22:51:28 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 30 May 2014 22:51:28 +0200 Subject: fulldisc encryption In-Reply-To: <53886217.1070108@ioioioio.eu> References: <53886217.1070108@ioioioio.eu> Message-ID: <5388EF50.8010803@vulcan.xs4all.nl> On 30-05-2014 12:48, system at ioioioio.eu wrote: > as truecrypt gave up developing the software any further, the question > raised up, how to encrypt the full disc with gnupg. i looked into the > web and found something like > https://bbs.archlinux.org/viewtopic.php?id=96994 All other solutions I have seen so far are much more limited than TrueCrypt: they are either for only one OS (usually windows or Linux), they are only focussed on whole drive encryption (TrueCrypt containers can be ptretty usefull too and work even on Android). The most usefull cause of action seems to me a fork starting from the TrueCrypt 7.1a source. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From tux.tsndcb at free.fr Fri May 30 23:05:29 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Fri, 30 May 2014 23:05:29 +0200 (CEST) Subject: fulldisc encryption In-Reply-To: <5388EF50.8010803@vulcan.xs4all.nl> Message-ID: <665118954.22068970.1401483929613.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello Johan, ----- Mail original ----- De: "Johan Wevers" ?: gnupg-users at gnupg.org Envoy?: Vendredi 30 Mai 2014 22:51:28 Objet: Re: fulldisc encryption On 30-05-2014 12:48, system at ioioioio.eu wrote: > as truecrypt gave up developing the software any further, the question > raised up, how to encrypt the full disc with gnupg. i looked into the > web and found something like > https://bbs.archlinux.org/viewtopic.php?id=96994 All other solutions I have seen so far are much more limited than TrueCrypt: they are either for only one OS (usually windows or Linux), they are only focussed on whole drive encryption (TrueCrypt containers can be ptretty usefull too and work even on Android). LUKS soltution works also for android (but not for full disk), available here : https://play.google.com/store/apps/details?id=com.nemesis2.luksmanager Best Regards _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From johanw at vulcan.xs4all.nl Fri May 30 23:19:04 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 30 May 2014 23:19:04 +0200 Subject: fulldisc encryption In-Reply-To: <665118954.22068970.1401483929613.JavaMail.root@zimbra33-e6.priv.proxad.net> References: <665118954.22068970.1401483929613.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <5388F5C8.7080300@vulcan.xs4all.nl> On 30-05-2014 23:05, tux.tsndcb at free.fr wrote: > LUKS soltution works also for android (but not for full disk), available here : I don't know any full disc encryption metghod for Android. However, LUKS doesn't work for windows. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From tux.tsndcb at free.fr Fri May 30 23:30:56 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Fri, 30 May 2014 23:30:56 +0200 (CEST) Subject: fulldisc encryption In-Reply-To: <5388F5C8.7080300@vulcan.xs4all.nl> Message-ID: <1138433989.22106749.1401485456837.JavaMail.root@zimbra33-e6.priv.proxad.net> > LUKS soltution works also for android (but not for full disk), available here : I don't know any full disc encryption metghod for Android. However, LUKS doesn't work for windows. Yes of course because LUKS => L for linux (so not for Windows) but works also for android as virtual folders Best Regards From markr at signal100.com Sat May 31 02:21:49 2014 From: markr at signal100.com (Mark Rousell) Date: Sat, 31 May 2014 01:21:49 +0100 Subject: fulldisc encryption In-Reply-To: <53886217.1070108@ioioioio.eu> References: <53886217.1070108@ioioioio.eu> Message-ID: <5389209D.70201@signal100.com> On 30/05/2014 11:48, system at ioioioio.eu wrote: > dear mailinglist, > > as truecrypt gave up developing the software any further, the question > raised up, how to encrypt the full disc with gnupg. i looked into the > web and found something like > https://bbs.archlinux.org/viewtopic.php?id=96994 > > but iam not pretty sure, if its the best way / best practise to do so. > any suggestions ? Just carry on using TrueCrypt 7.1a for now (subject to anything found in the ongoing audit project). The strange turn of events surrounding the TrueCrypt website do *not* seem to me to be a good reason to cease using TrueCrypt. I do not take seriously the claims that TrueCrypt is insecure; they seem to me to be invalidated by the odd, non-sensical comments on the new website and overall bizarre nature of the whole episode. Happily it seems likely that there will now (at last) be actively developed forks of TrueCrypt so there is a future for TC users on Windows and other platforms. Note that there is also DiskCryptor for open source full disk encryption on Windows. See http://diskcryptor.com. I've not tested it but it does seem to work, although it suffers from the same drawbacks that TC does (e.g. lack of GPT support). -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 From faramir.cl at gmail.com Sat May 31 07:57:08 2014 From: faramir.cl at gmail.com (Faramir) Date: Sat, 31 May 2014 01:57:08 -0400 Subject: fulldisc encryption In-Reply-To: <5389209D.70201@signal100.com> References: <53886217.1070108@ioioioio.eu> <5389209D.70201@signal100.com> Message-ID: <53896F34.2090604@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 30-05-2014 20:21, Mark Rousell escribi?: ... > Note that there is also DiskCryptor for open source full disk > encryption on Windows. See http://diskcryptor.com. I've not tested > it but it does seem to work, although it suffers from the same > drawbacks that TC does (e.g. lack of GPT support). I get error 404 on that link (not sure why I'm being forwarded to www.diskcryptor.com ). FreeOTFE seems to be available for windows, and it is compatible with LUKS and dm-crypt, but it is only available at sourceforge, since the website seems to only show advertisement. Sigh, I'm glad I don't need a bullet-proof disk encryption tool right now, so I can wait until things become more clear. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTiW80AAoJEMV4f6PvczxAxTwH/jP6eJa7+S4/DBWyww3FCbXp FNzKNqdhSLetxUgNPyx+94w+YBKmVB25Nyc9kw8dvwV6jvJ5iH2ebPrlL3oRkJf5 yzksS+SS+SzL0DKjVLywaDBTcvVQdW3b8SOiirbo7CibglG5Xj5gb9jAoxHng3sv xVS0QXMmfsHKCHv7gU8N5Cq2m0XJfesAsPucijXriWxlF0iVGxR2j4qEgcMQ5K+Y MnwJIJUA9hVZkBI8GnHhNG1+EJ+1HNJNUj8AoUgNoXzUK6Z5hY8Tz4DqKikezPwo dCjCY/swTcXEQKbH6zDNf39asUCMl62rwXWDK0arTQr3LVEMMlUkZaVmHYKA3VE= =pzsh -----END PGP SIGNATURE----- From markr at signal100.com Sat May 31 08:35:07 2014 From: markr at signal100.com (Mark Rousell) Date: Sat, 31 May 2014 07:35:07 +0100 Subject: fulldisc encryption In-Reply-To: <53896F34.2090604@gmail.com> References: <53886217.1070108@ioioioio.eu> <5389209D.70201@signal100.com> <53896F34.2090604@gmail.com> Message-ID: <5389781B.5020504@signal100.com> On 31/05/2014 06:57, Faramir wrote: > El 30-05-2014 20:21, Mark Rousell escribi?: > ... >> Note that there is also DiskCryptor for open source full disk >> encryption on Windows. See http://diskcryptor.com. I've not tested >> it but it does seem to work, although it suffers from the same >> drawbacks that TC does (e.g. lack of GPT support). > > I get error 404 on that link (not sure why I'm being forwarded to > www.diskcryptor.com ). Whoops, I apologise. It should have been https://diskcryptor.net > FreeOTFE seems to be available for windows, and it is compatible > with LUKS and dm-crypt, but it is only available at sourceforge, since > the website seems to only show advertisement. Last time I looked FreeOTFE had not been updated since 2010, so it's even older than the latest working version of TrueCrypt. Unlike TrueCrypt, its device driver is not signed so it won't run on Windows Vista x64 or later without the OS being put in test signing mode. All that said, Free OTFE might be a good basis on which to continue development if the licence terms of TrueCrypt 7.1a turn out to be too restrictive to allow a successful fork. > Sigh, I'm glad I don't > need a bullet-proof disk encryption tool right now, so I can wait > until things become more clear. As far as anyone can tell at the moment, TrueCrypt 7.1a is safe and reliable. The messages on the TrueCrypt Sourceforge website simply should not be taken seriously in my opinion. They are so bizarre as to be of no sense, whereas TrueCrypt has a long history of effective use. -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 From johanw at vulcan.xs4all.nl Sat May 31 09:42:36 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 31 May 2014 09:42:36 +0200 Subject: fulldisc encryption In-Reply-To: <5389781B.5020504@signal100.com> References: <53886217.1070108@ioioioio.eu> <5389209D.70201@signal100.com> <53896F34.2090604@gmail.com> <5389781B.5020504@signal100.com> Message-ID: <538987EC.2080803@vulcan.xs4all.nl> On 31-05-2014 8:35, Mark Rousell wrote: > All that said, Free OTFE might be a good basis on which to continue > development if the licence terms of TrueCrypt 7.1a turn out to be too > restrictive to allow a successful fork. I think it is reasonbably safe to simply ignore the TC license and just fork it. Distribute the forked version without any license whatsoever. Given the secretive nature of the author, he should, for a start, first have to prove he is the author if he wanted to sue you. 2 possible reasons for this action seem likely to me: personal reasons (he's tired of the project) or a gag order. In both cases the author is unlikely to sue. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From tristan.santore at internexusconnect.net Sat May 31 09:55:47 2014 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Sat, 31 May 2014 08:55:47 +0100 Subject: fulldisc encryption In-Reply-To: <538987EC.2080803@vulcan.xs4all.nl> References: <53886217.1070108@ioioioio.eu> <5389209D.70201@signal100.com> <53896F34.2090604@gmail.com> <5389781B.5020504@signal100.com> <538987EC.2080803@vulcan.xs4all.nl> Message-ID: <53898B03.80906@internexusconnect.net> On 31/05/14 08:42, Johan Wevers wrote: > On 31-05-2014 8:35, Mark Rousell wrote: > >> All that said, Free OTFE might be a good basis on which to continue >> development if the licence terms of TrueCrypt 7.1a turn out to be too >> restrictive to allow a successful fork. > I think it is reasonbably safe to simply ignore the TC license and just > fork it. Distribute the forked version without any license whatsoever. > Given the secretive nature of the author, he should, for a start, first > have to prove he is the author if he wanted to sue you. > > 2 possible reasons for this action seem likely to me: personal reasons > (he's tired of the project) or a gag order. In both cases the author is > unlikely to sue. > https://github.com/bwalex/tc-play On Fedora, yum install tcplay Enjoy. 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 From markr at signal100.com Sat May 31 10:12:43 2014 From: markr at signal100.com (Mark Rousell) Date: Sat, 31 May 2014 09:12:43 +0100 Subject: fulldisc encryption In-Reply-To: <538987EC.2080803@vulcan.xs4all.nl> References: <53886217.1070108@ioioioio.eu> <5389209D.70201@signal100.com> <53896F34.2090604@gmail.com> <5389781B.5020504@signal100.com> <538987EC.2080803@vulcan.xs4all.nl> Message-ID: <53898EFB.10409@signal100.com> On 31/05/2014 08:42, Johan Wevers wrote: > On 31-05-2014 8:35, Mark Rousell wrote: > >> All that said, Free OTFE might be a good basis on which to continue >> development if the licence terms of TrueCrypt 7.1a turn out to be too >> restrictive to allow a successful fork. > > I think it is reasonbably safe to simply ignore the TC license and just > fork it. Distribute the forked version without any license whatsoever. > Given the secretive nature of the author, he should, for a start, first > have to prove he is the author if he wanted to sue you. > > 2 possible reasons for this action seem likely to me: personal reasons > (he's tired of the project) or a gag order. In both cases the author is > unlikely to sue. Good points. It should also be noted that the 'TrueCrypt License Version 3.0' (under which TC 7.1a is licensed) includes three sublicences from included software written by identifiable entities[1] but on a brief reading none of them seem to prevent TC from being forked. All the same, merging the capabilities of FreeOTFE would be a nice-to-have for a TrueCrypt fork. Footnote:- 1: Including one from E4M which was allegedly the subject of a legal dispute early on in TC's history. -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 From toni.einio at kpmg.fi Fri May 30 13:44:06 2014 From: toni.einio at kpmg.fi (Einio, Toni) Date: Fri, 30 May 2014 11:44:06 +0000 Subject: encrypt timestamp file Message-ID: <4414613698B8544E86189D031E70F712207F5BE3@R2AVNEXC300.ema.kworld.kpmg.com> Hello I like to automate encryption but what parameters I need to use for file which name is changing? Here is my command: gpg -sear xxxxxxxx--homedir e:\gnu\keys --batch --default-key privateKey at xxxx.fi --passphrase xxxxxxxxxxxxxxxxxxxxx "E:\Inetpub\wwwroot\usrImport_timestamp.csv" So there is timestamp on usrImport.csv file. Toni ********************************************************************** The information in this e-mail (and any attachments) is intended exclusively for the addressee(s). Any use by a party other than the addressee(s) is prohibited. The information may be confidential in nature and fall under a duty of non-disclosure. If you are not the addressee, please notify the sender and delete this e-mail. KPMG cannot guarantee that e-mail communications are secure or error-free, as information could be intercepted, corrupted, amended, lost, destroyed, arrive late or incomplete, or contain viruses. Any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing KPMG client engagement letter. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: