At rest encryption (with protected crypto keys)

[Joseph Tam]

On Tue, 24 Mar 2020, Kees de Jong wrote:

> As stated on the Dovecot documentation, at rest encryption is possible
> [1]. However, these keys are present on the system itself and are
> unprotected. Therefore, if a system is compromised, the attacker has
> access to the encrypted mail and the keys. There is no security benefit
> in that situation, except for hoping that the attacker doesn't
> understand that this is happening and how.
>
> Nextcloud does this a bit better. A key is used to encrypt user data as
> well [2]. However, that key is protected with the user's password. When
> the user logs in and requests data, the user's password unlocks the key
> and data can be read and written safely. This also takes into account
> password changes. Files don't need to be encrypted again, the
> encryption key is simply re-encrypted with the new user's password.
>
> How does the Dovecot community see this?

The answer depends on how much security you want, and what you assume
an eavesdropper has access to.

The protection described in the second paragraph is merely an extension
of the first, where secrecy is implemented on the server side.  If the
system is compromised, it only takes several strategic placement of
code to intercept the secret parts and unravel the entire workings.
It may require expertise, but in theory, it's falls prey to the dishonest
administrator or skilled attacker.

A stronger form is client-side encryption: the key and encryption is done
on the client side, then only the encrypted data is transferred to the server.
The Nextcloud (or Dropbop) example is to have a encrypted FS on
the client side (e.g. VeraCrypt) and the whole container is sync'd
on the storage side (the server).  At no point does the server side ever
get to see keys.

Joseph Tam <jtam.home at gmail.com>