What protects your vault
You are considering putting a parent’s bank login into a website you had not heard of last week. These are the questions that deserve straight answers.
- Can you read my mother’s passwords?
- No. Every secret is encrypted in your browser before it is sent, with a key we never receive in usable form. Our servers hold ciphertext and a copy of that key wrapped by AWS KMS. We can prove we hold your data; we cannot show you what is in it.
- What can you read, then?
- The labels. The item title, the service name, the web address, the category, and who you have designated. So we can tell that you store a Chase account — we cannot tell you anything about it. If the existence of an account is itself sensitive, do not label it accurately.
- What happens if you get breached?
- An attacker with our database gets ciphertext and wrapped keys, not credentials. Unwrapping requires AWS KMS to authorise it for an authenticated session, which a stolen database does not provide.
- What happens if Relay disappears?
- You can export everything, decrypted in your browser, from your account page at any time — not on request, and not only if we are still around to answer. Keep that file the way you would keep a password list.
- Can someone trick you into opening my vault?
- Releasing requires the trigger you configured AND confirmation from the people you named. Relay never sends a link that signs anyone in — every message asks for a code typed at our address — so a convincing email cannot, by itself, open anything.
- What if I lose my phone?
- You get recovery codes when you create the vault. One of them enrols a new authenticator. Losing the phone costs you your sign-in, not your data — but lose the codes too and nobody can let you in, including us.
One thing we will not claim. Relay is early-stage software with no paying customers yet. The engineering above is real and you can inspect it, but a young product is a young product — please do not make this the only place something important is written down. Our terms say the same thing.
How it is built
For readers who want the mechanism rather than the reassurance.
- Client-side envelope encryption
- A per-item AES-GCM-256 data key is generated in the browser via SubtleCrypto, used to encrypt the secret, then wrapped by an AWS KMS customer master key. The server stores ciphertext plus the wrapped key and never handles the plaintext data key.
- A release state machine, not a share button
- ARMED → PENDING → GRACE → RELEASED, with exactly seven permitted transitions. Each one is a compare-and-set against a strongly-consistent store, so an owner, a verifier and the scheduler acting at the same moment cannot double-release. Exhausting a retry always lands back in ARMED — the safe state is the default, not the exception.
- Reversibility as a property of the trigger
- Whether a release can be undone is derived from the trigger type rather than a flag someone could set wrongly. Emergencies reverse; estate handoffs are permanent by construction.
- Hash-chained audit log
- Every access, grant and release is an append-only entry whose hash includes the previous entry’s. Editing history is detectable, and the chain is verifiable in your own browser rather than on our word. A failed audit write blocks the operation it was recording.
- Zero-knowledge boundary for the ranking
- The component that works out which credentials unlock the others reads labels only. It is structurally prevented from decrypting anything, so the analysis that makes the product useful cannot become the thing that exposes you.
- Aurora DSQL, active-active across regions
- The correctness invariant is owned by the database rather than reconstructed in application code, and the data survives the loss of a region.
Relay won Most Impactful at the H0 hackathon, judged on this architecture. The build is public and open to inspection.
Still deciding? The clearest way to judge it is to see what happens.