Under the hood

The following picture shows the EasyCrypt network system. EasyCrypt clients connect both to the Tor network and to clearnet. EasyCrypt servers are implemented as hidden services on the Tor network. Communication between EasyCrypt subscribers takes place over Tor in tandem with clearnet.

 

 

Encryption of outgoing message contents
EasyCrypt clients generate keys locally and encrypt outgoing messages using OpenPGP and PGP/MIME, with the 4096 bit RSA algorithm. The messages can be decrypted only on the devices of their intended recipients.

Key management
The user’s private key is encrypted on the user’s device by a passphrase known only to the user, and stored on EasyCrypt servers. It can be decrypted only on the user’s device. This allows support of automatic key restoration in case client storage is accidentally erased or when there is a need to reinstall the client. This also allows automatic, user-transparent synchronization of keys when the user installs EasyCrypt clients on additional devices.

Public keys of EasyCrypt subscribers and their external PGP recipients are stored locally on the clients, as well as on EasyCrypt servers. This provides support for robust, independent operation of the clients even if the server is temporarily inaccessible. External PGP users register their public keys with EasyCrypt by emailing them to registerpublickey@easycrypt.co. This is followed by automated cryptographic verification of the pairing between the key and the email address, following which messages exchanged between EasyCrypt subscribers and the external PGP users are automatically encrypted.

Metadata protection and anonymization
To perform metadata protection and anonymization, EasyCrypt uses an innovative combination of metadata encryption at the endpoints, suppression of unnecessary metadata, generation of innocuous metadata for transmission over clearnet, anonymizing functionality of EasyCrypt servers and the anonymizing nature of the Tor network.

Message subject and sender’s email address (or sender’s email pseudonym) are encrypted by the sending client to the public key of the recipient using OpenPGP with 4096 bit RSA, and appended to the outgoing message. Either the recipient’s email address or a SHA-256 hash of the recipient’s email pseudonym is also appended to the message. The message is then sent by the client to EasyCrypt servers over the Tor network, along with an anonymous cryptographic proof that the sending client belongs to an EasyCrypt subscriber. The identity and email address of the sending subscriber are not known to EasyCrypt servers.

EasyCrypt servers contain a lookup table of the subscribers’ email addresses and the hashes of their pseudonyms. When a hashed pseudonym rather than the recipient’s email address is appended to a message, the server replaces the pseudonym with the looked-up email address of the recipient.

No unencrypted or non-hashed metadata, including metadata that identifies the sender, ever leaves the client. The sender’s IP address remains unknown to EasyCrypt servers that operate and communicate with the clients as hidden services on the Tor network. The only piece of message data or personally identifiable metadata known to EasyCrypt servers is the recipient’s email address.

Message transport to the recipient
The messages are forwarded by EasyCrypt servers over Tor to an SMTP proxy that operates as Tor hidden service and is also connected to clearnet. The SMTP proxy fills all the SMTP header fields except the recipient’s email address with innocuous metadata and forwards the message to the recipient over clearnet using SMTP.

The following diagram shows network paths taken by messages exchanged among EasyCrypt subscribers and between EasyCrypt subscribers and external PGP users. When subscriber Alice sends a message to subscriber Bob, her message first travels to EasyCrypt servers where it is processed as described above. It is then forwarded to Bob over clearnet/SMTP and lands in Bob’s Gmail inbox. When Alice communicates with an external PGP user Pete, the message may be transmitted either as shown in the picture (standard PGP over clearnet) or, if Alice chooses to be anonymous, the message will be sent to Pete via EasyCrypt servers and will take a path similar to that taken by her message to Bob.

 

 

Message decryption by the recipient
The receiving  client decrypts the message with the recipient’s private key and thus gains access to the sender’s address (or pseudonym), message subject, body and attachments.

Communication with external PGP users
When communicating with external PGP users, EasyCrypt subscribers can anonymize themselves as described above, but full metadata protection is not possible. For example, message subject cannot be encrypted in such case as this is not supported by the OpenPGP standard. Message body and attachments are encrypted as usual in PGP-based communication.

Secure Webmail, onion address
EasyCrypt Secure Webmail is a browser-based encrypting email client. No installation is required and the major browsers, including Tor browser, are supported. End-to-end encryption and decryption are performed in the browser. The connection between the browser and EasyCrypt servers is secured by TLS with Perfect Forward Secrecy, using a certificate from a reputable Swiss Certification Authority. For extra security and anonymity, users may use Tor browser to access EasyCrypt Webmail either at https://webmail.easycrypt.co or at the onion address webmail.ezcrypt2dgcicxqj.onion.

Single-password login with dual-layer authentication
To log in, users type their email address and EasyCrypt password. The password is known only to the user and has no length limit. The password is hashed on the client with a user-specific salt and sent over TLS to EasyCrypt webmail server. At the server it is hashed again using bcrypt with a user-specific salt and compared to a stored hash value. If the comparison is successful, the server sends to the client the user’s private key encrypted by the user’s password, as well as a randomly generated nonce encrypted to the user’s public key. The client decrypts the private key with the password, and sends the decrypted nonce back to the server. If the received nonce matches the original, the server allows the client to access EasyCrypt Webmail.

Protection of email credentials in EasyCrypt webmail service
In order to access their email account via EasyCrypt webmail, at sign-up users either provide their email password or authorize the generation of an OAuth token for EasyCrypt (the latter is currently supported for Gmail and Hotmail/Outlook.com). To protect such email credentials from access by 3rd parties, hackers or even EasyCrypt personnel, EasyCrypt uses the following method.

At sign-up the EasyCrypt server encrypts the email credentials using the user’s public key, stores the result on the server and erases the cleartext copy of the credentials. When the user logs into EasyCrypt webmail, the server generates a random number (nonce), encrypts it with the user’s public key and sends it along with the stored email credentials (also encrypted by the public key) to the client. The client decrypts the credentials, re-encrypts them using AES-256 keyed by the nonce, and sends them back to the server. The server decrypts the credentials with the nonce, creates a randomly generated session key and stores a local copy of the credentials encrypted by the session key. The server then creates a JWT-encrypted session cookie that contains the session key, sends the cookie to the client and erases the local copy of the cookie and the cleartext copies of the credentials and the session key.

Thereafter, every time the client posts a request that requires access to the user’s email account, the client provides the session cookie to the server which extracts the session key from the cookie, uses it to decrypt the credentials, makes a one-time use of the credentials and then erases the session key, the credentials and the cookie. This ensures that after the session is terminated or aborted, the server can no longer access the user’s email account. All session data are stored in volatile RAM only.

 

Send this to a friend