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 <jilliancy...@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 > <l...@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 > compa...@stanford.edu. > > > > -- > Note: I am slowly extricating myself from Gmail. Please change your address > books to: jilliancy...@riseup.net or jill...@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 > 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.
