Agreed. The threat model discussion clearly is too often lost in all the current post-Snowden debates. We need to remember that a lot if solutions might not be enough to protect anyone against NSAish authorities but more than enough against other, most real, threats to peoples personal safety. Regular employers, schools, parents, skiddies, whatever.
Marcin > 10 okt 2013 kl. 22:11 skrev Pranesh Prakash <pran...@cis-india.org>: > > Interesting. But someone should also write a piece called "1 reason not > to criticise security tech without clearly stating threat model which > serves as basis for that criticism". What if Mallory isn't a > well-funded governmental organization but is the admin who runs your > employer's email servers? > > This should actually be two lists: reasons not to use e-mail, and > reasons not to use OpenPGP over e-mail. > > Only reasons 2, 3, 4, 5, 7, 8 are really about OpenPGP (you should've > stuck to "6 reasons not to use PGP"), and at least three of them are > really good reasons to look for alternatives. There are no good > alternatives over e-mail: S/MIME unfortunately suffers from many of the > same issues as OpenPGP, and then some more. > > And reason #1 is something that the client should take care of (ideally > with default settings), and not the encryption protocol. Why are you > attacking OpenPGP and OTR for this? > > And thank you so much for the comparative chart. It is *very* useful. > > Why doesn't telephony have SIP? > > ~ Pranesh > > carlo von lynX [2013-10-10 15:23]: >> 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. > > -- > Pranesh Prakash > Policy Director > Centre for Internet and Society > T: +91 80 40926283 | W: http://cis-india.org > PGP ID: 0x1D5C5F07 | Twitter: @pranesh_prakash > -------------------+ > Postgraduate Associate & Access to Knowledge Fellow > Information Society Project, Yale Law School > T: +1 520 314 7147 | W: http://yaleisp.org > > -- > 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 > compa...@stanford.edu. -- 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 compa...@stanford.edu.
