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 <[email protected]> ----- > > Date: Thu, 10 Oct 2013 14:17:01 -0700 > From: elijah <[email protected]> > To: [email protected] > Subject: Re: [liberationtech] 10 reasons not to start using PGP > Message-ID: <[email protected]> > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 > Thunderbird/24.0 > Reply-To: liberationtech <[email protected]> > > 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 > [email protected]. > > ----- End forwarded message ----- -- Sent from Ubuntu
signature.asc
Description: This is a digitally signed message part
