[liberationtech] 10 reasons not to start using PGP
Jason Gulledge
ramdac at ramdac.org
Thu Oct 10 12:53:04 PDT 2013
Also, the premise of your argument, "10 reasons not to start", presupposes the truth of your argument, essentially begigng the question. Not that it makes your other arguments invalid, but I cringed when I saw the title, and also laughed.
- Jason Gulledge
On Oct 10, 2013, at 9:40 PM, Jillian C. York <jilliancyork at gmail.com> wrote:
> In my opinion, this makes about as much sense as telling people who are already having sex not to use condoms.
>
> 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).
>
> 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.
>
> (Detailed snark in-line)
>
>
> On Thu, Oct 10, 2013 at 12:23 PM, carlo von lynX <lynX at time.to.get.psyced.org> 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.
>
> Okay, I'm not going to argue that PGP isn't hard or that people don't use it incorrectly at times. But would you say "don't use condoms because they're ineffective sometimes"? No, you would not.
>
> This is a reason to improve the UI of PGP/OTR for sure, but not a reason not to use it.
>
>
> 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.
>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Steganography, really? Sigh.
>
>
> 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.
>
> 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.
>
> 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).
>
> 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?
>
> 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.
>
> 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 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 | twitter: @jilliancyork
>
> "We must not be afraid of dreaming the seemingly impossible if we want the seemingly impossible to become a reality" - Vaclav Havel
> --
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20131010/4fe449ac/attachment-0001.html>
More information about the liberationtech
mailing list