[liberationtech] 10 reasons not to start using PGP

Ted Smith tedks at riseup.net
Fri Oct 11 10:59:54 PDT 2013


One reason to start using PGP:

1. Worse is better. Something is better than nothing.

On Fri, 2013-10-11 at 12:59 +0200, Eugen Leitl wrote:
> ----- 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 -----

-- 
Sent from Ubuntu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20131011/4ba6004a/attachment-0001.sig>


More information about the cypherpunks mailing list