ProtonMail’s security model relies on three pillars: end-to-end encryption (RSA-2048 + AES-256) so only you and your recipient can read messages, zero-access architecture so ProtonMail’s own servers never store decryptable content, and client-side key generation so your private key never leaves your device in plaintext. This means ProtonMail cannot read your emails even if compelled by a court order or compromised by an attacker. Here is how each layer works in practice.

End-to-End Encryption Fundamentals

ProtonMail employs end-to-end encryption (E2EE) as its foundational principle. Unlike traditional email services that encrypt messages only during transmission (transport layer security), ProtonMail ensures that only the intended recipient can decrypt and read the message content.

The encryption scheme uses a combination of RSA-2048 and AES-256. When you create a ProtonMail account, the service generates cryptographic key pairs:

// Conceptual key generation (simplified for illustration)
const keyPair = await window.crypto.subtle.generateKey(
  {
    name: "RSA-OAEP",
    modulusLength: 2048,
    publicExponent: new Uint8Array([1, 0, 1]),
    hash: "SHA-256"
  },
  true,
  ["encrypt", "decrypt"]
);

Your public key encrypts outgoing messages, while your private key—which never leaves your device in decrypted form—decrypts incoming messages. This architectural choice means ProtonMail itself cannot access your message content, even if compelled to do so.

Zero-Access Encryption Architecture

The zero-access encryption model represents ProtonMail’s most distinctive security feature. Traditional email providers store messages in plaintext on their servers, creating a tempting target for hackers and legal requests. ProtonMail eliminates this vulnerability entirely.

When you send an email to another ProtonMail user:

  1. Your browser generates a random session key
  2. The message encrypts locally using AES-256
  3. The session key encrypts with the recipient’s public key
  4. Only the recipient’s private key can unlock the session key and decrypt the message

For communication with non-ProtonMail users, ProtonMail offers a convenient bridge: you can send encrypted messages to any email address, with the recipient receiving a link to view the decrypted content after authenticating through a password you specify.

# Conceptual Python implementation of ProtonMail-style E2EE
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend
import os

def encrypt_message(public_key, plaintext):
    # Generate random session key
    session_key = os.urandom(32)  # AES-256
    
    # Encrypt message with session key
    iv = os.urandom(16)
    cipher = Cipher(algorithms.AES(session_key), modes.CBC(iv), default_backend())
    encryptor = cipher.encryptor()
    ciphertext = encryptor.update(plaintext) + encryptor.finalize()
    
    # Encrypt session key with recipient's public key
    encrypted_session_key = public_key.encrypt(
        session_key,
        padding.OAEP(mgf=padding.MGF1(algorithm="SHA256"), algorithm="SHA256", label=None)
    )
    
    return {
        "iv": iv,
        "ciphertext": ciphertext,
        "encrypted_session_key": encrypted_session_key
    }

Authentication and Session Security

ProtonMail implements several layers of authentication protection. The service never stores your password in plaintext—instead, it uses Secure Remote Password (SRP) protocol to verify credentials without transmitting the actual password over the network.

For session management, ProtonMail employs:

The authentication flow involves computing a password verifier that gets stored on servers. When you log in, the client proves knowledge of the password without revealing it:

// SRP authentication conceptual flow
async function authenticate(email, password) {
  const salt = await fetchSalt(email);
  const verifier = computeVerifier(password, salt);
  
  // Client generates ephemeral key pair
  const clientEphemeral = generateEphemeralKeyPair();
  
  // Proof generation happens entirely client-side
  const clientProof = computeClientProof(
    clientEphemeral.public,
    serverPublic,
    salt,
    password
  );
  
  // Server verifies proof without knowing the password
  const serverProof = await verifyWithServer(email, clientProof);
  return verifyServerProof(serverProof);
}

Address Verification and Key Transparency

A often-overlooked aspect of ProtonMail’s security model is its approach to public key verification. The service maintains a Key Transparency system that helps detect man-in-the-middle attacks by publishing signed prekeys to a verifiable log.

When you add a new contact or receive their first email, ProtonMail automatically retrieves and validates their public key from the server. For security-conscious users, manual fingerprint verification remains available:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP.js

mQINBF[...truncated for brevity...]
-----END PGP PUBLIC KEY BLOCK-----

You can verify fingerprints through an independent channel (in-person, Signal, etc.) to ensure you’re not being redirected to an attacker’s key.

Limitations and Threat Model

Understanding what ProtonMail protects against—and what it doesn’t—matters for proper risk assessment:

What ProtonMail protects:

What ProtonMail does NOT protect:

Practical Implications for Developers

If you’re building applications that integrate with ProtonMail or implementing similar encryption systems, consider these architectural takeaways:

  1. Key management is critical — The security of E2EE systems depends entirely on proper key handling. Never store private keys in plaintext.

  2. Client-side encryption is mandatory — Server-side encryption provides transit security but fails the zero-access guarantee. Perform cryptographic operations in the user’s browser or application.

  3. Fail gracefully — Design systems that handle missing keys, expired certificates, or decryption failures without exposing sensitive data.

  4. Consider key rotation — Implement procedures for key revocation and rotation to limit exposure if keys are compromised.

ProtonMail’s security model demonstrates that building privacy into a consumer-friendly email service is achievable. While no system is impenetrable, the zero-access architecture provides meaningful protection against sophisticated adversaries—exactly what developers and power users need when communication confidentiality matters.

Built by theluckystrike — More at zovo.one