+1 - you said it much better than me.
On Thu, Oct 10, 2013 at 1:55 PM, Enrique Piracés <enriq...@benetech.org>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi there, > > I think this is a good topic for debate among those who can or are > currently developing security tools/protocols, and it is one way to > further discuss usability as a security feature in communities like > this one. That said, I think it is really bad advice and I encourage > you to refrain from providing this as a suggestion for users who may > put themselves or others at risk as a result of it. > > Also, I think the title is misleading, as most of the article is about > why PGP is not an ideal solution for the future (a point where I think > you would find significant agreement). Again, suggesting not to use > PGP without providing a functional alternative is irresponsible. > > Best, > Enrique > - -- > Enrique Piracés > Vice President, Human Rights Program > Benetech > > https://www.benetech.org > https://www.martus.org > https://www.twitter.com/epiraces > > On 10/10/13 3:23 PM, carlo von lynX 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. > > > > 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. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.20 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQEcBAEBCgAGBQJSVxRLAAoJEDU0GlswZf+d7UQH/0pn157xP9AmSawV93Oced8v > Sfy/lNudnO+beZ/TPLsYkD+Hd/AjcRDdX+h7f6r+5AWsKpHtDdCQ8NTzWchDAwtr > 2sLqXILAAavqAbtzzZO7mQs98r0WJimhmJCizxYW/LgjhDEQ+vryCpBqkvaH5sth > dM6bJCPJ6zad83ZARM0KNyYme3Jw1tAxqZJJLtsi/U/eqCqawcVy5WO7a3U4T/TP > 0Q9rlYxheUpB9bB/PLJ5brpgFvpXpm0Wv27ocKQAHA0RjugbM24Zuap77MtWqSen > GXy089iikDhD7DS3GH0re6dNtpvZDPj3PgaG4UuPTPBjIMo4CenBYtPc3JICjXM= > =G3UK > -----END PGP SIGNATURE----- > -- > 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 <http://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.
