Re: [cryptography] OpenPGP adoption post-PRISM
On Tue, Jul 30, 2013 at 1:51 AM, Andreas Bürki abue...@anidor.com wrote: Am 30.07.2013 01:25, schrieb Tony Arcieri: Here's the source of the data, if you're curious: https://sks-keyservers.net/ To me as a boring consumer it looks curious, right: https://www.ssllabs.com/ssltest/analyze.html?d=sks-keyservers.nethideResults=on What exactly are you pointing out here? If this were a timely graph (ie, one made to indicate the trend before/after the NSA leaks) it might've been limited to the beginning of the year and 3.2M and have put markers for certain events (I'd like to see this graph anyway if anyone wants to make it). The chart looks pretty honest to me (I have nothing to dispute the numbers or the source nore any feeling that the trend is wrong). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OpenPGP adoption post-PRISM
Am 30.07.2013 08:51, schrieb shawn wilson: On Tue, Jul 30, 2013 at 1:51 AM, Andreas Bürki abue...@anidor.com wrote: Am 30.07.2013 01:25, schrieb Tony Arcieri: Here's the source of the data, if you're curious: https://sks-keyservers.net/ To me as a boring consumer it looks curious, right: https://www.ssllabs.com/ssltest/analyze.html?d=sks-keyservers.nethideResults=on What exactly are you pointing out here? That sks-keyservers.net seems to have a curious certificate. That's all. And no pointer at all about the growing interest of individuals for privacy, reflected in the chart. This seems quite plausible to me, having latest circumstances in mind. If this were a timely graph (ie, one made to indicate the trend before/after the NSA leaks) it might've been limited to the beginning of the year and 3.2M and have put markers for certain events (I'd like to see this graph anyway if anyone wants to make it). The chart looks pretty honest to me (I have nothing to dispute the numbers or the source nore any feeling that the trend is wrong). -- Andreas Bürki abue...@anidor.com S/MIME certificate - SHA1 fingerprint: ED:A5:F3:60:70:8B:4C:16:44:18:96:AE:67:B9:CA:77:AE:DA:83:11 GnuPG - GPG fingerprint: 5DA7 5F48 25BD D2D7 E488 05DF 5A99 A321 7E42 0227 smime.p7s Description: S/MIME Cryptographic Signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OpenPGP adoption post-PRISM
On 2013-07-30 at 10:29 +0300, Ryan Hurst wrote: I understand the decision of a PGP solution to not leverage PKIX but such a decision raises the bar of adoption of PGP by mere mortals even further than it already is. Nonsense: PGP key retrieval normally doesn't use TLS and is subject to traffic analysis. So none of this gets in the way of normal key retrieval or PGP operation. Mere mortals don't know or care how the pools are run, don't go changing the default, and if they do change the default will probably just pick a hostname, rather than explicitly trying to turn on hkps and enabling verification. So this is about the issues that limit people who know rather more than is typical about crypto engineering. If you're using TLS to defeat traffic analysis, you don't do this to keyservers in a public pool, where a number of the keyservers might be run by national security agencies hoping to be used by local clients (in the geographic pools). The TLS sub-pool mostly serves as a proof of concept and to provide a framework for public exploration, not for providing protection against traffic analysis. Which is the only thing that TLS on key retrievals serves for: to retard disclosure of who you're wanting to talk privately with. Kristian does not, to my knowledge, run background checks on keyserver operators to find out who has a day-job working for an acronym agency, so merely being the hkps pool provides no protection here. If you care about traffic analysis, you run your own keyserver, you block to port 11371 at firewalls except for connections from your keyserver (for reconciliation) to catch people with unconfigured clients and you then set up TLS on the keyserver, using the public insecure examples as guidelines for what can be done. For your own keyserver, you can pay for a PKIX CA cert if you want to avoid having dedicated trust anchors for PGP in the client configurations. The only issues come if you start trying to run a pool and can't share server keys, in which case the public pool gives hints of what will work and be tested by GnuPG users, so will keep working. -Phil ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OpenPGP adoption post-PRISM
There are free PKIX certs, I offer them to projects like this and StartSSL offers free certs as well so the decision to use something else is not a function of cost. The fact that one needs to operate their own key server to have any confidence is part of the adoption barrier; not the largest for sure but certainty part. Ryan Hurst Chief Technology Officer GMO Globalsign twitter: @rmhrisk email: ryan.hu...@globalsign.com Sent from my phone, please forgive the brevity. On Jul 30, 2013, at 8:34 PM, Phil Pennock rb-cryptography+p...@spodhuis.org wrote: On 2013-07-30 at 10:29 +0300, Ryan Hurst wrote: I understand the decision of a PGP solution to not leverage PKIX but such a decision raises the bar of adoption of PGP by mere mortals even further than it already is. Nonsense: PGP key retrieval normally doesn't use TLS and is subject to traffic analysis. So none of this gets in the way of normal key retrieval or PGP operation. Mere mortals don't know or care how the pools are run, don't go changing the default, and if they do change the default will probably just pick a hostname, rather than explicitly trying to turn on hkps and enabling verification. So this is about the issues that limit people who know rather more than is typical about crypto engineering. If you're using TLS to defeat traffic analysis, you don't do this to keyservers in a public pool, where a number of the keyservers might be run by national security agencies hoping to be used by local clients (in the geographic pools). The TLS sub-pool mostly serves as a proof of concept and to provide a framework for public exploration, not for providing protection against traffic analysis. Which is the only thing that TLS on key retrievals serves for: to retard disclosure of who you're wanting to talk privately with. Kristian does not, to my knowledge, run background checks on keyserver operators to find out who has a day-job working for an acronym agency, so merely being the hkps pool provides no protection here. If you care about traffic analysis, you run your own keyserver, you block to port 11371 at firewalls except for connections from your keyserver (for reconciliation) to catch people with unconfigured clients and you then set up TLS on the keyserver, using the public insecure examples as guidelines for what can be done. For your own keyserver, you can pay for a PKIX CA cert if you want to avoid having dedicated trust anchors for PGP in the client configurations. The only issues come if you start trying to run a pool and can't share server keys, in which case the public pool gives hints of what will work and be tested by GnuPG users, so will keep working. -Phil smime.p7s Description: S/MIME cryptographic signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] OpenPGP adoption post-PRISM
Interesting chart: https://pbs.twimg.com/media/BQYA_qWCEAIoUFT.png -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
