It is unlikely that built-in email encryption will ever be available in Gmail | Hacker News Reader

It is unlikely that built-in email encryption will ever be available in Gmail

tutanota.com

196 pointswil_I_am_2763 comments

> While it is possible to encrypt certain emails in Gmail with GPG, Google can still read all email meta-data such as email addresses and subject lines. Better use a Gmail alternative that encrypts your entire mailbox and contacts automatically.

This is nonsense. Any email service will be able to see the recipients (and senders) of your messages, because that's how email works. Subject lines too, again, because that's how email works.

E2E encryption of email is a good thing, GPG is hard. These things have be true forever.

Yes, email providers must see sender and recipient email addresses, and corresponding server names (and how to reach them). However, if you and your correspondents use ~anonymous email accounts, none of that get's tied to meatspace. And if you're really paranoid, you can have multiple accounts, and mix them up.

About 30 "activist" email providers exchange messages via Tor onion addresses.[0,1] But you still need to trust your provider, unless you trust your OPSEC enough.

Back in the day, we had Mixmaster remailer nyms, with PGP and message delivery to alt.anonymous.messages. You downloaded all messages, and then selected based on public key. But not enough people ever used it, so the anonymity space was tiny. But there is still activity. I recently came across something ~new on Github, but I don't remember exactly what.

0) https://github.com/ehloonion/onionmx/blob/master/sources/map...

1) https://riseup.net/en/email#what-is-special-about-riseup-ema...

> "But you still need to trust your provider"

When it comes to the security or privacy of your messages, if you really, really need it, then you cannot trust your provider and that's the whole point of end-to-end encryption.

If you're an activist whose life would be threatened if those messages got out, then you'd better make sure that any information you leak to your email service provider cannot be tied to you, no matter how much you trust that provider.

> "if you and your correspondents use ~anonymous email accounts"

Note that anonymity is earned by you via the steps you take to open and use that email account.

For example, if you're logging in to that email account from your home IP and you're being targeted by some security organization or crime syndicate with enough resources, who your email provider is will be absolutely irrelevant.

OK, you're right. You can't trust anyone.

> Note that anonymity is earned by you via the steps you take to open and use that email account.

That's what I meant by "unless you trust your OPSEC enough".

However, not all of us are " activist[s] whose life would be threatened if ... messages got out". So I think there is some value in providers who will protect you, if your OPSEC is weak. If nothing else, it's failsafe. Like climbing with a rope.

It's a pity that anonymous remailers aren't more widely used, but I've been thinking of an 80/20 solution that might be easier to adopt.

Imagine that alice@protonmail wants to send an encrypted message to bob@tutanota and they both have each other's PGP keys. What these email providers could do is offer a reserved email address (such as remailer@) with its own associated PGP public key. (The address and the public key could be stored in the DNS, or retrieved via some HTTPS .well-known URL).

This way alice@protonmail could encrypt a message (including headers) to bob@tutanota using his private key, and then encrypt this inner message as the body of a message sent to remailer@tutanota. ProtonMail would only see that Alice is communicating with a Tutanota user, and Tutanota would only see that Bob is communicating with a ProtonMail user. (For the specific case of webmail providers, you would also want something like SXG [1] combined with Binary Transparency [2] to prevent malicious JavaScript being served).

[1] https://developers.google.com/web/updates/2018/11/signed-exc...

[2] https://wiki.mozilla.org/Security/Binary_Transparency

That is an interesting idea.

However, remailers are vulnerable. For example: https://riseup.net/en/about-us/press/fbi-seizes-anonymous-re...

> However, if you and your correspondents use ~anonymous email accounts, none of that get's tied to meatspace.

Anyone else here remember anon.penent.fi, or am I simply old? :)

* https://en.wikipedia.org/wiki/Penet_remailer

Also, mixmasters:

* https://en.wikipedia.org/wiki/Anonymous_remailer

I think that using anon.penent.fi was one of my first attempts at anonymity. Then I discovered mixmaster remailers and nyms.

I used Private Idaho for Windows, and then Quicksilver. Just a few years ago, I got Quicksilver running in Wine in Whonix. There were (maybe still are?) some nymservers, remailers and news servers running as Tor onions.

GPG 2.0 now supports encrypting the Subject line.

It does? As a user I'm interested. How does that work?

While as the parent points out some header info has to remain available to deliver the mail correctly I always thought that it was a huge weakness that the subject wasn't encrypted as it could potentially leak some critical information. I didn't think there was a solution to this problem.

In SMTP only the envelope headers are really required to be unencrypted. The rest, including the actual To, From and Subject fields are part of the payload. You can use milters that look at the payload which can affect email delivery (think anti virus) but that is separate from the protocol itself.

The "envelope headers" are not really part of the email though, they are just SMTP protocol messages (commands) required to get to the point where you can pipe/stream the actual mail body (payload) through. Though every MTA prepends stuff to the payload (Received headers, etc.).

This is probably what they are referring to: https://github.com/autocrypt/memoryhole

The Autocrypt team are doing some great work, and I really hope they prove that OpenPGP can provide the basis for a backwards compatible and secure email system, which works without requiring the user to necessarily understand the underlying cryptography (just as HTTPS has succeeded).

Making email more secure than it currently is seems like quite a low bar to reach, even if perfect security remains impossible to achieve.

https://autocrypt.org/

The RFCs for the SMTP protocol call what is read by the server.

Reading RFCs is fun :)

Hmm...the pgp emails I've received recently either have no subject or the subject is "Encrypted Email".

>Subject lines too, again, because that's how email works.

Yeah, it's not though.

https://www.enigmail.net/index.php/en/user-manual/handbook-f...

There's nothing about Gmail that prevents you from encrypting your subject lines.

The most important metadata however is whom your communicating with. And there's nothing in GPG that can protect the addresses of your recipients, because it's not possible due to the email protocol.

> because it's not possible due to the email protocol.

Or any other protocol that's not crazy paranoid as anonymous PGP messages on alt.anonymous.messages.

This.

Can we please kill the idea of "safe email" forever. Email leaks like a sieve. In fact, It would be interesting to see if the Carbon Copy (CC:) feature of email violates GDPR.

Don't even get me started on domain spoofing.

I get so much junk every day due to bounce backs of people spoofing my domain to send junk.

SPF, DKIM and DMARC have done (and can do) nothing to help.

Email is broken, and this, sadly, is the price we pay for the federation it provides for a technology of its age.

Are you sure your server is correctly configured? I host my own server on a custom domain and while I do receive a non-negligible amount of spam I don't think I've ever noticed my domain being spoofed.

>SPF, DKIM and DMARC have done (and can do) nothing to help.

Isn't that precisely what these technologies are supposed to help? Why do you say that they can't do anything?

Sadly, as the other commenter has pointed out, they rely on the recipient server understanding them.

A lot of the fails I get are due to non-existent recipients, full mailboxes and some that detect it as spam end up replying (to me) just to tell me that they've detected it as spam (which I know already, and would prefer they didn't aggravate the issue by replying).

Bear in mind, I'm not talking about recieving spam directly (I get almost none) I'm talking about "back scatter" from innocent (but perhaps poorly configured) mail servers telling me they couldn't or wouldn't deliver "my" email.

This all goes to randomly generated addresses at my domain (which the spammers using my domain are generating), which I receive at my catch-all and may have to consider disabling, while ensuring my mail server doesn't also notify them that it didn't deliver their bounce back (otherwise I'm perpetuating the issue) all at the risk of losing legitimate emails if they're miss-spelt etc.

You are right that they are designed to prevent spoofing. The problem is that the recipient server needs to be configured to use it and not all servers do, for reasons spanning false positives to ignorance. So if you have a fairly old or known domain you will get non trivial amounts of backscatter from spoofed email being sent to invalid or otherwise rejected addresses.

100% agree. I remember a friend who typed in SMTP commands to send his dad a Christmas email from santa@northpole.com.

There are alternatives, they just haven't caught on as an email replacement. For example, I suspect the Extensible Messaging and Presence Protocol (XMPP) can do everything email can do, and it supports E2E encryption. XMPP addresses would still be exposed, as any messaging needs the message routing information decryptable by the server, but much better that email.

    > telnet mailserver.com 25
    HELO me
    MAIL FROM: santa@northpole.com
    RCPT TO: friends@dad.com
    DATA
    You've been a good boy.
    Santa
    .

Syntax error.

Good call, needs more colons.

Spoofing email is trivial but it's also usually trivial to detect, at least if the real provider uses modern technologies like SPF, DKIM and DMARC. I can easily forge an SMTP message from sjobs@apple.com and send it from my computer but it'll be considered junk by any mail service worth using.

The feature itself obviously doesn't (there's many uses of it where sharing the information is intended and legal, e.g. CC-ing multiple people involved with the same thing and knowing each other so it is clear everyone has seen it), but using it wrong can be a violation (e.g. CC-ing all your customers, who have no need to know about each other)

Three things:

1. Nothing is ever absolutely safe. Everything can leak at some point or another be it only because someone whipped their phone out and took a picture of the screen.

2. Just because it can not be made 100% safe, doesn't mean no efforts should be undertaken to push things in that direction.

3. Despite being well-spirited, DGPR is a retarded piece of legislation. Bested only by the EU cookie law.

> 3. Despite being well-spirited, DGPR is a retarded piece of legislation.

Why? As someone (currently) in the EU I'm quite happy with it.

In regards to 3. why exactly is not using CC for mailing lists "retarded" (very poor choice of words by the way). Just because I'm on a mailing list doesn't mean everyone in that mailing list should see my mail address and the fact that I'm subscribed. That is exactly what BCC is for so why not use it?

Eh? Nobody mentioned mailing lists except you. The guy who brought up GDPR was suggesting that the CC feature in itself might be a GDPR violation. You, on the other hand, are talking about a specific use of CC that people broadly agree is wrong, but presenting that as if it's the same thing as what the first guy said.

This is like somebody calling for a law that bans all cars, someone else calling that retarded, and you coming along and saying Why exactly is it retarded not to drive on the pavements? That's what roads are for!

Well it clearly depends on how you use the CC feature, most of the complains about CC have been in regards to mailing lists as that's where obviously unwanted information leaks happen.

"the CC feature in itself might be a GDPR violation" is a, to use your words, "retarded" idea. For starters you can still send emails internally, perfectly fine to use CC there. Also I'm sure there are some legitimate interest cases where CC instead of BCC makes sense too.

This is classic GDPR fear mongering and laziness.

> "the CC feature in itself might be a GDPR violation" is a, to use your words, "retarded" idea

Well, yes, I agree.

> This is classic GDPR fear mongering

Well, no. The person who suggested that it's a violation is anti-email, not anti-GDPR; it's implicit that they think it would be a good thing if the CC feature were inherently illegal.

This is a promotion article for an end-to-end encrypted mail service called tutanota. They claim that google abandonment of the mail encryption project impiles that gmail encryption will necessarily never be available for gmail users.

It was dead the moment they put it on Github. Their blog post[1] claimed:

> E2EMail is not a Google product, it’s now a fully community-driven open source project, to which passionate security engineers from across the industry have already contributed.

But looking at the commit history[2] makes it clear that was not the case at all.

Although this post is by Tutanota (and I can't tell if Tutanota supports PGP), Protonmail does support PGP emails.

1: https://security.googleblog.com/2017/02/e2email-research-pro...

2: https://github.com/e2email-org/e2email/commits/master

All email services selling encrypted email as a service are snake oil in my opinion.

You won't gain anything more than when using GPG by yourself, except you're now trusting a third-party app to do it for you, using a non-standard adapter for allowing IMAP / SMTP apps to still work while at the same time obscuring the fact that end-to-end encryption will only happen when the recipients support it as well, which is at most 1% of all recipients you're communicating with.

AKA "death by open sourcing it", the hideous cousin to the equally awful "Death by acquisition" (aka "We will continue working on this now that we've been acquired").

I know it's a bit old, but since I read this I cannot possibly take Tutanota seriously on anything crypto:

https://tutanota.uservoice.com/forums/237921-general/suggest... https://seclists.org/fulldisclosure/2015/Jun/58

The article has a point but do know that Tutanota is using their own custom encryption scheme. I can understand they don't want to support PGP if they have something better but judging from their FAQ [0] they just replicated what PGP already can do [1] [2] effectively reinventing square wheel.

As for browser encryption Mailvelope [3] works and can even use local GnuPG (through NativeMessaging). FlowCrypt [4] is a little bit more tightly integrated with Gmail (through their API).

[0]: https://tutanota.com/faq/#pgp

[1]: "That's why we have developed a solution that is also based on recognized algorithms (RSA and AES) and that automatically encrypts the subject, the content and the attachments."

[2]: https://github.com/autocrypt/memoryhole#memory-hole-protecte...

[3]: https://www.mailvelope.com/en

[4]: https://flowcrypt.com/

Hmm. Solutions like signal or whatsapp also used their "own custom encryption scheme" (in that sense), instead of PGP.

I'm not sure PGP is actually good enough that alternatives aren't desirable. Here's a Wired article saying "PGP is dead... use Signal for your encrypted messaging instead": https://www.wired.co.uk/article/efail-pgp-vulnerability-outl...

Here's respected cryptographer Matthew Green saying PGP is "a model of email encryption that’s fundamentally broken" in 2014. https://blog.cryptographyengineering.com/2014/08/13/whats-ma...

I think there was another more recent "what's the matter with PGP" post I saw on HN, I found these above while trying to see if I could remember what I saw more recently.

> Solutions like signal or whatsapp also used their "own custom encryption scheme" (in that sense), instead of PGP.

But Signal's "own custom encryption scheme" have obvious advantages over PGP, for example forward secrecy. That's what I meant by "I can understand (...) if they have something better".

In Tutanota's case judging from their public descriptions the scheme doesn't have any advantages over PGP as it is currently used.

Implementing custom crypto usually ends up with something like this: https://tutanota.uservoice.com/forums/237921-general/suggest...

If you're providing an encryption service and not doing it well, that's certainly a problem.

There are various levels of "custom". I'm not sure anything that isn't PGP is "implementing custom crypto" in the same way; you could be using a good crypto library like NaCL -- or not -- for instance.

But you gotta know what you're doing. With so much critique of PGP though, I'm not sure "using PGP or not," or suggesting that using PGP is the obvious way to go, is the right line to be drawing.

But yeah, that link you provide to an issue does not one make confident that tutanota has the proper staffing to do crypto right.

In the meantime I'm using mutt on the desktop on K9 on Android. I have to say that K9 is brilliant (mutt less so, but I like it ;-)). It's the closest "it just works" E2E mail client I've ever used. Unfortunately the reality of PGP is that it's hard for a normal person to use, although I've got my Dad using it for all of our email.

We need the Dark Mail Alliance more than ever.

https://en.wikipedia.org/wiki/Dark_Mail_Alliance

https://darkmail.info/downloads/dark-internet-mail-environme...

https://github.com/lavabit/

GPG is hard for some, but 7-zip is easy for most. Not perfect, but perfect is enemy of good. Just put your email, files, whatever in a 7-zip encrypted and compressed file and email that.

Tell your friend the password over voice chat, or some other chat that is in no way related to your mail provider. Even a weak password is better than trusting the mail provider to handle this job. Here is a 7-zip file with a very simple password. [1] Please reply with the contents of the text file in the 7z.

[1] - https://tinyvpn.org/5/e/f/5efed61e6efe235d965547999292279e.7...

If all one wants to do is communicate securely with another person and what your typing is private but not "illegal", then why even send email. Simply use the Drafts in GMail. Compose an email and leave it in Drafts. Each person amends the draft and they can agree on times to check and update. This has been done with great success before if you want nothing "going across the wire" so to speak.

Advertisement for tutanota. Just use GPG like everybody who knows what they're doing.

Mass surveillance is kinda Google’s model

So, I'm sure this idea has holes all over it, but how about a very simple service that you log into with your PGP public key, then would allow you to post encrypted messages to other PGP public keys and retrieve messages posted to your public key. It could be fully anonymous, depending on your choice of keys. It would be very similar to the mixmaster remailers, except it wouldn't actual mail anything as it wouldn't have any identifiable information other than the public key.

PGP itself leaks a huge amount of metadata. A known problem on open mailing lists and Usenet.

Why not something like Let's Encrypt, but for S/MIME?

That's actually what a Swiss startup called Vereign seems to be working on: https://medium.com/@ggreve/nobody-cares-about-signatures-a56...

"shows where Google's real interests are: Not in protecting their users' private data, but in harvesting it for their own benefit."

Well, Duh. That's the deal. "in exchange for this service we will scrape your data in order to serve ads". If you don't like it go somewhere else. Google doesn't owe you a free email service.

The problem with Email is that it’s routed, store and forward, whereas there’s no reason why it shouldnt be point to point.

If you wanted to revolutionize email then you’d create a point to point email service.

There's a reason peer to peer isn't seen as a great idea for messaging and that reason is it's been tried many, many times and it doesn't work well. For some people it just won't work well ever. Furthermore, it doesn't mesh with the expectations most people will have of a mail service (you push the mail out and it will arrive some day regardless of what you do), which makes it a bad fit for the use-case to begin with.

Point to point is very fragile and inflexible.

There are many good reasons for email (and internet in general) was designed to be routable.

That shouldn't be a problem if it's properly encrypted. The whole internet is routed over various switches owned by various entities.

I'm not a fan of email, and not only because of security / privacy. Yes, it's ubiquitous and convenient; and great for quick simple messages.

But it's not (in a biz / life context) a project management tool. So aside from "where do you want to go for lunch?" the appropriateness of email breaks down pretty quick. Unfortunately, the habit and convenience not so much so.

Ideally, we're nudging towards a tipping point where email gets replaced by more appropriate (planning and proj management) tools - even at the personal level.

I'm not a fan of cars, because they don't perform well in lakes. I'm hoping we're moving toward a world where we use different tools for different tasks. Something engineered to float would be much better, in my opinion.

Yes! Thank you for proving my point[1]!!

That is, at this point email is the internet equivalent of a fax machine. It's a hammer (or car) that most are using as a screwdriver (or boat). Factor in the lack of security / privacy and email should be marginalized, just as the fax machine was.

[1] Yes, I realize it was not your intent. But the fact is, your analogy is a good one for the point I'm trying to make.

Reply on news.ycombinator.com