Scope
This document describes the parts of Skudo that decide who can learn the identity behind an alias. It is written for people evaluating that claim: security engineers, journalists assessing the service before recommending it, and anyone whose safety would be affected by getting the answer wrong.
It does not describe the dashboard, the billing system or the mobile clients except where they touch the mapping. Where a statement here depends on trusting Skudo rather than on a mechanism, it says so in those words.
The system in three parts
Mail arrives at a forwarding relay, which accepts messages addressed to an alias and needs one thing to deliver them: the address behind that alias. It reads that from the database, where the alias itself is stored in clear, because matching an incoming address is the whole job, and the address it forwards to is stored encrypted under a key held separately from the one protecting everything else. The dashboard writes new aliases and reads them back for you.
A copy of the database, taken on its own, does not reveal where anything is forwarded. It does not follow that Skudo cannot read it: the service decrypts the address to deliver your mail, so the key is on the same machines.
What is stored, and in what form
Everything in the table below exists because delivery, billing or abuse handling cannot work without it. Nothing is retained for analysis, and there is no data set kept "in case it is useful later".
| Record | Form | Retention |
|---|---|---|
| Alias address | Plaintext, the relay must match it to route mail | Until you delete the alias |
| Forwarding address | Encrypted under a dedicated key, with a keyed blind index for lookup | Until you remove the recipient |
| Alias note and display name | Encrypted under the application key | Until you delete the alias |
| Per-alias counters and last-used timestamps | Plaintext integers and timestamps; the relay updates them on every message | Until you delete the alias |
| Account credentials | Password hash; recovery secret split into two shares across separate stores | Life of the account |
| Delivery failures | Sender and destination encrypted; remote server, error code and time in clear | 7 days |
Message bodies are not in that table because they are not kept. A message is relayed from the inbound connection to the outbound one and no copy is retained afterwards. One exception: if the destination is temporarily unreachable, the message waits in the mail queue, which lives on disk like every mail server's queue, until it is delivered or expires.
Encrypting the forwarding address
The address an alias forwards to is encrypted with an authenticated cipher under a key of its own, configured separately from the application key that protects the rest of the encrypted columns. The point of the separation is narrow and worth stating precisely: leaking the application key alone is not enough to read forwarding addresses.
Alongside it sits a blind index, a keyed hash of the address, so that the service can find the row for a known address without decrypting the column or holding a list of addresses. The property that comes with it, stated for completeness: anyone holding the index key can test whether a particular address is present, though they cannot enumerate the addresses.
The recovery key, split in two
Account recovery is the place where a service usually keeps something that undoes all of its own encryption. Skudo stores the recovery secret as two random shares that combine back to it by exclusive-or, one in the main database and one in a separate store on a different service.
Neither share on its own says anything about the secret, and that is a mathematical statement rather than a hopeful one: exclusive-or against a share of equal length and full randomness is a one-time pad. A dump of the database alone, or of the other store alone, yields nothing usable. Both must be taken together, at the same time, from the same account.
What happens when an order arrives
- The order is received and reviewed against the law it is issued under. An order that is defective on its face is refused and, where the law allows, contested.
- Skudo produces what it holds. For an alias that is the address itself, which is in clear, together with the counters and timestamps attached to it.
- If a valid order demands the forwarding address, it can be decrypted. There is no second party to ask and no procedural step that prevents it. Skudo operates the service, holds the key, and is subject to the courts of one country.
- The count is published in the quarterly transparency report: how many orders arrived, how many sought an identity, and how many forwarding addresses were disclosed.
A gag order can prevent naming the requester or the timing. What remains visible is the aggregate count and the canary on the transparency page.
Abuse handling without identification
An alias used to send phishing or harassment is stopped at the relay: outbound sending is revoked and inbound delivery ceases. This acts on the address, not the person, and needs no decryption at all. Reports are answered with what happened to the alias, never with who held it.
Rate limits and outbound reputation monitoring are applied per account, using counters that do not require reading the mapping. An account that repeatedly generates aliases used for abuse is suspended as an account, again without decrypting anything.
What this does not protect against
A threat model that lists only what it defeats is marketing. These are the cases where the design above does not help, stated plainly.
- Traffic analysis by an observer on both sides. Someone who can watch connections into the relay and into your mailbox provider can correlate timing and size without touching the mapping at all. Skudo does not defend against a global passive adversary and no forwarding service can.
- Your own inbox. Every message forwarded to you exists in your mail provider's account, subject to that provider's policies and to any order served on them. An alias hides your address from the sender, not your mail from your own provider.
- Compulsion against you. Nothing here prevents an authority with power over you personally from demanding your credentials.
- Skudo itself. The service decrypts your forwarding address on every delivery, so the key is on the machines that run it. A valid order, or an attacker who takes the running system rather than a copy of the database, reaches it.
Cryptographic parameters
| Field encryption | AES-256-CBC with HMAC-SHA256 over the ciphertext |
|---|---|
| Forwarding address key | Separate from the application key, set per deployment |
| Blind index | Keyed hash under its own key, distinct from both of the above |
| Recovery secret | Two-of-two exclusive-or split, MySQL and Redis |
| Transport | TLS 1.3 preferred; MTA-STS published in testing mode |
| Forward encryption | OpenPGP to your key when one is supplied |
Audits and changes
There has been no external review yet. A review of this kind runs into the tens of thousands and Skudo is self-funded and free to use, so it is a question of budget rather than of willingness. When one is commissioned the report is published in full, including findings that remain open, on the transparency page.
This document is versioned. Material changes to the design, meaning the keys, what is stored or how long it is kept, are recorded here with the date they took effect, so that a claim made to you on one date can be checked against what the system did on that date.