Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] 10 reasons not to start using PGP

elijah elijah at
Thu Oct 10 14:17:01 PDT 2013

On 10/10/2013 12:23 PM, carlo von lynX wrote:

> 1. Downgrade Attack: The risk of using it wrong.

Fixed in the new generation of clients (mailpile, LEAP, etc).

> 2. The OpenPGP Format: You might aswell run around the city naked.

Fixed by using StartTLS with DANE (supported in the new version of
postfix). Admittedly, this makes sysadmin's job more challenging, but
LEAP is working to automate the hard stuff (

> 3. Transaction Data: He knows who you are talking to.

Fixed in the short term by using StartTLS with DANE. Fixed in the long
term by adopting one of these approaches:

> 4. No Forward Secrecy: It makes sense to collect it all.

Imperfectly fixed in the short term using StartTLS with only PFS ciphers
enabled. This could be fixed in the long term by using Trevor Perrin's
scheme for triple EC Diffie-Hellman exchange. This has been implemented
by moxie for SMS, and could be for SMTP

> 5. Cryptogeddon: Time to upgrade cryptography itself?

New version of GPG supports ECC, but of course nothing in the snowden
leaks suggest we need to abandon RSA of sufficient key length (just the
ECC curves that have *always* been suspicious).

> 6. Federation: Get off the inter-server super-highway.

Federated transport with spool-then-forward time delay is likely a much
more feasible way to thwart traffic analysis than attempting to lay down
a high degree of cover traffic for direct peer to peer transport. This
is, of course, an area of active academic research and it would be
irresponsible to say that we definitively know how to prevent traffic
analysis, either with p2p or federation.

> 7. Statistical Analysis: Guessing on the size of messages.

Easily fixed.

> 8. Workflow: Group messaging with PGP is impractical.

No one anywhere has solved the problem of asynchronous, forward-secret
group cryptography. There are, however, working models of group
cryptography using OpenPGP, such as SELS
( This approach makes key management
more difficult, but we need to automate key management anyway for
OpenPGP to be usable enough for wider adoption.

> 9. TL;DR: I don't care. I've got nothing to hide.

This critique rests on the assumption that the problems with email are

> 10. The Bootstrap Fallacy: But my friends already have e-mail!

Email remains one of the two killer apps of the internet, and is
unlikely to vanish any time soon. Simple steps we can take to make it
much better seem like a wise investment in energy.

There are two approaches to addressing the problems with email:

(1) assert that email is hopeless and must be killed off.
(2) identify areas where we can fix email to bring it into the 21st century.

I think that approach #1 is irresponsible: regardless of one's personal
feelings about email, it is certainly not a lost cause, and asserting
that it is will make it more difficult to build support for fixing it.

Approach #2 is certainly an uphill battle, but there are a growing
number of organizations working on it. LEAP's (free software) efforts
are outlined here: We have it working, we just
need to get it mature enough for production use.


More information about the liberationtech mailing list