Mailfence end-to-end encryption and digital signatures

End-to-End Encryption (E2EE)
Is a method used for securing encrypted data while it’s moving from a source to a destination. With End-to-End Encryption, data is encrypted on the sender’s system and only the intended recipient will be able to decrypt it. Nobody in between (be they an internet/application service provider, surveillance programs or a hacker, …) can read or tamper with it – thus providing a great deal of confidentiality and protection to all communications.

Digital Signature
Is an equivalent of a handwritten signature or stamped seal, but offering far more inherent security. A digital signature is intended to solve the problem of tampering and impersonation in digital communications – and provides absolute authenticity and integrity to all messages.

How do we do it

Mailfence secure and private email-suite encapsulates OpenPGP, a time-honored protocol designed by Phillip Zimmermann, which got further refined in RFC-4880 along with S/MIME protocol.

We leverage the OpenPGP.js – a Javascript implementation of OpenPGP standard which is open-source and well-audited. It allows us to perform all the complex crypto-operations of en(de)cryption purely on the client side, without exhausting the device’s resources.

Glance of operations in step-wise manner
Every crypto process encapsulates a series of different steps working back and forth between the client and the server over TLS/SSL – in order to successfully carry out a particular operation. Below you will find a step-by-step linear diagram that illustrates how Mailfence End-to-end encryption and digital signatures functions along with other relevant details.

Mailfence to Mailfence

mailfence-to-mailfence

Mailfence to other email providers
  • Key generation
    1. The client-browser requests the specific key-generation code from the server after receiving a request from the user – and the server sends that specific code to the client’s browser.
    2. The key then gets generated on the user device (in browser) and gets encrypted with the provided passphrase via AES-256. The public key at this point also gets published on public key servers (if the user has opted for that option as well).
    3. The encrypted key is then pushed onto the server from user’s browser – so that a user can access it any time from any device in a secure and protected manner.

* For private key import (encrypted already with the user passphrase) – steps 1-3 will be skipped.

  • Passphrase changing
    1. The client-browser requests the specific passphrase changing code along with the related encrypted key from the server after receiving a request from the user – and the server sends that specific code with the related encrypted key to the client’s browser.
    2. User decrypts the key by providing the respective passphrase and encrypts it with the new one.
    3. The encrypted key is then pushed back to the server from the user’s browser.
  • Key revocation
  1. The client-browser requests the specific key revocation code along with the related encrypted key from the server after receiving a request from the user. The server sends that specific code with the related encrypted key to the client’s browser.
  2. User decrypts the key by providing the respective passphrase.
  3. The key then gets revoked and its revocation status also gets published on public key servers (if user has opted for this option). The key then gets encrypted back with user passphrase.
  4. Client browser then pushes the encrypted key back to the server.

* For generating revocation certificate – In step 4, instead of revoking the key, the application will generate a revocation certificate – which user can use at any later stage to claim the key revocation.

  • Key Export
    1. The client-browser requests the specific key exporting code with the related key from the server after receiving a request from the user and the server sends that specific code with the related encrypted key to the client’s browser.
    2. The user then exports (downloads) that encrypted key onto his device.
  • Key Deletion
    1. The client-browser requests the specific key deletion code with the related key from the server after receiving a request from the user and the server sends that specific code with the related encrypted key to the client’s browser.
    2. The user then deletes the encrypted key onto his device.
  • Key expiration date modification
    1. The client-browser requests the specific expiration date modification code with the related key from the server after receiving a request from the user – and the server sends that specific code with the related encrypted key to the client’s browser.
    2. User decrypts the key by providing the respective passphrase and modifies the expiration date. The key then gets encrypted back with user passphrase.
    3. Client browser then pushes the encrypted key back to the server.
  • Sending a digitally signed email
    1. The client-browser requests the specific digital signing code with the related key from the server after receiving a request from the user – and the server sends that specific code with the related encrypted key to the client’s browser.
    2. User decrypts the key by providing the respective passphrase.
    3. The composed email message gets digitally signed (PGP/MIME) and then sent to the recipient.
    4. The key then gets encrypted back with user passphrase and pushed back to the server.
  • Sending an encrypted and digitally signed email
    1. The client-browser requests the specific encryption and digital signing code with the related key from the server after receiving a request from the user – and the server sends that specific code with the related encrypted key to the client’s browser.
    2. User decrypts the key by providing the respective passphrase.
    3. The composed email message gets digitally signed (PGP/MIME), encrypted with the public key of the recipient (OpenPGP) and then gets sent.
    4. The key then gets encrypted back with user passphrase and pushed back to the server.

For a detailed “How to” user manual, please check this link as well.

Get your secure email!

Follow us on twitter/reddit and keep yourself posted at all times.

– Mailfence Team


Spread the word !

M Salman Nadeem

Information Security Analyst
– Security Team | Mailfence

You may also like...

9 Responses

  1. July 27, 2016

    […] Mailfence end-to-end encryption and digital signatures July 25, 2016 […]

  2. August 3, 2016

    […] Mailfence end-to-end encryption and digital signatures July 25, 2016 […]

  3. November 21, 2016

    […] notre avis, le chiffrement de bout en bout joue un rôle crucial dans la mise sur pied de messageries sécurisées. Il […]

  4. December 5, 2016

    […] communications, Email is the first thing that comes into mind – and Mailfence offers true end-to-end encryption and digital signatures based on OpenPGP standard without any modifications, thereby allowing users to have the features of PGP […]

  5. December 13, 2016

    […] Use a 4096 bit (or at least a 2048 bit) length-based private key to sign a digital message. Mailfence always generates a 4096bit RSA key by default. […]

  6. August 2, 2017

    […] anonymity. What technologies we employ to guarantee privacy and security?  Why we decided to use OpenPGP?  How we made it easy-to-use for our users?  What sets us apart from other secure mail […]

  7. August 26, 2017

    […] outre, ‘How do we do it’ (un aperçu détaillé) est également là  (en anglais) pour améliorer votre compréhension de […]

  8. August 29, 2017

    […] Mailfence end-to-end encryption and digital signatures […]

  9. August 29, 2017

    […] Mailfence end-to-end encryption and digital signatures […]

Leave a Reply

Your email address will not be published. Required fields are marked *