Hacker News Reader

Comment by pvg | Hacker News Reader

You can make an email-like app out of Signal but nobody would call that email since it won't work with the thing everyone else calls email. You can't just add Signal to actual email and get something with the security and privacy properties of Signal, though.

View on HN

There is, however, an app like DeltaChat that looks more or less like WhatsApp, uses AutoCrypt for E2E encryption, and uses IMAP/SMTP as its storage and transport media.

https://delta.chat/

Fun fact, the main reason I developed rpgp in the first place was to power the pgp portion pf deltachat, as we ran into the same problem of not having a good library based implementation. And spawning gnupg on a phone was never an option.

Why couldn't you have a browser extension for gmail that checked whether the other end was registered & if it was encrypt the email body before it's sent? You get transparent upgrades for your friends who have the extension installed.

The latacora link in the sibling comment covers most of that.

Nope actually it doesn’t. It makes the case that pgp is a bad implementation but makes the leap to claim that means there’s no way to improve the situation.

For example, you could run a proxy server to deliver the messages between parties. So if you’re emailing someone, the browser extension changes the address to be a server you control, sends you the encrypted email that has everything meaningful encrypted, you decrypt the part your able to (ie the intended receiver) and forward that.

As far as either email server is concerned, your email server is sending out and receiving encrypted emails but there’s no metadata to connect anyone. The key handling uses your access to the email account to validate access same as signal uses the phone number.

That seems like a pretty close system to how Signal works and I don’t see anything meaningfully different. If you do, can you actually elaborate? I don’t feel like the link you pointed me answers why my proposal would be larping security since the security and threat model feels very similar to Signal.

Here are some choice quotes I pulled out of that link and why I have problems with the claims made:

> Searchable archives are too useful to sacrifice, but for secure messaging, archival is an unreasonable default. Secure messaging systems make arrangements for “disappearing messages”.

Signal and most apps except Snapchat (which isn’t e2e afaik) don’t archive by default. But yes, it is true that having encrypted web mail and search are incompatible whereas messaging apps store the data locally and thus can provide search. You’d need a dedicated client that could store all the encrypted messages locally but people aren’t as used to for that.

> Some email clients have obscure tools for automatically pruning archives, but there’s no way for me to reliably signal to a counterparty that the message I’m about to send should not be retained for more than 30 minutes.

Talk about security LARPing. Once the message is sent you’ve lost all control of it. Your just following social contracts that the app honors the request and the user is using an unmodified app.

> No matter how good a job one does securing their own data, their emails are always at the mercy of the least secure person they’ve sent them to.

Also true for messaging apps

For example, you could run a proxy server to deliver the messages between parties.

You could just email each other your Signal ids at that point. It's no longer the email everyone thinks of as email.

The closest solution I remember to this happened roughly 15 years ago when there was a browser extension that detected pgp on Email bodies and was able to get public keys and encrypt/decrypt emails automatically or with a single click, if I recall correctly.

It felt a small team or a single person project. There was a cat and mouse game being played against Gmail interface changes, with the encryption being broken every now and then. It required me, a random user, to trust the extension developer(s) with my Gmail and gpg keys. I had fear of having an xz backdoor situation compromising my Gmail account and gpg keys.

And for this extension to succeed I also had to convince all my Gmail friends and contacts to use it, and convincing them to trust the developers of the extension as I had done.

While I felt confident that the extension was perfectly safe I didn't dare to convince my family and friends to use it because (a) I could not guarantee that the extension wouldn't be compromised in the future and (b) the chance of the extension being broken in the future due to a Gmail UI change was close to 100%. Also the more users the extension had the higher the chances for someone to attempt to infiltrate to attempt a backdoor...

If I recall correctly, eventually the developer got tired of the Gmail UI changes and increasing demands of users and moved on, stopping the development.

Anyone with time could try to develop such an extension, but there were drawbacks back in the day...

You can but if you sent the email yo someone that doesn't have the extension, they wouldn't be able to read it, and you have no way yo know who has the extension installed. That's the core problem here: pretty much nobody uses encrypted emails, so you can't send encrypted emails to them. The problem doesn't exist with Signal since everyone using Signal uses a client that supports encryption.

Discovery is a solved problem same as how signal uses phone numbers: https://support.signal.org/hc/en-us/articles/360007061452-Do...

Nothing stops you from implementing a similar mechanism based on email addresses.

Except that it’s no longer email at that point. As others have pointed out: if you want to do things right you need to violate ordinary message and metadata assumptions in SMTP, at which point you’re better off skipping the heartburn and using a modern design.

Reply on news.ycombinator.com