polo46
Joined 2 months ago
Karma
12
Submissions
11
Member since
Aug 26
Recent submissions
Comment · 2 months ago
Comment · 2 months ago
Hey everyone!
I’ve always faced a dilemma when setting up secure tools for non-technical friends: they love the usability of Proton, but I want 100% open-source, self-hosted control and open standards.
The main issue is that combining E2E encrypted docs (like CryptPad) and E2E encrypted mail usually meant managing isolated tools, browser extensions (like Mailvelope), or typing two different passwords every session. That is not ideal and when I introduce these solutions to my friends, they say "Thanks for your efforts, really, but I think I will still use Proton".
To solve this, I built AurionMail Suite. It's an open-source orchestrator, the glue, that bridges CryptPad, Stalwart Mail Server (JMAP), Bulwark Webmail, and Ory Hydra into a single, unified Zero-Knowledge workflow. And It also makes the Cryptpad UI (and Notes app) more friendly, really. I feel you need a proof to convince you, so there is a gif demonstrating the single password login in which we access to webmail and CryptPad on repo.
Key Features:
- One Single Master Password: Enter it once to derive keys in-memory for both webmail and CryptPad.
- Open Standards: OpenPGP for email encryption and JMAP via Stalwart.
- Zero-Knowledge: Master keys reside strictly in client-side RAM during the session (no unencrypted key writes to disk/IndexedDB).
- Unified Session Management: Global single logout and password changes that sync safely across services.
- Easy Deployment: In addition to manual setups, I wrapped the suite (Hydra, SSO, Webmail, API, CryptPad) into a single Go binary called Orchestra, making deployment straightforward.
There is a table to compare with alternatives on repo !
To keep the Zero-Knowledge promise across isolated services without relying on URL hashes or storing cleartext keys in disk storage, AurionMail uses ephemeral WebCrypto AES-GCM keys. Decrypted session secrets pass between origins through short-lived, encrypted RAM buffers managed by a central API, keeping credentials safe even across iframes. Check out our https://github.com/AurionMail/docs/blob/main/security_model.... for the exact cryptographic derivations and secret-sharing threat model.
The project is licensed under AGPLv3. I'd love to hear your feedback, bug reports, or thoughts on the architecture!
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 !