Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] 10 reasons not to start using PGP

carlo von lynX lynX at time.to.get.psyced.org
Thu Oct 10 17:14:29 PDT 2013


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 at time.to.get.psyced.org <mailto:lynX at 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.




More information about the liberationtech mailing list