Under the hood

How Scroogle Mail encrypts your email

The plain-English version lives on our security page. This page is for people who want the specifics: which algorithms, which parameters, what exactly is encrypted - and, just as importantly, what isn't.

The short version

  • Between Scroogle users: end-to-end encrypted. Encrypted on the sender's device, decrypted on yours. Our servers relay ciphertext they cannot open.
  • Everything stored: zero-access. Your whole mailbox sits on disk as encrypted blobs, locked with keys derived from your password. We cannot read it, so we cannot leak it, sell it or hand it over readable.
  • In transit: TLS 1.3, with MTA-STS and DANE so connections to other providers can't be quietly downgraded.
  • The honest limit: ordinary email crossing the open internet carries routing metadata (sender, recipient, timestamps). No provider can encrypt that away, including us. We say so plainly below.
The specifics

The algorithms we use

Nothing exotic, on purpose. Every primitive here is standard, heavily reviewed and boring in the best possible way. We do not invent cryptography; we assemble the well-studied kind carefully.

Job What we use Notes
Symmetric encryption AES-256-GCM Authenticated encryption for message bodies, attachments and mailbox blobs. GCM means tampering is detected, not just prevented from being read.
Key exchange / asymmetric Curve25519 (x25519) Modern elliptic-curve keys: small, fast and among the most scrutinised curves in use. Signatures use its sibling, Ed25519.
Password-derived key Argon2id Memory-hard key derivation, currently tuned to 64 MiB of memory, 3 passes and 4 lanes - deliberately expensive so offline guessing attacks are slow and costly. Parameters are reviewed yearly and only ratcheted upwards.
Message format OpenPGP An open standard rather than a private format, so you can exchange encrypted mail with anyone running PGP anywhere - and leave us without losing access to your archive.
Transport TLS 1.3 + MTA-STS + DANE Encrypted connections to your device and to other mail servers. MTA-STS and DANE stop an attacker on the network stripping encryption from server-to-server delivery.
Post-quantum x25519 + ML-KEM (Kyber), hybrid On our roadmap, honestly labelled: not yet shipped. The hybrid construction keeps today's security even if the post-quantum half turns out to have flaws. Track it on the roadmap.

Cipher choices and parameters are documented in our audit scope and re-examined in every annual audit. If we change a primitive, it goes in the changelog.

Per data type

What is encrypted, exactly

"Encrypted" is a slippery word in marketing. Here is the precise list - including the part most providers leave off: what encryption cannot hide.

Encrypted, zero-access

Stored only as ciphertext. Readable with your keys, on your devices, and nowhere else.

  • Message bodies and attachments - encrypted to your key before they touch disk. This is the core of zero-access storage.
  • Subject lines - encrypted at rest, unlike classic PGP setups where the subject travels and sits in the clear.
  • Contacts - names, addresses and notes in your address book are stored encrypted.
  • Calendar event details - titles, descriptions, locations and attendee notes in Scroogle Calendar are encrypted; our servers see only opaque blobs plus the timing data needed to fire reminders.
  • Drafts - encrypted the same way as delivered mail, from the first autosave.

Not hidden - and can't be

Email is a federated, 40-year-old system. Routing it requires some data in the clear. Anyone who claims otherwise is selling something.

  • Envelope metadata on external mail - when mail arrives from or leaves for another provider, SMTP requires the sender and recipient addresses in the clear to route it. Every provider on Earth sees this for the mail it handles.
  • Timestamps - when a message arrived or was sent is visible to the servers that carried it.
  • Approximate message size - ciphertext length roughly reveals how big a message is, even though the content is sealed.
  • Your account's existence - that an address exists and is active is observable by anyone who emails it.

We keep this metadata only as long as operations require - delivery logs are held for 3 days - and we publish what we can be compelled to produce in our transparency report.

The core idea

Zero-access, explained

Most "encrypted" hosting means the provider encrypts your data with keys the provider holds - which protects you from a stolen hard drive and nothing else. Zero-access means the keys are never ours to hold.

1

Keys are made from your password, on your device

When you sign in, your device runs your password through Argon2id to derive your key material and unlock your private key. The password itself is never sent to us - we verify you with a derived proof, not the secret.

2

We store encrypted blobs, nothing more

What sits in our Zurich and Lausanne datacentres is ciphertext: sealed mailbox blocks we cannot open. A subpoenaed disk, a rogue employee or a breach of our storage layer yields the same thing - noise.

3

Decryption happens where you are

Your mail is decrypted in your browser or app, after your key is unlocked locally. Our open-source clients let you check that claim rather than take it on faith - see the security page.

The honest trade: because we hold no keys, a forgotten password with no recovery phrase means your stored mail is unreadable - by you, by us, by anyone. That is not a bug; it is the same property that keeps everyone else out. Your recovery phrase, shown once at signup, is the escape hatch. Keep it.
The other 4 billion inboxes

Mail to people who aren't on Scroogle

End-to-end encryption needs both ends to cooperate. When the other end is a Gmail or Outlook address, you have two options - and we're upfront about what each one does and doesn't protect.

Password-protected encrypted message

Tick "Encrypt" when composing and set a password. The recipient gets a link to a secure viewing page; the message decrypts in their browser only after they enter the password, which you share with them some other way - a call, a text, in person. They can reply encrypted from that same page.

  • Content stays end-to-end encrypted - their provider sees only a notification with a link
  • Optional expiry, from one hour to four weeks (28 days by default)
  • Attachments included, up to your plan's message size limit

Ordinary email over TLS

Send normally and the message travels to their provider over TLS 1.3 - encrypted in transit, delivered as regular email. Honest caveat: from that point on it is exactly as private as their provider makes it. If they're on a free ad-funded service, the copy in their inbox lives under that service's rules.

  • Zero friction - it's just email, and it works with everyone
  • Your stored copy in Sent remains zero-access encrypted with us
  • We enforce TLS to major providers via MTA-STS rather than falling back to plaintext

Emailing someone who uses PGP with another provider? Exchange public keys and it's end-to-end OpenPGP, no viewing page needed.

Design decisions

Why we don't rely on PGP for everything - and skip S/MIME

We use the OpenPGP message format because it is an open standard: it keeps you interoperable with the wider PGP world and means your archive is never trapped in a proprietary container. But raw PGP, used the classic way, has well-known gaps - subjects and metadata in the clear, brittle key management that ordinary humans understandably refuse to do by hand.

So the heavy lifting is our own zero-access layer: automatic key generation and distribution between Scroogle users, encrypted subjects, encrypted contacts and calendar data, and Argon2id-protected key storage. PGP is the envelope standard; the system around it is what actually keeps your mailbox sealed without asking you to run a key ceremony at your kitchen table.

As for S/MIME: we deliberately don't offer it. It depends on certificate authorities you have no reason to trust with your mail, and the EFAIL class of attacks showed how its common client implementations could be tricked into leaking plaintext of previously captured messages. Supporting it would add an attack surface to tick a compliance box. We'd rather not.

Don't take our word for it

Verify it yourself

Claims about encryption are cheap. Checkable claims are the point. Here is where to do the checking.

Open-source clients

Our web, mobile and desktop clients - the code that holds your keys - are open source. Read the crypto, build them yourself, compare what runs against what's published. Where to find the code.

Published audits + bounty

Independent security firms audit our cryptography annually and the reports are published, findings and all. Found something they missed? The bug bounty pays for it.

Engineering write-ups

When we change something that touches your keys or ciphertext, we write it up in plain language on the blog and log it in the changelog - before it ships, not after someone notices.

Good questions

Encryption questions, answered honestly

If everything is encrypted, how do you filter spam?
Inbound mail from other providers necessarily arrives readable at the moment of delivery - that's how SMTP works. Our filters run at that instant, in memory, and the message is then encrypted to your key before it is stored. It is never written to disk in the clear and never used for anything except the accept/reject decision. Mail between Scroogle users is end-to-end encrypted and never scanned by us at all.
Are you protected against "harvest now, decrypt later" quantum attacks?
Partly, and we won't overstate it. AES-256 is considered comfortably quantum-resistant. The x25519 key exchange is not, in theory, if a large-scale quantum computer ever exists - which is why a hybrid x25519 + ML-KEM (Kyber) scheme is on our roadmap. It is not shipped yet, and any provider telling you they're "quantum-proof" today deserves a sceptical squint.
Why should I believe any of this rather than just trust you?
You shouldn't just trust us - that's the design goal. The clients that handle your keys are open source, the cryptography is standard and documented, and independent auditors check the implementation every year with published reports. Trust the maths and the paper trail, not the marketing. Start with the security page.

Encryption you can check, not just believe.

Zero-access storage, standard cryptography and an honest list of limits - from £2.99 a month, VAT included. Setup takes about three minutes.

Get Scroogle Mail