[liberationtech] 10 reasons not to start using PGP

[Eugen Leitl]

----- Forwarded message from carlo von lynX <lynX at time.to.get.psyced.org> -----

Date: Fri, 11 Oct 2013 00:08:47 +0200
From: carlo von lynX <lynX at time.to.get.psyced.org>
To: liberationtech <liberationtech at mailman.stanford.edu>
Subject: Re: [liberationtech] 10 reasons not to start using PGP
Message-ID: <20131010220847.GH22105 at lo.psyced.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Reply-To: liberationtech <liberationtech at lists.stanford.edu>

Hello again. I will answer to most comments all in a single mail
to avoid clogging libtech. While I wrote this another ten mails
have slipped in, so expect another large reply to those.  :-)


On 10/10/2013 10:00 PM, Richard Brooks wrote:
> 10 reasons to give up, stop trying, hide in a corner, and die.

Sorry if I start talking about the alternatives only at the very end
of the document. This is about becoming aware of how serious the
problem is and to start directing some energy into fueling the
alternatives which are popping up like mushrooms just recently.
For the obvious reasons. And I specifically mention peer reviewing
them. So the message is: go get yourself new tools and teach your
peers to use the new tool of the day.


On 10/10/2013 10:11 PM, Pranesh Prakash wrote:
> Interesting. But someone should also write a piece called "1 reason not
> to criticise security tech without clearly stating threat model which
> serves as basis for that criticism".  What if Mallory isn't a
> well-funded governmental organization but is the admin who runs your
> employer's email servers?

That's a good point. The reason why I don't pay attention to lesser
threat models is that the loss in quality of democracy we are currently
experiencing is large enough that I don't see much use for a distinction
of threat models - especially since alternatives that work better than
PGP exist, so they are obviously also better for lesser threat models.

For example, I don't think that a dissident in Irya (ficticious country)
is better off if no-one but Google Mail knows that he is a dissident.
Should at any later time in his life someone with access to that data
find it useful to use it against the dissident, he can still do it.
And who knows what the world looks like in twenty years from now?

Not saying give up and die. Saying if you can opt for better security,
don't postpone learning about it. If you can invest money in making
it a safe option, don't waste time with yet another PGP GUI project.

> This should actually be two lists: reasons not to use e-mail, and
> reasons not to use OpenPGP over e-mail.

Fine with me. I don't think it makes much difference for the end
user whether SMTP federation or actual PGP is failing her.

> Only reasons 2, 3, 4, 5, 7, 8 are really about OpenPGP (you should've
> stuck to "6 reasons not to use PGP"), and at least three of them are
> really good reasons to look for alternatives. There are no good
> alternatives over e-mail: S/MIME unfortunately suffers from many of the
> same issues as OpenPGP, and then some more.

I don't find S/MIME worth mentioning anymore. It has so failed us.
But maybe I should for completeness?

> And reason #1 is something that the client should take care of (ideally
> with default settings), and not the encryption protocol.  Why are you
> attacking OpenPGP and OTR for this?

Because it's not true that the client can handle it. The fact that an
email address exists implies that some folks will send unencrypted
stuff to it. I experienced this. Just yesterday a friend changed his
life plans because of an unencrypted message. Yes, you could enforce
PGP once it's configured - but you can't opt out from e-mail. That is
evil.

Look at any of the alternatives instead. None of them allow you to
transmit an unencrypted message. In fact all the modern systems use
the public key for addressing, so you can't do it wrong.

> And thank you so much for the comparative chart.  It is *very* useful.

My pleasure. I felt the need to do this since I get asked for
recommendations frequently - and I don't like to say.. wait until
secushare is ready. I don't want to wait for it myself.

> Why doesn't telephony have SIP?

It should. What would the icons be that you would put there?
I'm not familiar with end-to-end encryption over SIP for instance.


On 10/10/2013 10:33 PM, Marcin de Kaminski wrote:
> Agreed. The threat model discussion clearly is too often lost in all
> the current post-Snowden debates. We need to remember that a lot if
> solutions might not be enough to protect anyone against NSAish
> authorities but more than enough against other, most real, threats
> to peoples personal safety. Regular employers, schools, parents, skiddies, whatever. 

I think if employers, schools, parents, skiddies can find out who
you are exchanging encrypted messages with, that can be a very real
threat to you. Using a tool that looks like it does something
totally different.. on your screen, over the network and even on
your hard disk.. can save your physical integrity.


On 10/10/2013 09:55 PM, adrelanos wrote:
> Thank you for doing this work!
> The world needs someone facing the truth, explaining why gpg isn't the
> solution, advocating positive change. It's a communicative task, a very
> difficult one. As long there is gpg, most geeks don't see need to create
> better alternatives.

Glad someone is understanding the positivity in awareness and
will to move forward. Ignoring threats just because they are
depressing is a bit like sticking your head in the ground.

> I'd say, gpg's development slowed down. They're qualified but standing
> in their own way. They should break compatibility with commercial PGP
> (not because thats good, just because it's easier to implement better
> solutions), also break compatibility with RFCs, implement better
> solutions and standardize later. The current "first standardize, then
> maybe implement, and don't implement if it's not standardized" approach
> is much too slow, can't keep up with real developments in real word.

The whole architecture is wrong. There is hardly anything worth keeping
in the old PGP approach except for the cryptographic basics. All the
modern alternatives use a completely different approach.

> (Still don't even have mail subject encryption.) If Bitmessage succeeds
> (I haven't learned much about it yet), and actually provides better
> protection than gpg, I am happy with that also if there isn't a RFC. If
> Bitmessage gets really popular, I am sure they'll somehow work things
> out and happen to standardize it later.

Thanks for reminding me to look at Bitmessage. I was postponing that
unnecessarily. I read the whitepaper and have added it to the comparison
table according to the claims in it. The architecture sounds a bit
like the one of IRC, but without multicast routing - so I expect it
to run into serious scalability issues. It will probably have to split
into several incompatible networks as it grows. It will also probably
keep your computer a lot more busy than you expect from a communication
tool. But for the time being it is a crypto-strategically much safer
approach than PGP.

Concerning standardization: It is a VERY BAD development that it has
become en vogue to require standardization from projects that haven't
even started functioning. It has been detrimental to the social tool
scene: None of them work well enough to actually scale and replace
Facebook, but the scalability problems are already being cemented into
"open standards," ensuring that they never will.

You must ALWAYS have a working pioneer tool FIRST, then dissect the
way it works and derive a standard out of it. Bittorrent is a good
example for that. It's one of the few things that actually works.
Imagine if Napster and Soulseek had developed an open standard. It
would only have delayed the introduction of Bittorrent, promoting
an inferior technology by standardization.

Open standards are part of the problem, not the solution.

> Sometimes I even think, if there wasn't gpg, new approaches had better
> chances reaching critical mass.

Good point. libtech is the place where people put time and money
into these things. Figuring out the ultimate UX fix for PGP won't
solve the underlying problems. The number of PGP critics is growing.


On Thu, Oct 10, 2013 at 12:40:55PM -0700, Jillian C. York wrote:
> In my opinion, this makes about as much sense as telling people who are
> already having sex not to use condoms.

I am saying to use condoms that don't slip off during intercourse
and explaining why the old condom technology has a tendency to break.

> Consider mine a critique of why this post makes almost no sense to and
> won't convince any member of the public.  I'm sure some of the geeks here
> will have a field day with it, but some of it is barely in my realm of
> understanding (and while I'm admittedly not a 'geek', I've been working in
> this field for a long time, which puts me at the top rung of your 'average
> user' base).

Well, maybe we can find wordings that make it more understandable.
Of course the links are meant for being clicked upon when necessary.

> TL;DR: This may well be a solid argument for convincing developers to
> implement better UIs, etc, but it doesn't work for its intended purpose,
> which seems to be convincing n00bs not to use PGP.

No, it is exactly about not trying to fix on the UI level what is
fundamentally beyond repair.

> > 2. The OpenPGP Format: You might aswell run around the city naked.
> >
> >    As Stf pointed out at CTS, thanks to its easily detectable [06]OpenPGP
> >    Message Format it is an easy exercise for any manufacturer of [07]Deep
> >    Packet Inspection hardware to offer a detection capability for
> >    PGP-encrypted messages anywhere in the flow of Internet communications,
> >    not only within SMTP. So by using PGP you are making yourself visible.
> >
> >    Stf has been suggesting to use a non-detectable wrapping format. That's
> >    something, but it doesn't handle all the other problems with PGP.
> 
> Okay, this part requires more explanation for the layman, methinks.  It's
> not intuitive for a non-tech to understand.

Didn't feel like including an explanation of Deep Packet Inspection
and elaborate on the recognizable characteristics of the OpenPGP format
as it would explode the paragraph a bit, but maybe that's wrong. Depends
on who my target audience is. Somebody like you could be. Does it work by
following the links or does it get too abstract from there .. in the sense
that you can read the Wikipedia pages but fail to connect the dots?

> > 3. Transaction Data: He knows who you are talking to.
> >
> >    Should Mallory not [08]possess the private keys to your mail provider's
> >    TLS connection yet, he can simply intercept the communication by means
> >    of a [11]man-in-the-middle attack, using a valid fake certificate that
> >    he can make for himself on the fly. It's a bull run, you know?
> 
> You're not going to convince anyone with jargony talk.

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:

> >    Even if you employ PGP, Mallory can trace who you are talking to, when
> >    and how long. He can guess at what you are talking about, especially
> >    since some of you will put something meaningful in the unencrypted
> >    Subject header.
> 
> Again, this is a call for better education around email practices, not for
> people to stop using PGP.

There is nothing you can do with email that saves you from this happening.
Thus, it's not a problem of practices. It's a question of throwing away
the broken condom and learn about new contraceptive technology.

> >    Should Mallory have been distracted, he can still recover your mails by
> >    visiting your provider's server. Something to do with a PRISM, I heard.
> >    On top of that, TLS itself is being recklessly deployed without forward
> >    secrecy most of the time.
> >
> > 4. No Forward Secrecy: It makes sense to collect it all.
> >
> >    As Eddie has told us, Mallory is keeping a complete collection of all
> >    PGP mails being sent over the Internet, just in case the necessary
> >    private keys may one day fall into his hands. This makes sense because
> >    PGP lacks [12]forward secrecy. The characteristic by which encryption
> >    keys are frequently refreshed, thus the private key matching the
> >    message is soon destroyed. Technically PGP is capable of refreshing
> >    subkeys, but it is so tedious, it is not being practiced - let alone
> >    being practiced the way it should be: at least daily.
> 
> Again: Fair criticism, but unclear why this should convince one NOT to use
> PGP.  Rather, it should convince us to improve mechanisms and add forward
> secrecy.

You mean I should explain why it is impossible to add forward secrecy
to PGP over e-mail by design? I thought that was going to be clear.

> > 6. Federation: Get off the inter-server super-highway.
> >
> >    NSA officials have been reported saying that NSA does not keep track of
> >    all the peer-to-peer traffic as it is just large amounts of mostly
> >    irrelevant copyright infringement. It is thus a very good idea to
> >    develop a communications tool that embeds its ECC- encrypted
> >    information into plenty of P2P cover traffic.
> >
> >    Although this information is only given by hearsay, it is a reasonable
> >    consideration to make. By travelling the well-established and
> >    surveilled paths of e-mail, PGP is unnecessarily superexposed. Would be
> >    much better, if the same PGP was being handed from computer to computer
> >    directly. Maybe even embedded into a picture, movie or piece of music
> >    using [17]steganography.
> 
> Steganography, really?  Sigh.

One of the options that are safer than PGP is steganography, yes.

> > 7. Statistical Analysis: Guessing on the size of messages.
> >
> >    Especially for chats and remote computer administration it is known
> >    that the size and frequency of small encrypted snippets can be observed
> >    long enough to guess the contents. This is a problem with SSH and OTR
> >    more than with PGP, but also PGP would be smarter if the messages were
> >    padded to certain standard sizes, making them look all uniform.
> 
> It would be great, yes.  Still doesn't convince me that using PGP isn't
> worthwhile.

This one alone not necessarily, it's the least bad one of all.

> > 8. Workflow: Group messaging with PGP is impractical.
> >
> >    Have you tried making a mailing list with people sharing private
> >    messages? It's a cumbersome configuration procedure and inefficient
> >    since each copy is re-encrypted. You can alternatively all share the
> >    same key, but that's a different cumbersome configuration procedure.
> >
> >    Modern communication tools automate the generation and distribution of
> >    group session keys so you don't need to worry. You just open up a
> >    working group and invite the people to work with.
> 
> Okay, yes, you've got me here.  PGP sucks for group discussion, although I
> fail to see why group discussion is an imperative.  But what, do you
> suggest, is an immediate alternative?   Nothing?  Right, okay...still using
> PGP.

The article is not meant to be an advertisement for the alternatives.
With my working group we are currently exchanging materials by means
of RetroShare. It takes a bit getting used to as you would not expect
that a file sharing app should be used for by-the-way features like
its built-in homebrewn mail system and forum messaging - and to expect
it to be safer than regular e-mail. But RetroShare does indeed solve
some of the things listed in this long list (see the comparison for
details). The downside is, nobody is willing to put her hands in the
fire to guarantee it is a safe choice of software and the source code,
as frequently with file sharing tools, is too complex to be an easy
read. So it is an amazing feature beast pending peer review.

Briar is expected to be a better solution, but it is in alpha stage.

Both should probably be used over Tor for obfuscation, as they don't
provide for that themselves.

And then there is Pond, which is technologically a work of art, but it
doesn't facilitate group communication (yet).

> > 9. TL;DR: I don't care. I've got nothing to hide.
> >
> >    So you think PGP is enough for you since you aren't saying anything
> >    reaaally confidential? Nobody actually cares how much you want to lie
> >    yourself stating you have nothing to hide. If that was the case, why
> >    don't you do it on the street, as John Lennon used to ask?
> >
> >    It's not about you, it's about your civic duty not to be a member of a
> >    predictable populace. If somebody is able to know all your preferences,
> >    habits and political views, you are causing severe damage to democratic
> >    society. That's why it is not enough that you are covering naughty
> >    parts of yourself with a bit of PGP, if all the rest of it is still in
> >    the nude. Start feeling guilty. Now.
> 
> Again: This is merely a reason to convince people to use encryption MORE
> OFTEN (which EFF does and which I fully support).

I agree that you should use encryption MORE.. but use it BETTER!

> > 10. The Bootstrap Fallacy: But my friends already have e-mail!
> >
> >    But everyone I know already has e-mail, so it is much easier to teach
> >    them to use PGP. Why would I want to teach them a new software!?
> >
> >    That's a fallacy. Truth is, all people that want to start improving
> >    their privacy have to install new software. Be it on top of
> >    super-surveilled e-mail or safely independent from it. In any case you
> >    will have to make a [18]safe exchange of the public keys, and e-mail
> >    won't be very helpful at that. In fact you make it easy for Mallory to
> >    connect your identity to your public key for all future times.
> >
> >    If you really think your e-mail consumption set-up is so amazing and
> >    you absolutely don't want to start all over with a completely different
> >    kind of software, look out for upcoming tools that let you use mail
> >    clients on top. Not the other way around.
> 
> I don't even get what you're saying here.  What, do you suggest, is the new
> software to teach people if not PGP?

I am saying that teaching people PGP is MORE work than getting them
to installed any of
- Pond
- Briar
- RetroShare
- Bitmessage

And that I hope that we will have more projects to list and that we will
not feel guilty for doing so. RetroShare has a terribly confusing UI (but
the developers are just waiting for some UX designer to tell them what to
do) and I bet the others need a hand on that front, too.

> > But what should I do then!??
> >
> >    So that now we know 10 reasons not to use PGP over e-mail, let's first
> >    acknowledge that there is no easy answer. Electronic privacy is a crime
> >    zone with blood freshly spilled all over. None of the existing tools
> >    are fully good enough. We have to get used to the fact that new tools
> >    will come out twice a year.
> 
> Cop-out. "Don't use PGP but I can't suggest anything for you."  Silly.

Where does it say that?

Here comes the part that you were missing:

> >    In the [09]comparison we have listed a few currently existing
> >    technologies, that provide a safer messaging experience than PGP. The
> >    problem with those frequently is, that they haven't been peer reviewed.
> >    You may want to invest time or money in having projects peer reviewed
> >    for safety.
> >
> >    Pond is currently among the most interesting projects for mail privacy,
> >    hiding its padded undetectable crypto in the general noise of Tor. Tor
> >    is a good place to hide private communication since the bulk of Tor
> >    traffic seems to be anonymized transactions with Facebook and the like.
> >    Even better source of cover traffic is file sharing, that's why
> >    RetroShare and GNUnet both have solid file sharing functionality to let
> >    you hide your communications in.

You gave up reading just a few paragraphs too early....

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