love the direction have asked myself manytimes why this feature sent doesn't exist somewhere; for sure would need to see some high profile people start using this to think its bullet proof
I'm not sure this really hits E2EE. E2EE is a claim about who cannot read your mail, so the test is whether confidentiality survives a hostile operator. This model fails that test twice, and the choice of PGP decides how bad the second failure gets.
Take an operator that ships bad code first. The crypto runs in JavaScript that AurionMail serves on every page load, and nothing pins that bundle: no reproducible build, no signature the browser enforces, no way for a user to verify what ran. One build that posts the master passphrase to a host they control ends it. Password strength, the 5-minute TTL, and the non-extractable CryptoKey all stop mattering. Every guarantee in the document becomes a promise about operator behaviour, and E2EE exists to remove those promises. Signed reproducible clients fix this, or published bundle hashes in a transparency log. Their security model never mentions its own delivery channel.
Ignoring that/assuming an honest build pipeline--what does a breach, an insider, or a subpoena yields later. The server holds the wrapped OpenPGP private key, the 16-byte master salt (cross-device unlock needs it), and Argon2id(password, "auth_salt_${username}") from every login. That last value verifies the same password protecting the vault, so you can grind offline at Argon2id cost, derive the master key, unwrap the PGP key, and read the mail. auth_salt_${username} is public and known before any breach, so an attacker can precompute against a named target. A random per-user salt served at login removes that discount. Proton and Bitwarden share the general ceiling, so what follows is what makes this design worse.
In addition, PGP has no forward secrecy. Combine that with a server-side mail archive and a server-side copy of the long-term private key. One password recovery at any future point then decrypts the entire history in one pass. A long-term key is only as strong as the weakest security practice across its whole lifetime, and an attacker who eventually wins reads the full back catalogue. Remote backups of the long-term key are a pattern to avoid here, but AurionMail ships that backup as a sync feature. The document reasons carefully about a 5-minute TTL on a transport blob while the real exposure window is the account's entire lifetime, applied backwards.
Rotation makes it stickier. The same post argues that people keep keys they suspect are compromised because rotating costs too much. Here the master password derives both the PGP wrapping key and the CryptPad seed, so a password change orphans CryptPad documents, and replacing the PGP key means re-establishing it with every correspondent. Two coupled rotation costs, and the document specifies neither procedure.
Coverage is the other limit. PGP over SMTP leaves envelope recipients and timestamps in clear, and it only protects mail where the other party also runs PGP. Most folks see very few encrypted emails a year, and correspondents generally resend in plaintext given any excuse. The other end decides your coverage. The security model also never says how a user authenticates a correspondent's public key, and encrypting to an attacker's key defeats everything upstream of it. Web of trust does not close that gap in practice.
Two parts of the design are correct. The cross-origin handoff keeps the seed off the network, so the server holds ciphertext it cannot open, and burn-on-read with a short TTL layers sensibly on top. One Argon2id pass feeding domain-separated HKDF labels is standard, and separate salts for auth and for the master key keep the login hash from being the vault key.
From my POV, this is client-side encryption with a trusted operator, built on a key model that competent advocates were publicly abandoning ten years ago. That property is real and it beats server-side encryption, and it requires trusting their build pipeline, their hosting, and their users' passwords. "Zero-knowledge" claims none of that trust is needed, but their security model doesn't support this claim.
Thanks a lot for taking the time to read the security model so thoroughly and for providing such a detailed critique. I didn't think someone would do it ! This is extremely valuable feedback.
A few thoughts on your specific points:
- You are right about the web threat model. Serving the crypto bundle over the web means trusting the server not to serve malicious JS at load time. Moving towards reproducible builds, bundle hashing, or a dedicated browser extension is definitely the long-term path to remove operator trust on code delivery.
- For the `auth_salt_${username}` salt, this is a choice I made at the beginning of the project, an error, and it should be replaced soon. However, this is only used for authentication and not encryption.
- Changing the master password does not orphan CryptPad documents. The master password is solely used client-side to derive the wrapping key that encrypts the underlying persistent secrets (the PGP private key and the CryptPad account pass).
When changing the password:
1. The persistent secrets are unwrapped in RAM using the old derived key.
2. They are re-wrapped using the new key derived from the new master password.
3. CryptPad's native account key update process is triggered with old and new secret.
Framing AurionMail as "client-side encryption with a trusted operator" rather than absolute ZK is a fair and accurate classification of the current web-based threat model. I'll update the documentation and security spec to clarify these trust assumptions explicitly.
love the direction have asked myself manytimes why this feature sent doesn't exist somewhere; for sure would need to see some high profile people start using this to think its bullet proof
I'm not sure this really hits E2EE. E2EE is a claim about who cannot read your mail, so the test is whether confidentiality survives a hostile operator. This model fails that test twice, and the choice of PGP decides how bad the second failure gets.
Take an operator that ships bad code first. The crypto runs in JavaScript that AurionMail serves on every page load, and nothing pins that bundle: no reproducible build, no signature the browser enforces, no way for a user to verify what ran. One build that posts the master passphrase to a host they control ends it. Password strength, the 5-minute TTL, and the non-extractable CryptoKey all stop mattering. Every guarantee in the document becomes a promise about operator behaviour, and E2EE exists to remove those promises. Signed reproducible clients fix this, or published bundle hashes in a transparency log. Their security model never mentions its own delivery channel.
Ignoring that/assuming an honest build pipeline--what does a breach, an insider, or a subpoena yields later. The server holds the wrapped OpenPGP private key, the 16-byte master salt (cross-device unlock needs it), and Argon2id(password, "auth_salt_${username}") from every login. That last value verifies the same password protecting the vault, so you can grind offline at Argon2id cost, derive the master key, unwrap the PGP key, and read the mail. auth_salt_${username} is public and known before any breach, so an attacker can precompute against a named target. A random per-user salt served at login removes that discount. Proton and Bitwarden share the general ceiling, so what follows is what makes this design worse.
In addition, PGP has no forward secrecy. Combine that with a server-side mail archive and a server-side copy of the long-term private key. One password recovery at any future point then decrypts the entire history in one pass. A long-term key is only as strong as the weakest security practice across its whole lifetime, and an attacker who eventually wins reads the full back catalogue. Remote backups of the long-term key are a pattern to avoid here, but AurionMail ships that backup as a sync feature. The document reasons carefully about a 5-minute TTL on a transport blob while the real exposure window is the account's entire lifetime, applied backwards.
Rotation makes it stickier. The same post argues that people keep keys they suspect are compromised because rotating costs too much. Here the master password derives both the PGP wrapping key and the CryptPad seed, so a password change orphans CryptPad documents, and replacing the PGP key means re-establishing it with every correspondent. Two coupled rotation costs, and the document specifies neither procedure.
Coverage is the other limit. PGP over SMTP leaves envelope recipients and timestamps in clear, and it only protects mail where the other party also runs PGP. Most folks see very few encrypted emails a year, and correspondents generally resend in plaintext given any excuse. The other end decides your coverage. The security model also never says how a user authenticates a correspondent's public key, and encrypting to an attacker's key defeats everything upstream of it. Web of trust does not close that gap in practice.
Two parts of the design are correct. The cross-origin handoff keeps the seed off the network, so the server holds ciphertext it cannot open, and burn-on-read with a short TTL layers sensibly on top. One Argon2id pass feeding domain-separated HKDF labels is standard, and separate salts for auth and for the master key keep the login hash from being the vault key.
From my POV, this is client-side encryption with a trusted operator, built on a key model that competent advocates were publicly abandoning ten years ago. That property is real and it beats server-side encryption, and it requires trusting their build pipeline, their hosting, and their users' passwords. "Zero-knowledge" claims none of that trust is needed, but their security model doesn't support this claim.
Thanks a lot for taking the time to read the security model so thoroughly and for providing such a detailed critique. I didn't think someone would do it ! This is extremely valuable feedback.
A few thoughts on your specific points:
- You are right about the web threat model. Serving the crypto bundle over the web means trusting the server not to serve malicious JS at load time. Moving towards reproducible builds, bundle hashing, or a dedicated browser extension is definitely the long-term path to remove operator trust on code delivery.
- For the `auth_salt_${username}` salt, this is a choice I made at the beginning of the project, an error, and it should be replaced soon. However, this is only used for authentication and not encryption.
- Changing the master password does not orphan CryptPad documents. The master password is solely used client-side to derive the wrapping key that encrypts the underlying persistent secrets (the PGP private key and the CryptPad account pass).
When changing the password: 1. The persistent secrets are unwrapped in RAM using the old derived key. 2. They are re-wrapped using the new key derived from the new master password. 3. CryptPad's native account key update process is triggered with old and new secret.
Framing AurionMail as "client-side encryption with a trusted operator" rather than absolute ZK is a fair and accurate classification of the current web-based threat model. I'll update the documentation and security spec to clarify these trust assumptions explicitly.
Thanks again for your feedback !