Re: [liberationtech] 10 reasons not to start using PGP

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 -----

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

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@stanford.edu.

----- End forwarded message -----

-- Sent from Ubuntu