15 ms·
Tell us your threat model. You talk about overthrowing evil regimes, organized crime, first world police and google as though they all do the same thing. https
by buzzkillington 7y ago
Tell us your threat model. You talk about overthrowing evil regimes, organized crime, first world police and google as though they all do the same thing.
https://imgs.xkcd.com/comics/security.png https://imgs.xkcd.com/comics/security.png
If your adversary is going to drop you, your family, neighbours and cat in an acid vat disappearing messages aren't going to save you.
If your threat model is organized crime, signal might be an ok solution, if you have messages set to disappearing faster than you would tell them your password after they start sanding your feet off.
If your model is first world law enforcement I hope you or anyone you care about have never committed any crimes ever because you will have the book thrown at everything you might have done: https://www.goodreads.com/book/show/6611240-three-felonies-a-day https://www.goodreads.com/book/show/6611240-three-felonies-a...
If your model is google, then encrypted email is perfectly valid and a wonderful way to use gmail.
- jcranmer 7y agoHere's the problem with encrypted email: there is only a very, very narrow threat model that it (additionally) protects against. In any sane setup, your (and your recipient's) email client will use encrypted connections to and from your respective email servers. Any competent email provider will use MTA-STS, ensuring that no one but the sender, receiver, and respective MTAs can read the message [1]. All this happens for regular unencrypted email, without any effort on the user's part. So encrypted email purports to drop the ability to allow the MTAs to read the email. But... they don't really do that. Your email providers are required to MITM all of your email, and can trivially modify any plaintext attribute they want to. And anyone who has credentials to your email account can also trivially MITM all incoming email (and may be able to at least social engineer outgoing email, if not MITM as well). This means that pretty much any key discovery mechanism that allows an unencrypted email to initialize or update a public key is defeated [2]. So, encrypted email only provides extra security in those cases where: a) keys are negotiated completely external to email (in which case, why bother with email?), or b) you trust the email provider enough to not try to intercept your messages but not enough to not look at your messages without your permission. Given the BOFH principle (i.e., administrators have no inclination to look at your email because you're boring), that kind of means the second case doesn't really exist as a practical concern. You can improve your security in the second case simply be deleting emails from the server immediately, again not requiring encrypted email. So... why bother with encrypted email? Unencrypted is secure enough unless you're paranoid, and if you're more than very slightly paranoid, encrypted email isn't secure enough. [1] This is all happening via TLS, which has gone far, far further than PGP or S/MIME have in actually making "no one can read encrypted text" true. The latter protocols take the stance that "using the cipher.encrypt() is good enough," which has been known to be false for decades. [2] And DANE-PGP is right out, because your email provider is of course the one publishing your public key.
- tptacek 7y agoI'd love to know what you thought I got wrong.
- buzzkillington 7y ago>keys are negotiated completely external to email (in which case, why bother with email?) Because I've been using that method for close to 15 years now?
- tptacek 7y agoPeople used FTP for decades, too.
- buzzkillington 7y agoAnd they still do. I worked at a market maker that used ftp over ssh to move over 10b a year in trades between its various offices.
- angry_octet 7y agoHas anyone told them there might be a better way?
- yread 7y agoWhat is better than (S)FTP? Or do you mean MFT, AS2?
- whoopdedo 7y agoSFTP shares only those three letters with FTP but is otherwise a completely different protocol. It's also a counterpoint to one of the OP's points which is that trying to secure email is a dead-end that we should give up on. It may be possible, though very difficult, to transition to secure email. But it would have to be a brand new protocol not tacked-on to the current system. The way that SFTP is the appropriate upgrade path for FTP and not FTPS.
- joshuamorton 7y agoCan you explain how you ensure that neither you nor the recipient of your email leak your messages to an untrustworthy email provider?
- buzzkillington 7y agoYou don't. The same way that you don't ensure your recipient doesn't leak screenshots of signal conversations to icloud.
- joshuamorton 7y agoSo your threat model is "protect me from my email provider (and very little else) assuming every person I interact with has great opsec"?
- buzzkillington 7y agoMy threat model is the one that I learned at a three letter agency when I was organizing their key signing party.
- joshuamorton 7y agoThis appears to contradict your earlier comment, so I'm confused.
- tsimionescu 7y agoI think the point was that you can't protect yourself from your recipient disclosing the information, regardless of your chosen scheme,so it just doesn't matter.
- joshuamorton 7y agoThere are schemes that make it difficult for a recipient to accidentally disclose your information. PGP isn't one of them. For example a common enough way of doing PGP is to use a chrome extension that PGP-ifies your webmail. Or to use an encrypted mail service like protonmail or tutanota. In all of those cases, assuming the mail provider is untrustworthy enough that you feel the need to use e2e encryption, they can also just inject JS to steal your plaintext from the client, so you aren't really secure unless you're using an imap client, which by definition you aren't doing.