[liberationtech] 10 reasons not to start using PGP

Eugen Leitl eugen at leitl.org
Fri Oct 11 03:59:16 PDT 2013


----- Forwarded message from elijah <elijah at riseup.net> -----

Date: Thu, 10 Oct 2013 14:17:01 -0700
From: elijah <elijah at riseup.net>
To: liberationtech at lists.stanford.edu
Subject: Re: [liberationtech] 10 reasons not to start using PGP
Message-ID: <5257194D.1050202 at riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
Reply-To: liberationtech <liberationtech at lists.stanford.edu>

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 (https://leap.se/platform).

> 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: https://leap.se/en/routing

> 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
(https://whispersystems.org/blog/simplifying-otr-deniability/).

> 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
(http://sels.ncsa.illinois.edu/). 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
unfixable.

> 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: https://leap.se/email. We have it working, we just
need to get it mature enough for production use.

-elijah
-- 
Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu.

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5



More information about the cypherpunks mailing list