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

carlo von lynX lynX at time.to.get.psyced.org
Thu Oct 10 12:23:28 PDT 2013


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.




More information about the liberationtech mailing list