[liberationtech] 10 reasons not to start using PGP

----- 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-secur... 09. http://secushare.org/comparison 10. http://crypto.stackexchange.com/questions/10493/why-is-tls-susceptible-to-pr... 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