[cryptography] OpenPGP adoption post-PRISM

Phil Pennock rb-cryptography+phil at spodhuis.org
Tue Jul 30 13:34:12 EDT 2013

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

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.


More information about the cryptography mailing list