Convenient End-To-End Encryption for E-Mail

Have you used Signal recently? It’s quite robust IMO, from texting to calling and everything in between. My initial reaction to the GP post was not unlike yours, but as I read on I find myself agreeing with him. Going through my email records, a vast number as he said, are automated or transactional. The only real exceptions are from older relatives sending Facebook crap, or occasional indications to and from friends who don’t use messaging apps to read a particular article or study.

Worse it’s pretty much impossible to teach people don’t want to learn how to try and make email less insecure. By contrast I found it very easy to turn people onto Signal and similar applications.

Signal != Signal Protocol. I like Signal and prefer it to the other applications, but Wire (for instance) does not need your phone number.

First of all, most messaging platforms today are encrypted, so that rfc wouldn't really apply except to monitoring by the company providing the service, and that's the price you pay for "free stuff on the internet".

Second, almost all the "attackers" are nation-states and your ISP. If it's illegal to read your mail, it should be illegal to read your email (simple regulatory fix). That just leaves spy organizations, and nobody but computer geeks and privacy nutjobs cares about that.

Oh look, another "middlebrow dismissal" (https://news.ycombinator.com/item?id=4693920) upvoted to the top of a HN post. Color me surprised.

...and if you are going to ignore what tptacek says and try it anyway, I think it can be done a little better than the submitted product (although I only skimmed their site so I might be misunderstanding a bit).

I worked at a company that had a go at end to end email encryption around 2001. The basic idea of the submitted system looks quite similar to what we did--piggyback on top of existing email clients and their messages.

However, we did not want to require modifying the MUAs or installing plug-ins or extensions or whatever a given MUA supported for that kind of stuff. We needed to support pretty much ever MUA on Windows, and writing plug-ins for each would have been impractical (and I don't think they all supported that).

So instead of hooking in directly in the MUA, our first approach would have the user configure their MUA to use a proxy, and our software installed a local email proxy. It's been a long time so I may be mixing up some projects, but I think we later did a version where we played around with intercepting things by hooking Winsock, and another version where we used the Service Provider Interface to get in there [1].

Anyway, the first time you used the proxy it would generate a key pair for you, and then on your outgoing mail would put your public key in a header. If incoming mail had someone else's public key in the header it would import that into your keyring.

You could set it to sign your outgoing mail. I don't remember what options we have for protecting your private key. My guess is that they were weak, because as is usual when the marketing folks have too much influence, convenience trumps security.

Incoming signed mail would have the signature checked by the proxy, and it would annotate the message somehow so that the result would be visible in your email client. I don't remember if we added something to the subject, or added a status header, or added something to the body.

Encryption was similar. If the proxy saw that you were sending to some for whom it had a public key, you could set it to encrypt using that public key. (By which I mean encrypt with a symmetric cipher, and use RSA to encrypt the key...I believe we were simply using GPG).

As with signing, convenience won if it came into conflict with security, I believe (and over my objection, if I recall correctly).

From a user point of view this actually worked pretty well. As I said, we rejected the plug-in approach because it was impractical to write and maintain plug-ins for each client. However, it was practical for all the major ones (and many less major ones) to poke around in the registry or find their config file, and figure out how to programmatically edit those to change proxy settings, thus allowing our installer to find and configure all your email clients. So from the user point of view, you just installed our program, and started using email normally. After a mail and answer between two people who both used it, subsequent messages between them would be encrypted and signed.

Of course there was still the issue that this just told you that the subsequent messages were to someone who had access to the keys of the person you initially exchanged messages with at that address--it doesn't verity that they are really who you think they are. I don't remember if we had a way to go outside the system to verify someone's public key and tell the system you have done so.

As I write this, I'm now starting to think it wasn't just a simple proxy that just passed requests through, occasionally diddling the headers and the body. I think it was actually an IMAP server that stored messages itself. I think that was so it could keep copies of the encrypted incoming messages itself, and then the email clients could be configured not to store local copies of mail. That way the mail would only be decrypted when you are actually reading it in the email client.

Anyway, I think that this could have been made quite reasonable at the time (around 2001). Email has gotten quite a bit more complicated since then. Most people then only used their email from a single computer. Now they use it from 2 or 3 devices, or more, often each running a different operating system. There's no good place controlled by the user that you can put the proxy that is accessible to all of their clients, and so you really need to provide this as a service that includes a server to handle the email...but then how do you let people keep using their existing email address? I supposed you could do an ugly hack like configuring their email clients to all forward incoming mail to the service's server, which decrypts it and sends it back...yuck.

At this point it seems clear that you should just use some dedicated secure messaging app for your secrets, and keep email like it is now, as tptacek said.

In short, I think this is an idea whose time has come...and gone.

[1] I may be mixing up different projects because we had this completely insane contract at the time with one of the biggest distributors of Windows utility software in Japan to provide him with something like 12 new products a year, and new versions of 6 prior products a year, which led to a couple years where everything is largely a blur of projects that mix together in my mind.