EmailDiscussions.com - View Single Post

kangas · 8 Oct 2016, 02:33 AM

Hello,

Perhaps our blog page needs to be updated as it appears to be confusing. What it essentially says is that (for email):

1. We use full disk encryption for all data for all (shared and dedicated) enterprise-class customers and for dedicated business-class customers who request it.

2. We have options on top of full disk encryption for storing messages individually using encryption (i.e. PGP, S/MIME, and "stored encrypted in a database waiting to be picked up by a recipient"). The latter actually double-encrypts the data.

Regarding Fastmail, do you have a link for your reference to their email encryption? I would like to see what they are doing currently. In my search, I cam up with their page that describes how they provide security for email across many different aspects of their service:

https://www.fastmail.com/help/ourservice/security.html

I would expect to see some mention of at-rest encryption there ... but do not. Perhaps this is described elsewhere and this page is out dated? So -- digging further, I found the fastmail documentation related to their encryption:

https://blog.fastmail.com/2014/12/07...-installation/

It seems that they do exactly what we do -- full disk encryption using built-in support or using LUKS when built-in support is not available. This protects the data on disks from discovery when disks are destroyed/discarded or accessed from external systems. It does not protect email at rest from attackers who have broken into a running server (we discuss this in our blog article). This is why additional levels of encryption are often desired on top of disk encryption. This is also why disk encryption in a data center environment hat has solid processes for media disposal is of marginal utility compared to object-level encryption that protected that data from attackers that have broken into a running server.

Doing that well has tradeoffs and that is why there are many different flavors of email encryption out there. As you take more and more protections, you often lose things such as speed, searchability, sharability, etc. Ultimately, companies need to decide for themselves where they fall on the spectrum of need for security and need for usability and other features. In our experience, most companies want good security and security practices but not "the be-all end-all" so that they can take advantage of other productivity features that they would lose otherwise.

For this reason, LuxSci presents a variety of options to fit a variety of customer needs (and price sensitivity points).

This update was longer than expected -- sorry -- but I hope it helps.

8 Oct 2016, 02:33 AM	#7
kangas Member Join Date: Feb 2004 Posts: 81 Representative of: LuxSci.com	Hello, Perhaps our blog page needs to be updated as it appears to be confusing. What it essentially says is that (for email): 1. We use full disk encryption for all data for all (shared and dedicated) enterprise-class customers and for dedicated business-class customers who request it. 2. We have options on top of full disk encryption for storing messages individually using encryption (i.e. PGP, S/MIME, and "stored encrypted in a database waiting to be picked up by a recipient"). The latter actually double-encrypts the data. Regarding Fastmail, do you have a link for your reference to their email encryption? I would like to see what they are doing currently. In my search, I cam up with their page that describes how they provide security for email across many different aspects of their service: https://www.fastmail.com/help/ourservice/security.html I would expect to see some mention of at-rest encryption there ... but do not. Perhaps this is described elsewhere and this page is out dated? So -- digging further, I found the fastmail documentation related to their encryption: https://blog.fastmail.com/2014/12/07...-installation/ It seems that they do exactly what we do -- full disk encryption using built-in support or using LUKS when built-in support is not available. This protects the data on disks from discovery when disks are destroyed/discarded or accessed from external systems. It does not protect email at rest from attackers who have broken into a running server (we discuss this in our blog article). This is why additional levels of encryption are often desired on top of disk encryption. This is also why disk encryption in a data center environment hat has solid processes for media disposal is of marginal utility compared to object-level encryption that protected that data from attackers that have broken into a running server. Doing that well has tradeoffs and that is why there are many different flavors of email encryption out there. As you take more and more protections, you often lose things such as speed, searchability, sharability, etc. Ultimately, companies need to decide for themselves where they fall on the spectrum of need for security and need for usability and other features. In our experience, most companies want good security and security practices but not "the be-all end-all" so that they can take advantage of other productivity features that they would lose otherwise. For this reason, LuxSci presents a variety of options to fit a variety of customer needs (and price sensitivity points). This update was longer than expected -- sorry -- but I hope it helps.