Fastmail and email encryption

17pm · 6 Dec 2015, 09:41 PM

Hello,

I was reading this article, https://tutanota.com/blog/posts/vodafone-encryption, and wondered if fastmail is considering/thinking about supporting, end to end email encryption and/or encrypted mailboxes? (Like tutanota, posteo, protonmail, etc).

BritTim · 6 Dec 2015, 11:08 PM

Total end-to-end encryption of all email is probably not what most people want, however easy it is superficially for the user. The main problem is that you are no longer able to search your mail. Indeed, if you want to hide metadata (to/from/subject) there is a substantial overhead in even showing the normal list of messages within a folder. When network speeds and client processing power increase sufficiently, it may be possible to overcome the searching challenge by downloading and decrypting in memory all historical email, and doing the search on the client. We are nowhere near being able to do that with current consumer hardware.

For the time being, what is needed is an easy, seemless way to encrypt (and/or sign) particularly sensitive messages, on the understanding that these will no longer participate in search. One could visualize a "Send Encrypted" button on the Compose screen. This requires a standard, followed by all email clients,

There are many possible schemes. One of the most practical might be to combine a Yubikey type device for storing private keys, combined with key servers with all the public keys for all subscribers to a specific mail service, maintained by the provider. A DNS entry would identify, first that the email encryption standard is supported, and second where the provider's key server can be located.

As with all standards, it can be extremely difficult to get such an initiative going. There is a lot of work involved in implementing support and, if others do not follow, the work is wasted.

popowich · 6 Dec 2015, 11:55 PM

Quote:

The main problem is that you are no longer able to search your mail

This isn't true for all of the encrypted services. SCRYPTmail encrypts all metadata and the mailbox is searchable by a user after logging in.

Quote:

One could visualize a "Send Encrypted" button on the Compose screen. This requires a standard, followed by all email clients,

If you prefer to use a standard mail program such as Thunderbird there are PGP add-ons that senders and recipients can use, and services such as whiteout.io come to mind too.

David · 7 Dec 2015, 01:25 AM

Quote:

Originally Posted by popowich

This isn't true for all of the encrypted services. SCRYPTmail encrypts all metadata and the mailbox is searchable by a user after logging in.

Hello popowich: this thread is titled 'Fastmail and email encryption'

glass · 7 Dec 2015, 01:45 AM

Those javascript encrypted email services are essentially snake-oil. Everything is encrypted using javascript they control, if they wanted to, or were compelled, they could serve different javascript which obtains your private key.

You're trusting the server to not be evil, which defeats the purpose, as the entire point of end-to-end encryption is that you don't (or don't have to) trust the server.

BritTim · 7 Dec 2015, 04:27 AM

Quote:

Originally Posted by popowich

If you prefer to use a standard mail program such as Thunderbird there are PGP add-ons that senders and recipients can use, and services such as whiteout.io come to mind too.

PGP is a pretty sound solution for those with the knowledge to set it up and use it. I have PGP, and occasionally use it. It is worthless for sending encrypted emails to the vast majority of my correspondents. After 24 years, the general population still has not heard of PGP. Even smart phone devices do not come with it preinstalled (which would be possible with automatic key generation). Also (not a huge problem in most cases) a PGP based solution does not hide metadata.

I may look into Whiteout. As it is PGP under the covers, it does hold promise. I have some questions as to whether the private key is really secure though.

pjwalsh · 7 Dec 2015, 06:37 AM

Quote:

Originally Posted by BritTim

PGP is a pretty sound solution for those with the knowledge to set it up and use it...
I may look into Whiteout. As it is PGP under the covers, it does hold promise.

Whiteout is done.
https://blog.whiteout.io/2015/11/30/...ction-required

Unfortunate as PGP interoperability was one of its strong points. Requesting PII for registration was not.

OpenPGP is an IETF standards-track protocol. Mailvelope incorporates OpenPGP.js, now a mature and robust implementation. In August GMX & WEB.de made available PGP webmail encryption using the Mailvelope API, providing their 30 million users with accessible end-to-end email encryption.
https://www.mailvelope.com/en/blog/g...-de-launch-pgp

Something FastMail might consider.

--
For those who find the idea of PGP daunting, Mailvelope has a concise and clear introduction to public key cryptography.
https://www.mailvelope.com/help#basics

robn · 7 Dec 2015, 07:19 AM

We have no plans to do anything with client-side encryption.

Client-side encryption is a non-starter for web applications because you have no way of knowing if the crypto code running inside the browser is compromised. Your browser runs unverified code from all over the internet. It cannot be trusted.

Even if it were possible to do client-side crypto securely, not having the ability to read messages on the server means there's several crucial features we can't offer (search, IMAP, etc). It's not worth the tradeoff.

As I've said elsewhere, we're a privacy-conscious service, but not we're not chasing privacy-at-all-costs. If that's what you want then FastMail is probably not for you.

BritTim · 7 Dec 2015, 09:23 AM

Rob ... I do not think you should rule out allowing users easily to send selected emails encrypted and/or signed. I do not suggest any support for encryption of metadata.

I appreciate, for webmail, some kind of browser extension or helper application is needed to make it work properly, but this is not an absolute deal breaker IMHO, especially as you may be able to use existing solutions more or less unchanged.

I suggest the encrypted/signed message be transmitted as an attachment. I know such messages will not participate in search, but that is a tradeoff users will need to take into consideration.

Of course, encrypted messages can already be sent via Fastmail. It is inconvenient to do so. The objective should be to make existing capabilities seemless and easy for users to set up and use. Fastmail would not need to write much new code.

Demand for this is growing, and I do believe Fastmail risks losing customers with an occasional need for secure and/or signed message transmission, just on the basis that they lack this feature.

robn · 7 Dec 2015, 10:44 AM

The only way to make encryption work technically is via some non-browser application. _Anything_ in the browser, including extensions, is fundamentally insecure because you don't know when the server that provides that code gives you a compromised update.

As soon as we're working with non-browser applications, then we've got a very difficult development and support prospect. This is full-blown application development, not a "small amount of code", and we've got to do it for multiple platforms and provide a means of getting that code to you that can't be compromised (which rules out mobile app stores). And we're of course assuming that automatic OS upgrades aren't compromised as well.

And once installed, there's no way to make this as seamless as you believe. The user is now burdened with keeping a private key secure but still being able to synchronise that information between devices.

And we still have to deal with key distribution, which leads us into a more fundamental discussion about what identity actually is.

This is the extreme paranoid description, but these are actually all the factors involved in making this properly secure. If this is too much, then we need to start seriously talking about threat models. What kinds of attack are we trying to defend against here, and why? And that's a question that I have never seen answered to my satisfaction by anyone talking about "secure email".

And there's still the simple fact that we could do all this fancy stuff and it still wouldn't be any less difficult to get up and running than a regular email client with PGP installed.

We've selected a set of security features that we know we can support alongside the kind of mail service and feature set we want to provide. And that's why I say that if you care more about security features we don't have over other features we do have, maybe FastMail isn't for you. If we lose customers as a result of that position, so be it.

David · 7 Dec 2015, 12:03 PM

Speaking essentially as a non-techi, with only a limited amount of knowledge (of email conventions) I will say that if I ever really needed to send encrypted email, in a situation where privacy was essential, I would do it client side (likely using GnuPG) I would also ensure that the receiver of the message had enough knowledge (and information) to be able to decrypt it.

These are just my thoughts.

David

BritTim · 7 Dec 2015, 12:32 PM

It is clear if we want something, it will need to be a third party effort.

As Rob says, the primary concern with a browser extension is auto updating, but there are ways to disable that.

I am considering a kickstarter project to develop a Fastmail encrypt message extension. It would prompt the user through initial PGP setup, key generation and key upload to key server. It would then provide hooks for encrypting, decrypting, signing and signature checking of message attachments.

Anyone interested in collaborating to get this off the ground?

17pm · 7 Dec 2015, 02:57 PM

Quote:

Originally Posted by BritTim

It is clear if we want something, it will need to be a third party effort.

As Rob says, the primary concern with a browser extension is auto updating, but there are ways to disable that.

I am considering a kickstarter project to develop a Fastmail encrypt message extension. It would prompt the user through initial PGP setup, key generation and key upload to key server. It would then provide hooks for encrypting, decrypting, signing and signature checking of message attachments.

Anyone interested in collaborating to get this off the ground?

There's already an extension for gmail, yahoo, outlook and gmx: https://www.mailvelope.com/

Perhaps talking with the developers of said extension and asking them for FM support is easier than doing a new one all-together? I think this extension was mentioned to FM staff and they said they were not interested in helping.

jl66 · 7 Dec 2015, 03:07 PM

As Rob said before in this forum and now again: Fastmail is not for those looking for privacy or encryption. That's why I am one of those who deleted my account in FM.

robn · 7 Dec 2015, 04:57 PM

Quote:

Originally Posted by jl66

As Rob said before in this forum and now again: Fastmail is not for those looking for privacy or encryption.

That is not what I said.

6 Dec 2015, 09:41 PM	#1
17pm Cornerstone of the Community Join Date: Sep 2013 Posts: 536	Fastmail and email encryption Hello, I was reading this article, https://tutanota.com/blog/posts/vodafone-encryption, and wondered if fastmail is considering/thinking about supporting, end to end email encryption and/or encrypted mailboxes? (Like tutanota, posteo, protonmail, etc).

6 Dec 2015, 11:08 PM	#2
BritTim The "e" in e-mail Join Date: May 2003 Location: mostly in Thailand Posts: 3,095	Total end-to-end encryption of all email is probably not what most people want, however easy it is superficially for the user. The main problem is that you are no longer able to search your mail. Indeed, if you want to hide metadata (to/from/subject) there is a substantial overhead in even showing the normal list of messages within a folder. When network speeds and client processing power increase sufficiently, it may be possible to overcome the searching challenge by downloading and decrypting in memory all historical email, and doing the search on the client. We are nowhere near being able to do that with current consumer hardware. For the time being, what is needed is an easy, seemless way to encrypt (and/or sign) particularly sensitive messages, on the understanding that these will no longer participate in search. One could visualize a "Send Encrypted" button on the Compose screen. This requires a standard, followed by all email clients, There are many possible schemes. One of the most practical might be to combine a Yubikey type device for storing private keys, combined with key servers with all the public keys for all subscribers to a specific mail service, maintained by the provider. A DNS entry would identify, first that the email encryption standard is supported, and second where the provider's key server can be located. As with all standards, it can be extremely difficult to get such an initiative going. There is a lot of work involved in implementing support and, if others do not follow, the work is wasted.

7 Dec 2015, 01:45 AM	#5
glass Member Join Date: Dec 2013 Posts: 54	Those javascript encrypted email services are essentially snake-oil. Everything is encrypted using javascript they control, if they wanted to, or were compelled, they could serve different javascript which obtains your private key. You're trusting the server to not be evil, which defeats the purpose, as the entire point of end-to-end encryption is that you don't (or don't have to) trust the server.

7 Dec 2015, 07:19 AM	#8
robn Master of the @ Join Date: May 2012 Location: Melbourne, Australia Posts: 1,007 Representative of: Fastmail.fm	We have no plans to do anything with client-side encryption. Client-side encryption is a non-starter for web applications because you have no way of knowing if the crypto code running inside the browser is compromised. Your browser runs unverified code from all over the internet. It cannot be trusted. Even if it were possible to do client-side crypto securely, not having the ability to read messages on the server means there's several crucial features we can't offer (search, IMAP, etc). It's not worth the tradeoff. As I've said elsewhere, we're a privacy-conscious service, but not we're not chasing privacy-at-all-costs. If that's what you want then FastMail is probably not for you.

7 Dec 2015, 09:23 AM	#9
BritTim The "e" in e-mail Join Date: May 2003 Location: mostly in Thailand Posts: 3,095	Rob ... I do not think you should rule out allowing users easily to send selected emails encrypted and/or signed. I do not suggest any support for encryption of metadata. I appreciate, for webmail, some kind of browser extension or helper application is needed to make it work properly, but this is not an absolute deal breaker IMHO, especially as you may be able to use existing solutions more or less unchanged. I suggest the encrypted/signed message be transmitted as an attachment. I know such messages will not participate in search, but that is a tradeoff users will need to take into consideration. Of course, encrypted messages can already be sent via Fastmail. It is inconvenient to do so. The objective should be to make existing capabilities seemless and easy for users to set up and use. Fastmail would not need to write much new code. Demand for this is growing, and I do believe Fastmail risks losing customers with an occasional need for secure and/or signed message transmission, just on the basis that they lack this feature.

7 Dec 2015, 10:44 AM	#10
robn Master of the @ Join Date: May 2012 Location: Melbourne, Australia Posts: 1,007 Representative of: Fastmail.fm	The only way to make encryption work technically is via some non-browser application. _Anything_ in the browser, including extensions, is fundamentally insecure because you don't know when the server that provides that code gives you a compromised update. As soon as we're working with non-browser applications, then we've got a very difficult development and support prospect. This is full-blown application development, not a "small amount of code", and we've got to do it for multiple platforms and provide a means of getting that code to you that can't be compromised (which rules out mobile app stores). And we're of course assuming that automatic OS upgrades aren't compromised as well. And once installed, there's no way to make this as seamless as you believe. The user is now burdened with keeping a private key secure but still being able to synchronise that information between devices. And we still have to deal with key distribution, which leads us into a more fundamental discussion about what identity actually is. This is the extreme paranoid description, but these are actually all the factors involved in making this properly secure. If this is too much, then we need to start seriously talking about threat models. What kinds of attack are we trying to defend against here, and why? And that's a question that I have never seen answered to my satisfaction by anyone talking about "secure email". And there's still the simple fact that we could do all this fancy stuff and it still wouldn't be any less difficult to get up and running than a regular email client with PGP installed. We've selected a set of security features that we know we can support alongside the kind of mail service and feature set we want to provide. And that's why I say that if you care more about security features we don't have over other features we do have, maybe FastMail isn't for you. If we lose customers as a result of that position, so be it.

7 Dec 2015, 12:03 PM	#11
David Ultimate Contributor Join Date: Dec 2001 Location: Canada. Posts: 10,355	Speaking essentially as a non-techi, with only a limited amount of knowledge (of email conventions) I will say that if I ever really needed to send encrypted email, in a situation where privacy was essential, I would do it client side (likely using GnuPG) I would also ensure that the receiver of the message had enough knowledge (and information) to be able to decrypt it. These are just my thoughts. David

7 Dec 2015, 12:32 PM	#12
BritTim The "e" in e-mail Join Date: May 2003 Location: mostly in Thailand Posts: 3,095	It is clear if we want something, it will need to be a third party effort. As Rob says, the primary concern with a browser extension is auto updating, but there are ways to disable that. I am considering a kickstarter project to develop a Fastmail encrypt message extension. It would prompt the user through initial PGP setup, key generation and key upload to key server. It would then provide hooks for encrypting, decrypting, signing and signature checking of message attachments. Anyone interested in collaborating to get this off the ground?

7 Dec 2015, 03:07 PM	#14
jl66 Essential Contributor Join Date: Oct 2013 Posts: 413	As Rob said before in this forum and now again: Fastmail is not for those looking for privacy or encryption. That's why I am one of those who deleted my account in FM.