2.2 KiB
+++ 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.
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 (from RiseUp) or scrambler (from Posteo).
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, 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.