47 lines
3.4 KiB
Markdown
47 lines
3.4 KiB
Markdown
+++
|
|
title = "Per-user encryption"
|
|
weight = 10
|
|
+++
|
|
|
|
|
|
Aerogramme can't store plaintext data, instead all users data must be encrypted with a per-user key on the storage target.
|
|
Of course, cryptography is always a tradeoff with other properties (usability, compatibility, features, etc.),
|
|
so the way the key is derived and where the encryption/decryption can take place can be configured.
|
|
|
|
## Compared to PGP
|
|
|
|
PGP only encrypts the body of the email, it keeps in cleartext the metadata of your email (fields like From:, To:, or Subject: are readable by an attacker),
|
|
it can't protect your flags, your mailbox names, etc. Conversely, all this data is encrypted in Aerogramme.
|
|
|
|
## Security flavors
|
|
|
|
These different configurations are identified as flavors:
|
|
|
|
**Transparent Flavor** - Users' data are decrypted in the server's RAM. The key is derived from the user's password upon IMAP login.
|
|
It's completely transparent to end users. While an attacker having full access to the server can still compromise users' data, it reduces the attack surface.
|
|
In term of security, it's similar to [TREES](https://0xacab.org/liberate/trees) (from [RiseUp](https://riseup.net)) or [scrambler](https://github.com/posteo/scrambler-plugin) (from [Posteo](https://posteo.de/)).
|
|
|
|
|
|
**Hardened Flavor** - Users' data are decrypted on the user's device. The private key is only stored on the user's device.
|
|
The server knows only users' public keys. When an email is received by the server, it is directly encrypted and stored by the server.
|
|
The user must run Aerogramme locally as a proxy that will manipulate the encrypted blobs stored in the server
|
|
and decrypt them locally, exposing an IMAP proxy interface. An attacker having full access to the server at a point in time
|
|
will not be able to compromise your already received data (but can intercept new emails). It's similar to [Proton Mail Bridge](https://proton.me/fr/mail/bridge),
|
|
but keep in mind that Aerogramme does not support (yet) end-to-end email encryption like Proton Mail or Tutanota, *so Aerogramme is less secure*.
|
|
|
|
<!--When run on server (both for the transparent and hardened flavor), Aerogramme must be started in the "provider mode", as in "email service provider".
|
|
When run on the end-user device (only the hardened flavor require that), Aerogramme must be started in the "companion mode", as in "a companion process of your email client".
|
|
These 2 words are materialized as 2 subcommands on the Aerogramme binary: `aerogramme provider` and `aerogramme companion`.-->
|
|
|
|
## Aerogramme roles
|
|
|
|
The transparent flavor only requires Aerogramme to be run on the service provider server, while the hardened flavor require the end-user to run a local proxy.
|
|
More specifically:
|
|
|
|
**Provider** - Provider must be run by the service provider, it is used for both flavors. For the transparent flavor, it both receives emails through LMTP and expose
|
|
the mailbox through IMAP. For the hardened mode, it only receives emails through LMTP, encrypt them with user's public key, but can't expose them through IMAP as the server
|
|
can't decrypt them. Provider commands are available through the `aerogramme provider` subcommand.
|
|
|
|
**Companion** - Companion must be run by the end user, it is used only for the hardened flavor. It fetches encrypted blobs from the server
|
|
of the email provider, decrypt them locally, and expose the mailbox across the IMAP interface, acting as a local proxy.
|
|
Companion commands are avaialble through the `aerogramme companion` subcommand.
|