Encrypt on Email

You can find the Chiense version of this introduction there and Rust implementation on Github

What is ENE?

ENE is an experimental, designed for mail, end-to-end encryption tool. It basically is what I conceive as OpenPGP 2.0 with several improvements with regard to the weakness of PGP.

Mail is a one-pass, stateless commutation scheme, which means designing encryption scheme for it does not meet many common security requirements such as Perfect Forward Secrecy. In fact, neglecting any one limitation, we can do much more. For example, OpenPGP has Forward Secrecy scheme in stateful situations1.

But under these conditions, what we can do is much less.

In the early days, we are satisfied with simple KEMKey encapsulation mechanisms + Encrypt scheme while those schemes lack authentication and integrity.

However, in 2018, we can do better.

ENE will support:

  • Authenticated Key Exchange
  • Deniable Authentication
  • Mail Integrity
  • Nonce-misuse Resistant AEAD
  • Experimental Post-quantum Cipher suite

We need Authentication?

Considering a scenario, where Alice sends Bob an encrypted message without authentication. Mallory could easily intercept and forward the message to Bob. And Bob will think the message is sent from Mallory.

This is caused by the absence of identity authentication.

Some people might think simply adding a signature solves all the problems. But it does not. The simple signature scheme has two weaknesses,

  1. The loss of Deniability2
    • When you sign the message with your private key, you have certain responsibilities. You cannot deny the message is from you.
  2. Surreptitious Forwarding Attack3,4
    • Mallory can separate the signature of Alice, use his own signature instead.
    • Some people might think Sign-then-Encrypt could solve this problem. But if the encryption scheme does not reach CCA5, then it still cannot prevent such attacks.

ENE has four authentication schemes, a user can choose the security level freely to meet their goals.

  1. One-Pass Authenticated Key Exchange6,7
    • One-pass AKE has good performance because it does not involve complicated signature algorithm.
    • Since the message is only passed once, we cannot reach perfect forward secrecy. But we can Sender Forward Secrecy, this is at least as good as public key encryption.
    • One-pass AKE only provides implicit authentication, which means it cannot resist KCIKey Compromise Impersonation attack8.
    • One-pass AKE is the weakest authentication methods in ENE, but it can still defense most attacks. (You should use it to replace the unauthentication methods in early mail encryption).
  2. Signature-based Authenticated Key Exchange9,10
    • Adding signature to key exchange can make explicit authentication. This improvement can defense KCI attack.
    • The content of signature does not include message, this means it can keep the deniability of the message.
  3. Signature Key Exchange and Message
    • Based on the 2nd method, the content of signature includes plaintext. This will keep the Non-Repudiation of the message.
  4. Signature Only
    • Sign only the plaintext, without any encryption.

We need AEAD?

I don’t think I need to repeat telling the importance of identity authentication in year 8102.

EFAIL is an example of poor integrity verification.

In fact, OpenPGP has its integrity verification scheme MDC11, but in many applications it serves only as warnings, and there is SEIP downgrade attack12. While in ENE, we use a more state-of-the-art method AEAD to keep integrity verified.

The research for AEAD has been conducted for many years13. More security properties have been proposed such as Nonce-misuse Resistant14.

Due to the stateless property of mails, we could only generate nonce randomly. For some encryption algorithms, the effect of nonce reuse is devastating such as AES-GCM 15. Although we may do not have enough amount of emails to start a birthday attack, using an AEAD of Nonce-misuse Resistant can make us immune to this problem.

We need Post-quantum?

A well-known fact is that quantum computer can break all popular public key algorithms. All emails encrypted with RSA/ECC will not be able to keep secrecy. Thus, it is necessary to prevent such scenario before the emergency of practical quantum computers.

There are generally two ways to defend against quantum adversary.

  1. Use Pre-Shared Key
  2. Use Post-quantum key exchange16

Considering the use case for mails, it is not practical to use pre-shared key. Therefore, using Post-quantum algorithm is a better choice.

Is ENE Perfect?


This is always space for improvements:

  • Subkey support
  • Full Forward Secrecy17,18
  • GroupMailing List Encryption Support
  • Denfense against Side-Channel attack
  • Protocol Formal Verification

ENE is a very young tool, all shall change in the future.

Why not use ENE?

ENE is not elixir. It is designed for mail encryption, not full replacement of PGP.

  1. Web of Trust19
    • I am not going to discuss the pros and cons of Web of Trust.
    • ENE is not a trust system, it does not consider how to build trust relations.
    • If needed, you can use PGP to sign ENE public key.
  2. Sign for git commit, packages and other public keys
    • You can use ENE to do it, but it does not have many advantages over PGP.
    • Of course, you can also use pbp.
  3. Encrypt large file
    • The context of mail is normally not too big, ENE thus does not consider this.
    • However, this does not mean GPG is suitable for file encryption. 4. Need reliable, stable encryption methods
    • ENE is not stable! It might change at anytime.
    • The “modern PGP” is still one of the best choices, such as Sequoia.

  1. Forward Secrecy Extensions for OpenPGP
  2. Deniable authentication
  3. Should we sign-then-encrypt, or encrypt-then-sign?
  4. Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML
  5. Chosen-ciphertext attack
  6. One-Pass HMQV and Asymmetric Key-Wrapping
  7. OAKE: a new family of implicitly authenticated diffie-hellman protocols
  8. Key Compromise Impersonation attacks (KCI)
  9. The SIGMA Family of Key-Exchange Protocols
  10. AEAD variant of the SIGMA-I protocol
  11. Modification Detection Code Packet
  12. OpenPGP SEIP downgrade attack
  13. Authenticated encryption
  14. Nonce misuse resistance 101
  15. Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS
  16. Post-quantum cryptography
  17. Forward Secure Asynchronous Messaging from Puncturable Encryption
  18. 0-RTT Key Exchange with Full Forward Secrecy
  19. Web of trust