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

Enrique Piracés enriquep at benetech.org
Thu Oct 10 13:55:40 PDT 2013


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

Best,
Enrique
- --
Enrique Piracés
Vice President, Human Rights Program
Benetech

https://www.benetech.org
https://www.martus.org
https://www.twitter.com/epiraces

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
> 
> 
> 
> [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.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSVxRLAAoJEDU0GlswZf+d7UQH/0pn157xP9AmSawV93Oced8v
Sfy/lNudnO+beZ/TPLsYkD+Hd/AjcRDdX+h7f6r+5AWsKpHtDdCQ8NTzWchDAwtr
2sLqXILAAavqAbtzzZO7mQs98r0WJimhmJCizxYW/LgjhDEQ+vryCpBqkvaH5sth
dM6bJCPJ6zad83ZARM0KNyYme3Jw1tAxqZJJLtsi/U/eqCqawcVy5WO7a3U4T/TP
0Q9rlYxheUpB9bB/PLJ5brpgFvpXpm0Wv27ocKQAHA0RjugbM24Zuap77MtWqSen
GXy089iikDhD7DS3GH0re6dNtpvZDPj3PgaG4UuPTPBjIMo4CenBYtPc3JICjXM=
=G3UK
-----END PGP SIGNATURE-----



More information about the liberationtech mailing list