[liberationtech] 10 reasons not to start using PGP
Eugen Leitl
eugen@leitl.org
Fri Oct 11 01:14:17 PDT 2013
----- Forwarded message from carlo von lynX <lynX@time.to.get.psyced.org> -----
Date: Thu, 10 Oct 2013 21:23:28 +0200
From: carlo von lynX <lynX@time.to.get.psyced.org>
To: liberationtech@mailman.stanford.edu
Subject: [liberationtech] 10 reasons not to start using PGP
Message-ID: <20131010192328.GA18814@lo.psyced.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Reply-To: liberationtech <liberationtech@lists.stanford.edu>
We had some debate on this topic at the Circumvention Tech
Summit and I got some requests to publish my six reasons
not to use PGP. Well, I spent a bit more time on it and now
they turned into 10 reasons not to. Some may appear similar
or identical, but actually they are on top of each other.
Corrections and religious flame wars are welcome. YMMV.
----------------------------------
TEN REASONS NOT TO START USING PGP
----------------------------------
Coloured version at http://secushare.org/PGP
[01]Pretty Good Privacy is better than no encryption at all, and being
[02]end-to-end it is also better than relying on [03]SMTP over [04]TLS
(that is, point-to-point between the mail servers while the message is
unencrypted in-between), but is it still a good choice for the future?
Is it something we should recommend to people who are asking for better
privacy today?
1. Downgrade Attack: The risk of using it wrong.
Modern cryptographic communication tools simply do not provide means to
exchange messages without encryption. With e-mail the risk always
remains that somebody will send you sensitive information in cleartext
- simply because they can, because it is easier, because they don't
have your public key yet and don't bother to find out about it, or just
by mistake. Maybe even because they know they can make you angry that
way - and excuse themselves pretending incompetence. Some people even
manage to reply unencrypted to an encrypted message, although PGP
software should keep them from doing so.
The way you can simply not use encryption is also the number one
problem with [05]OTR, the off-the-record cryptography method for
instant messaging.
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.
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?
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.
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.
5. Cryptogeddon: Time to upgrade cryptography itself?
Mallory may also be awaiting the day when RSA cryptography will be
cracked and all encrypted messages will be retroactively readable.
Anyone who recorded as much PGP traffic as possible will one day gain
strategic advantages out of that. According to Mr Alex Stamos that day
may be closer than PGP advocates think as [13]RSA cryptography may soon
be cracked.
This might be true, or it may be counter-intelligence to scare people
away from RSA into the arms of [14]elleptic curve cryptography (ECC). A
motivation to do so would have been to get people to use the curves
recommended by the NIST, as they were created using magic numbers
chosen without explanation by the NSA. No surprise they are suspected
[15]to be corrupted.
With both of these developments in mind, the alert cryptography
activist scene seems now to converge on [16]Curve25519, a variant of
ECC whose parameters where elaborated mathematically (they are the
smallest numbers that satisfy all mathematical criteria that were set
forth).
ECC also happens to be a faster and more compact encryption technique,
which you should take as an incentive to increase the size of your
encryption keys. It is up to you to worry if it's more likely that RSA
or ECC will be cracked in future, or you may want to ask a
mathematician.
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.
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.
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.
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.
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.
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.
Mallory has an interest in making us believe encryption isn't going to
work anyway - but internal data leaked by Mr Snowden shows that
encryption actually works. We should just care to use it the best way.
That means, not with PGP.
There is no one magic bullet you can learn about.
You have to get used to learning new software frequently. You have to
teach the basics of encryption independently from any software,
especially from the one that does it wrong the most.
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.
Mallory will try to adapt and keep track of our communications as we
dive into cover traffic, but it will be a very hard challenge for him,
also because all of these technologies are working to switch to
Curve25519. Secushare intends to only support Curve25519 to impede
[10]downgrade attacks. Until the next best practice comes out. It's an
arms race. Time to lay down your old bayonet while Mallory is pointing
a nuclear missile at you.
Thank you, PGP.
Thank you Mr Zimmermann for bringing encryption technology to the
simple people, back in 1991. It has been an invaluable tool for twenty
years, we will never forget. But it is overdue to move on.
References
01. https://en.wikipedia.org/wiki/Pretty%20Good%20Privacy
02. http://secushare.org/end2end
03. https://en.wikipedia.org/wiki/SMTP
04. https://en.wikipedia.org/wiki/TLS
05. https://en.wikipedia.org/wiki/Off-the-Record_Messaging
06. http://tools.ietf.org/html/rfc4880
07. https://en.wikipedia.org/wiki/Deep_packet_inspection
08. http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security
09. http://secushare.org/comparison
10. http://crypto.stackexchange.com/questions/10493/why-is-tls-susceptible-to-protocol-downgrade-attacks
11. http://en.wikipedia.org/wiki/man-in-the-middle%20attack
12. https://en.wikipedia.org/wiki/Forward_secrecy
13. http://www.heise.de/tr/artikel/Die-Krypto-Apokalypse-droht-1942212.html
14. https://en.wikipedia.org/wiki/Elliptic_curve_cryptography
15. http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-algorithm/
16. https://gnunet.org/curve25519
17. https://en.wikipedia.org/wiki/steganography
18. http://secushare.org/rendezvous
P.S.
Thanks for feedback to tg, duy and especially Mr Grothoff.
--
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
More information about the cypherpunks
mailing list