Stop Using Encrypted Email (2020)

Well, you might argue Matrix stores meta data server side (the ones chosen), while Signal at least doesn't have to.

But do you really want to give up all that freedom trusting a single service provider in that really no data is kept?

Maybe you can wait until Matrix allows you to avoid signing up on a server using P2P[0], then you have got it all, and don't have to commit to an alternative that has advantages, but also big draw backs.

[0] https://news.ycombinator.com/item?id=27077660

This is my problem with the article. It feels like it suffers from a bit of zero-sum fallacy. The statement here is, "it can be broken therefore it's fundamentally broken." I think it's more useful to think in terms of probabilities. If I disable password authentication for SSH and require public key authentication on my web server, an attacker can still get in by stealing my private key. That isn't a reason to take the opposite approach however - botnets commonly employ password-guessing attacks against entire IP ranges so you're not actually safer by avoiding this practice just because it isn't a perfect solution. There is no silver bullet for security, only endless layers of strategies and adaptations to edge cases.

I did enjoy some of the points about the limitations of email encryption (the email chain example is a great reminder of how security is often more about human behavior than software). But I think the article could have been more compelling had it presented a less dogmatic thesis - perhaps "Email Encryption Won't Save You" or something like that.

some of these authorities have all sorts of structure to prevent corruption. passionate people, nonprofit or open governance. however, they are still single points of failure, or targets, or whatever you'd like to call them.

it seems that after years of pain with poor effectiveness of specification or poor verification tools for implementations, it has become en vogue for modern cryptosystems to insist on tight centralized control of reference implementations to ensure correctness. (otherwise known as the apple computer model). while this does seem to work in terms of ensuring high quality and problem free implementations, it does open up the single point of failure issue.

i'd argue that email's replacement must retain email's greatest quality: it's an open specification, not a system or implementation owned or controlled by a single entity and that the true challenge in bringing it to fruition won't be clever protocol and cryptographic design (although these will be crucial) but also substantial advances in protocol definition and implementation verification such that any competent developer can implement compatible components and plug them in.

For messaging, we need something that is end to end encrypted by default, and is also only available in an e2ee format. Decentralization is an additional bonus, but really as long as the protocols are heavily audited and the clients are reasonably open (reproducible builds etc), it doesn't matter what your choice is and what networks your messages go through/who controls them.

But.

> If messages can be sent in plaintext, they will be sent in plaintext.

This format is such a common line of attack in critiques of technology that I think it needs a new logical fallacy coined to describe it. I've seen it used as the primary basis for entire "x considered harmful" essays (thankfully not the case here as the rest of the bullet points more than hold up without it).

The idea that many people will use technology wrong is not an argument in itself against that technology. It's essentially an argument against UX, which is important (especially in the case of security) but while a false sense of security is much worse than no security, that doesn't justify advocating against correct application of that technology (or against efforts to improve the UX of said tech).

As mentioned the point here is moot given encrypted email's other larger failings, but without them this point simply wouldn't stand.

(I get what the author is trying to say, I'm just reacting to the strange way the argument is phrased. I don't think they thought their wording and reasoning in that passage through enough.)

https://www.youtube.com/watch?v=FUPstXCqyus

"You can’t hide secrets from the future with math. You can try, but I bet that in the future they laugh at the half-assed schemes and algorithms amassed to enforce cryptographs in the past"

E2EE only guarantees encryption in transit between two end nodes. Infrastructure between those two nodes can't read or alter the payload. That is the only thing it guarantees. Once an end node receives a message any guarantees of encryption/safety go out the window.

There's no guarantee the intended recipient is in possession of the end node or someone isn't shoulder surfing them. There's also no guarantees the end node's local message storage will remain secure in perpetuity.

There's also no guarantee that the metadata of messages, even sent through a nominally secure service, will also remain secure in perpetuity. Signal as a service might be very secure and will never leak metadata but there's no guarantee of that especially if state funded malefactors target the service.

The security of messages at rest is pretty similar between PGP e-mail and Signal messages. Signal's metadata is more secure than e-mail by default but that may not always be true.

This is news to me, but I’ll admit I’m one of those technologists who doesn’t understand it enough. Can anyone point me to more info on this?

There are a lot of cases where I don't have any reason to care about metadata leaks. I've written plenty of reports for example where it was no secret that I was writing the report, what it was about, about how long it would be, when it would be finished, and to whom it was to be delivered.

As far as I can see delivering those reports as encrypted attachments to email would be fine.

> Every archived message will eventually leak

My encrypted attachment would be fine with this too. If some receiver archives the email the attachment will be encrypted in the archive.

https://darkmail.info/

Thunderbird supports it. Apple Mail supports it. Gmail does (but not for free accounts).

It's the core of the DIRECT Messaging protocol we use in healthcare. There are millions of messages being sent via DIRECT every week.

Mind, DIRECT is more than just S/MIME, it's a just a component of it (there's an entire trust system involved as well).

I appreciate the issue with leakage, which are very real, mostly due to the UI of the systems. I honestly don't know how well the programs like Apple Mail et al keep you from shooting yourself in the foot with S/MIME encrypted mail (such as "You're about to forward an encrypted email in the clear, are you sure you want to do that?").

The post bags on PGP, so I'm just curious if there are weaknesses inbuilt to S/MIME.

This is about the equivalent of not just throwing out the baby with the bath water, but taking the baby putting it in a rocket and launching it at the moon.

Never assume a network is private, never assume anything communicated over anything other than a piece of paper passed between two human beings in a secure room is private, and even then be suspicious.

But for gods' sake, use encrypted email.

A tool (like PGP) does not imply a privacy-guaranteed scenario. For an analogy, carrying a handgun does not make you James Bond, and carrying a lockpick does not make you a locksmith. They are just tools, and possessing one of them [like PGP] does not intrinsically include the knowledge and ability to use that tool properly.

Essentially, their argument is: Metadata isn't protected, and mail gets archived when perhaps you want messages to disappear. If you're writing messages on any system with the assumption they aren't stored somewhere indefinitely, you're already failing, buckaroo.

Sadly without reference. Does anyone know more about this?

That's why I use matrix, but I fear it will not catch on enough, and email will be the only option people will have to contact me. But I somehow agree that encrypting email is not an option as there are too much complications to it.

Encrypted email can be done exclusively in very safe places and the secret key that protects both the transferred and saved messages can be protected very well. This is entirely because of the difference in the mediums. Email can be completely locked up in any sort of dangerous environment because it is inherently offline. Something like instant messaging has to expose the secret stuff all the time to produce all the time access.

There might be people who like to LARP their encrypted email and that is a legitimate thing to do. There are people that actually need the level of security that can be provided by an asynchronous messaging system like encrypted email.

AFAIK Google (via GMail) reads emails from/to “normal people”. Is Google not a “powerful adversary”?

defeatist bullshit from the article:

>Every long term secret will eventually leak.

is not a valid excuse for abandoning PGP or encrypted email, its wishful thinking at best.

>The standard and best answer here is Signal

Signals github releases are sporadic at best and hard to compile consistently. its also centralized and has a dependency on google services to operate and lacks real transparency about its outages or plans to scale/operate, but at least its not too hard for you.

>Hop-by-hop encryption is a good thing: it makes untargeted dragnet surveillance harder.

the devices that handle this mail are commercial MTAs and are already largely backdoored by three letter agencies. a poison prime here, a weak cipher there, or even an opportune warrantless surveillance national security letter can sidestep this easily. companies will bend to the rule of US law.

>PGP don’t make this kind of surveillance any harder, and a targeted attacker will still get access to mail servers and messages.

this is a tangible, almost white-hot ignorance i cant abide. yes. youll get a PGP message. that message is encrypted with an asymmetric key and with a strong passphrase will have your adversary guessing until the last star falls from the heavens* and the statute of limitations for what was once your proud nation finally expire. PGP was invented to secure things that were transmitted IN PLAINTEXT.

trust was sacrosanct as you were expected to verify and know the person to which you were sending...you had keysigning parties and you used PGP to talk about important things with people you trusted. PGP is still valid and useful to this day.

* quantum computing may make this easier, but if it does, post-quantum ciphers are still an option