Zero-Knowledge Encryption
Your data is encrypted before it leaves your browser. We can't read it. Nobody can — not even us. Faral cannot access your emails, documents, files, contacts, or calendar details. Period.
Key hierarchy
Faral uses a three-tier PGP key hierarchy rooted in your password. Every key is generated and managed client-side.
├── Mail Key — email encryption only (PGP/MIME, WKD, encrypt-on-arrival)
└── Content Key — wraps per-resource AES-256-GCM keys
├── contacts:{user} AES key
├── documents:{user} AES key
└── drive:{user} AES key
Master Key Curve25519
Generated client-side. Encrypted with AES-256-GCM using Argon2id(password, salt). Stored encrypted in KMS. The server never sees the plaintext key or your password.
Mail Key PGP/MIME
Used exclusively for email encryption. Published via WKD (Web Key Directory) so other Faral users and external PGP users can send you encrypted email. Revocable independently without affecting other data.
Content Key AES-256-GCM
Wraps all non-email data. Each resource type (contacts, docs, drive) gets its own AES-256-GCM key, wrapped with the Content Key's PGP public key and stored in KMS.
SRP-6a — Zero-Knowledge Proof
Your password is never transmitted, not even as a hash. Faral uses Secure Remote Password (SRP-6a, RFC 5054) for authentication.
Registration
Browser generates Master key
A Curve25519 keypair is generated entirely client-side. The private key never leaves the browser.
Password derives SRP verifier
Password → Argon2id (time=3, mem=64MB, parallelism=1) → SRP verifier. Only the verifier is sent to the server.
Master key encrypted separately
A separate Argon2id derivation encrypts the Master key with AES-256-GCM. The encrypted blob is stored in KMS.
Server stores only the verifier
The server cannot reverse-engineer the password from the SRP verifier. No password, no hash, no plaintext key.
Login
SRP-6a mutual handshake
Browser and server perform the SRP-6a handshake. Both sides prove knowledge without revealing the password.
Session tokens issued
On success, the server returns the encrypted Master key and Ed25519-signed session tokens.
Client-side decryption
Browser derives the AES key from the password, decrypts the Master key locally. Master key unlocks Mail + Content keys from KMS.
What's encrypted vs. what's visible
We encrypt content. Metadata needed for functionality stays plaintext. Here's the exact breakdown.
| Data type | Encrypted (server cannot read) | Plaintext (server can see) | Method |
|---|---|---|---|
| Message body, attachments | Subject, From/To, timestamps | PGP/MIME with Mail key | |
| Contacts | Phone, address, notes, company, job title, links | Name, email, categories | AES-256-GCM with Content key |
| Documents | Entire document content | Title, timestamps | AES-256-GCM with Content key |
| Drive | File content (blob) | Filename, MIME type, folder structure | AES-256-GCM with Content key |
| Calendar | Description, location | Title, time, attendees, recurrence | Multi-recipient PGP with Mail keys |
Design choice: Filenames and email subjects stay plaintext so the server can search, sort, and display them. File content is always encrypted.
Isolated Key Management Service
The KMS is a separate microservice with its own database. The API server cannot access KMS data directly.
Separate database
The KMS uses its own database (faral_keys) with different credentials on a different host. The API server has zero access.
Stores only encrypted blobs
Master keys (AES-wrapped), Mail keys (PGP-wrapped), Content keys (PGP-wrapped), AES content keys (PGP-wrapped). The KMS cannot decrypt any of them.
Ed25519 session tokens
Signed with Ed25519, not RSA. 30-minute access tokens, 24-hour refresh tokens. Token hashes stored in the database for instant revocation on logout.
Server-side revocation
Every KMS request validates the session exists in the database. Logout immediately invalidates all tokens — no waiting for expiry.
Email encryption
Different levels of encryption depending on the recipient — always as strong as possible.
Between Faral users
End-to-end PGP/MIME (RFC 3156). Sender encrypts with recipient's Mail key (fetched via WKD). Recipient decrypts with their own Mail key. Server sees only the encrypted PGP message.
Encrypt-on-arrival
Incoming email from external senders is encrypted with your Mail key by the mail server before storage. Even if the sender didn't use PGP, your mailbox is encrypted at rest.
External recipients without PGP
Faral offers a Secure Portal. Messages are encrypted with AES-256-GCM using PBKDF2-SHA256 (600,000 iterations) derived from a shared passphrase. The server stores only the encrypted blob.
WKD — Web Key Directory
Your Mail public key is published at /.well-known/openpgpkey/ so any PGP-compatible client can discover it and send you encrypted email.
Multi-recipient calendar encryption
Calendar events use multi-recipient PGP instead of AES content keys. This is intentional — calendar events are inherently shared and email-adjacent (iMIM/iTIP).
How it works
The organizer encrypts the event description and location with all attendees' Mail keys. Each attendee can decrypt with their own Mail key.
The server can see event times and attendee lists (needed for scheduling) but cannot read descriptions or locations.
Account recovery
No backdoors. No admin password reset. No "forgot password" link that bypasses encryption.
BIP39 mnemonic recovery
During account creation, you receive a 12-word recovery phrase. Your Master key is encrypted with Argon2id(mnemonic, recovery_salt) and stored as a recovery blob. If you lose your password, the recovery phrase can decrypt your Master key and restore full access.
No backdoors — by design
If you lose both your password and recovery phrase, your data is irrecoverable. This is not a flaw — it's the only honest way to guarantee that nobody else can access your data either.
Client-side key caching
Keys are cached in the browser's IndexedDB to avoid re-fetching from KMS on every operation.
PGP private keys
Encrypted with a per-session AES-256-GCM wrapper key before storing to disk. This prevents raw private key material from being written to IndexedDB in plaintext.
AES content keys
Imported as non-extractable WebCrypto CryptoKey objects. The raw bytes never touch JavaScript or disk.
Logout cleanup
On logout, all cached keys are destroyed. This protects against disk forensics and casual data exposure, not against active XSS. XSS protection is handled through Content Security Policy, HttpOnly cookies, input sanitization, and framework-level protections.
Cryptographic standards
Every cryptographic choice maps to a published standard. No proprietary algorithms.
| Component | Algorithm | Standard |
|---|---|---|
| Master / Mail / Content Keys | Curve25519 ECC | OpenPGP v4 |
| Content Encryption | AES-256-GCM | NIST SP 800-38D |
| Password Derivation | Argon2id | RFC 9106 |
| Portal Passphrase | PBKDF2-SHA256, 600k iter | RFC 2898 |
| Token Signing | Ed25519 | RFC 8032 |
| Authentication | SRP-6a | RFC 5054 |
| Email Encryption | PGP/MIME | RFC 3156 |
System architecture
All encryption and decryption happens in the browser. The server routes requests and stores encrypted blobs.
Threat model
We'd rather be explicit about what we protect against — and what we don't — than make promises you can't verify.
What we protect against
- Server compromise — a database breach reveals only encrypted blobs, useless without your password
- Network eavesdropping — TLS in transit, plus client-side encryption means even intercepted data is encrypted
- Insider threats — our team cannot read your data, not even with full database access
- Brute-force attacks — Argon2id enforces ~150ms per attempt, plus server-side rate limiting and lockout
What we do not protect against
- Client-side malware or XSS — an attacker with script execution can use in-memory keys to decrypt data (inherent to all browser-based E2EE)
- Lost credentials — if you lose both your password and recovery phrase, your data is irrecoverable by design
- Metadata visibility — email subject lines, calendar event times, and filenames are visible to the server (needed for functionality)
Common questions
Your firm needs encryption that doesn't cripple operations
Faral is in invite-only testing. Request access for yourself or get in touch about your organization.