How Crymap Encryption Works

Crymap uses a number of modern, well-understood cryptographic primitives to securely store email data.

Encrypting Message Data

Messages must be stored in a way that ensures two properties:

Only the owner can read mail.
Anyone with file system access (e.g., the mail daemon) can add mail to the user’s mailbox.

This is a natural fit for asymmetric encryption. Currently, Crymap exclusively uses 4096-bit RSA for this purpose.

Each account has, at any given time, a single active public key. When mail is received, an encryption key (the “session key”) for the message is randomly generated, and the message data is stored encrypted with that session key. The session key itself is first encrypted with the active public key. This lets the user (who has access to the corresponding private key) decrypt the session key and then decrypt the message content.

The message content itself is encrypted with 128-bit AES-GCM. Besides making it impossible for others to read the message, it also ensures that if the data is corrupted, Crymap will signal an error instead of returning the corrupt data.

A Crymap account typically has more than one RSA private key, though only one at a time corresponds to the active public key. By default, keys are rotated once per month. (The old keys are retained though, so old messages are still readable.) By default, there is also a distinction between “internal” keys, which never have their public key exposed and are used for all encryptions done by the user while logged in, and “external” keys, whose public keys are made available as the primary public key as each key is introduced.

RSA private keys are stored in standard PEM format with a passphrase. The passphrase is not the user’s passphrase, but one autogenerated from the user’s login data (see next section).

User Credentials

Handling of each user’s passphrase is performed with a combination of two cryptographic primitives:

The Argon2 password hashing function, which makes password brute-force attacks extremely costly.
The KMAC function (essentially an HMAC based on Keccak, i.e., SHA-3), which is used to generate secondary keys from an input secret.

The user configuration stores three pieces of information about the user’s credentials:

A password salt
A password hash
The “master key XOR”

When the user inputs their password, it is first hashed using Argon2 with the given salt, giving what we’ll call the “argon hash”. A KMAC value is generated from the argon hash. If that KMAC is not equal to the user’s password hash, we know the password is wrong and can reject the log in. Otherwise, we know the password is right, and take a different KMAC value from the argon hash to produce an “intermediate hash”. Finally, every byte of the intermediate hash is XORed with the corresponding byte of the master key XOR to output the master key.

The “master key XOR” is functionally a one-time pad between the intermediate hash and the master key. Its significance is that it makes it possible for the user to change their password: there is no way to control what the intermediate hash of the new password will be, but whatever it is, a master key XOR can be chosen which still outputs the same master key for the new password as the previous set of parameters did for the old password.

The master key is the primary credential used for all further key derivation in Crymap. Currently, the only derived keys are the PEM passphrases for the RSA private keys, which are each generated from different KMACs of the master key.

Protection Crymap Provides

There are a number of different approaches one can take with encrypting mail. None is a perfect solution, and Crymap fills what is currently a unique niche.

Protection from...	Disk	End-to-end	PGPipe	Crymap
Theft of storage medium	Yes	Partial	Partial	Yes
File exfiltration	No	Partial	Partial	Yes
Metadata exposure	No	No	No	Partial
Eavesdropping in-transit	No	Partial	No	No
Connection compromise	No	Partial	Partial	No

Disk encryption

Disk encryption is a simple, effective way of protecting data in case someone walks away with the physical storage medium. It does not protect against attackers gaining shell access to the server or any form of file exfiltration since all the encrypted files are available in cleartext to anyone who can access that part of the file system. Disk encryption also poses challenges with respect to booting the server up without human intervention.

Protects from theft of storage medium.
No protection from file exfiltration.
No protection of message metadata.
No protection from eavesdropping on message in-transit.
No protection from IMAP connection compromise.

End-to-End Encryption

PGP and S/MIME provide ways for a sender to encrypt a message so that only the receiver can read it. Unlike the other solutions in this list, the message is also secure in-transit. The only way to compromise email content is to compromise the end email client itself. Unfortunately, not many people send encrypted messages this way. End-to-end encryption also typically reduces the quality of the mail experience. There is no protection of message metadata which is outside the message itself. Finally, PGP fails to encrypt any of the message headers.

Protects from theft of storage medium, except for parts of the message that can’t be encrypted.
Protects from file exfiltration, except for parts of the message that can’t be encrypted.
No protection of message metadata.
Protects from eavesdropping on message in-transit, except for parts of the message that can’t be encrypted.
Protects from IMAP connection compromise, except for parts of the message that can’t be encrypted.

Better-late-than-never encryption

This means using a solution like PGPipe to apply PGP encryption to unencrypted messages right before delivered. This protects the message after it has been delivered, but comes with the other downsides of PGP.

Protects from theft of storage medium, except for parts of the message that can’t be encrypted.
Protects from file exfiltration, except for parts of the message that can’t be encrypted.
No protection of message metadata.
No protection from eavesdropping on message in-transit.
Protects from IMAP connection compromise, except for parts of the message that can’t be encrypted.

Crymap

Since Crymap encrypts all message data at rest and has per-user isolation, it provides full defence against theft of storage medium and file exfiltration. It is also able to protect most message metadata, such as message flags. An attacker with file system access can still use that access to form educated guesses about when certain messages were delivered, whether they have been read, and their approximate size. Also note that the user folder structure is fully exposed. On the other hand, since Crymap transparently decrypts data before sending it over IMAP, compromising an IMAP connection reveals all data going over the wire.

Protects from theft of storage medium.
Protects from file exfiltration.
Partial protection of message metadata.
No protection from eavesdropping on message in-transit.
No protection from IMAP connection compromise.