Search Mailing List Archives
[liberationtech] 10 reasons not to start using PGP
Jillian C. York
jilliancyork at gmail.com
Thu Oct 10 14:06:07 PDT 2013
+1 - you said it much better than me.
On Thu, Oct 10, 2013 at 1:55 PM, Enrique Piracés <enriquep at benetech.org>wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> Hi there,
> 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.
> 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.
> - --
> Enrique Piracés
> Vice President, Human Rights Program
> On 10/10/13 3:23 PM, carlo von lynX wrote:
> > 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
> > Pretty Good Privacy is better than no encryption at all, and
> > being end-to-end it is also better than relying on SMTP
> > over 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 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
> > OpenPGP Message Format it is an easy exercise for any
> > manufacturer of 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 possess the private keys to your mail
> > provider's TLS connection yet, he can simply intercept the
> > communication by means of a 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 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 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 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 to be corrupted.
> > With both of these developments in mind, the alert cryptography
> > activist scene seems now to converge on 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
> > 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 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 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 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.
> 09. http://secushare.org/comparison
> > 10.
> 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> -----END PGP SIGNATURE-----
> Liberationtech is public & archives are searchable on Google. Violations
> of list guidelines will get you moderated:
> Unsubscribe, change to digest, or change password by emailing moderator at
> companys at stanford.edu.
*Note: *I am slowly extricating myself from Gmail. Please change your
address books to: jilliancyork at riseup.net or jillian at eff.org.
US: +1-857-891-4244 | NL: +31-657086088
site: jilliancyork.com <http://jilliancyork.com/>* | *
twitter: @jilliancyork* *
"We must not be afraid of dreaming the seemingly impossible if we want the
seemingly impossible to become a reality" - *Vaclav Havel*
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the liberationtech