----- Forwarded message from carlo von lynX <lynX@time.to.get.psyced.org> ----- Date: Fri, 11 Oct 2013 02:14:29 +0200 From: carlo von lynX <lynX@time.to.get.psyced.org> To: liberationtech <liberationtech@mailman.stanford.edu> Subject: Re: [liberationtech] 10 reasons not to start using PGP Message-ID: <20131011001429.GI22105@lo.psyced.org> User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: liberationtech <liberationtech@lists.stanford.edu> Next collection of answers to replies. Expect yours to be somewhere in here. Thanks for all the feedback! I actually expected harsher religious replies! :) On 10/10/2013 10:55 PM, Enrique Piracés wrote:

I think this is a good topic for debate among those who can or are currently developing security tools/protocols, and it is one way to further discuss usability as a security feature in communities like this one. That said, I think it is really bad advice and I encourage you to refrain from providing this as a suggestion for users who may put themselves or others at risk as a result of it.

The opening sentence says "Pretty Good Privacy is better than no encryption at all ..."

Also, I think the title is misleading, as most of the article is about why PGP is not an ideal solution for the future (a point where I think you would find significant agreement). Again, suggesting not to use PGP without providing a functional alternative is irresponsible.

I am suggesting four alternatives and indicating to work harder to make them viable tools for everyone as we should no longer postpone replacing PGP and e-mail. Of course I would also appreciate attention regarding the fifth, secushare. On 10/10/2013 10:57 PM, Jonathan Wilkes wrote:

Bitmessage doesn't have forward secrecy, and AFAICT there's no way to easily add it later on.

If I understood the principle correctly it allows you to generate new "accounts" freely, so you can put your *next* account name into a message. If both sides do this, they can obfuscate their identities a bit. And you can automate it. You could also re-key at each message with PGP, but I presume it would make your implementation incompatible with everybody else's. On 10/10/2013 11:08 PM, Gregory Maxwell wrote:

I'm surprised to see this list has missed the thing that bugs me most about PGP: It conflates non-repudiation and authentication.

I send Bob an encrypted message that we should meet to discuss the suppression of free speech in our country. Bob obviously wants to be sure that the message is coming from me, but maybe Bob is a spy ... and with PGP the only way the message can easily be authenticated as being from me is if I cryptographically sign the message, creating persistent evidence of my words not just to Bob but to Everyone!

I kind-of lumped it mentally together with forward secrecy, because for both problems the answer is Diffie-Hellman. But you are right, it is the eleventh reason.

My other big technical complaint about PGP is (3) in the post, that every encrypted message discloses what key you're communicating with. PGP easily _undoes_ the privacy that an anonymity network like tor can provide. It's possible to use --hidden-recipient but almost no one does.

Guess what, none of the alternative messaging tools would dream of putting the recipient address close to the message. They just make sure that it somehow gets there.

Its also easy to produce a litany of non-technical complaints: PGP is almost universally misused (even by people whos lives may depend on its correct use), the WOT leaks tons of data, etc.

Oh yes, I completely forgot to link that long article that recently came out criticizing the PGP web of trust.

In my view the use of PGP is more appropriately seen as a statement about the kind of world we want to have— one where encryption is lawful, widely used, and uncontroversial— and less of a practical way to achieve security against many threats that exist today.

It is not enough for the purpose of protecting democracy, therefore it's one of those statements that backfire: The adversary doesn't care about you making that statement and can use it against you. On 10/11/2013 12:17 AM, Jillian C. York wrote:

Just replying to this bit of your reply to me; the rest made sense

Grrreat.

On Thu, Oct 10, 2013 at 3:08 PM, carlo von lynX <lynX@time.to.get.psyced.org <mailto:lynX@time.to.get.psyced.org>> wrote:

...

If this is still jargony to you, hmmm... you are unlikely to understand the risks you are exposed to by using the Internet from day to day. These are concepts that anyone in the circumvention business must be aware of. You can choose to not read the Guardian article and not try to understand what's going on, but then you should better just trust that the conclusion is not made up:

No, see that's the thing: /I /get it, but I don't think I'm totally your target audience (I've been using PGP for years, you're talking to people who haven't started yet, right?)

No, not really. It is for the multipliers and activists. The ones that carry the torch to the people. The Luciphers. You have been carrying PGP to the people and I am suggesting you should consider giving them other tools, and educating them to question those tools and look out for even newer tools. And help make these tools safe, reviewed and usable. Then again I wouldn't mind if normal people /get/ it, too, but I wouldn't want them to opt out the easy way by stopping to use cryptography.

You want criticism? There it is. Your writing does not work for the general public. You write in a way that feels condescending and assumes that the reader already has a full grasp of why those things are issues.

I tried to hide the depth in the links so that it's still readable for someone who already knows all that stuff.

On the one hand, you're telling people that PGP is too hard/broken, while with the other you're expecting them to already understand it/the threat model.

Also, I have no idea what is meant by the "bull run" comment in that sentence. If you want your piece to have any reach beyond the English language, consider tightening up your writing.

It is mentioned in the article. It's the NSA program that enables them to hijack any TLS connection on the fly. It was mentioned in television news some weeks ago, too. The way I put it in that text is a hint saying "if you don't understand this, you should seriousy consider reading the linked articles..." ;-) On Thu, Oct 10, 2013 at 02:17:01PM -0700, elijah wrote:

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

Except for the fact that you are still using a mail address, thus it can ALWAYS be used without encryption -> FAIL.

...

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

Are you alluding to https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ ?

...

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

Hm, all of the approaches presume that there is something like a server that a dissident can trust.

...

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/).

You are slowly turning the email network in some sort of a Tor. Hehe.

...

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

Ok, how does it figure out the recipient can handle ECC?

...

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

Feasible? Such tools already exist. File sharing happens. Tor, too. Whereas obfuscation over mail servers needs to be deployed first.

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.

I think tools should do both spool-then-forward and play with cover traffic. If GNUnet as an academic project is working so much on the cover traffic bit, some academic results maybe exist. The terms P2P and federation are starting to get confusing. So-called P2P tools are sometimes actually employing dumb relay servers, which kind of defeats the original definition of P2P. And you are talking of federation servers that, although they are using plaintext email addresses, are actually not knowing where they are sending things to. That kind of goes beyond the traditional notion of federation. So in a way both are converging to a similar strategy. The difference that remains is that P2P uses DHT-resolution strategies like GNS to address any node, be it at home or in a server rack, while federation sticks to domain names and therefore cannot easily include user endpoints. Also, as you pointed out, it needs a whole lot of administration work. A DHT just works out of the box by using it. And then there are also social approaches to discovery... Still I have a feeling the DHT approach, especially with built-in lookup privacy like GNS/GADS has it, is superior. On the other hand, maintaining the domain name hell is backwards compatible to current e-mail. The question is if that is actually doing anyone any good. Maybe if you can convince spammers to use LEAP they will provide not only for nuisance but also for cover traffic. :)

...

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

I think you have to be a bit opportunistic about it. Briar does it somehow, if I understood correctly.

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.

Yes. Key management is an API, not a user interface. Automatic import of embedded secret keys sounds like a major cultural revolution for good ole PGP. No surprise none of the list clients supports that yet. Interesting developments. Not enough to consider this path worth pursueing but in the category of better-than-nothing.

...

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.

Yes. That even if all the effort is done you will still be receiving unencrypted mail because you have a mail address. You will still have a multitude of hosts that are still "unfixed." That you will still carry a dependency on DNS and X.509 around your neck just to be able to be backwards compatible to an e-mail system of which you hope you won't have to send or receive any messages since they will damage your privacy. So what is this terrific effort to stay backward compatible good for? I don't see it being a worthwhile goal. There is so much broken about it while a fresh start, where every participant is safe by definition, is so much more useful. Especially you don't have that usability challenge of having to explain to your users that some addresses are superduper safe while other addresses are lacking solid degree of privacy. And I still haven't understood where I get my trustworthy server from. I know I can rent one, but even if I have a root shell on it, it doesn't mean it is safe. So yes, I can't find a way to believe that those fixes actually can fix the entire architecture.

...

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.

I've read that claim before and I am sure Facebook has already proven us wrong. Wasn't it in the news a year ago that e-mail was losing users to Facebook messaging? And I don't see a use in maintaining e-mail if I have to rebuild my trust network, anyway.

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.

I think I have laid out why it is indeed a lost cause.

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.

You didn't actually address the "bootstrap fallacy" that I pointed out. -- 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 ----- -- 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