How it works

Sharing

1. You paste a secret and choose how long the link stays valid. Your browser generates a random key and encrypts the text (and any files) with it.
2. You get a link. The part before the hash points to the encrypted text on the server; the part after it is the key. Only someone with the whole link can read the secret.
3. The recipient opens the envelope. Only then does the browser fetch the encrypted text, and the server removes it in the same move. Opening it a second time is impossible, also for you. Optionally you allow 3 or 10 openings, or put a password on the link.
4. Changed your mind? Revoke the link. If the secret was already opened, Passit says so honestly, so you can change the password.
5. Files: up to 5 files of 25 MB each, encrypted one by one in your browser and uploaded in chunks. After opening, the recipient has 10 minutes to download them; then they are gone.

Requesting

1. You create a request with the fields you need, for example address, username and password of WordPress. Your browser generates a key pair: a public key to encrypt with and a private key to read with.
2. You get two links. The request link goes to your client; it contains your public key. The retrieval link is for you alone; it contains your private key. Keep it in your password manager.
3. Your client fills it in, without an account. Their browser encrypts the reply with your public key. Nobody else can open it, not even Passit.
4. You retrieve and wipe. Replies stay until you wipe them, and disappear in any case a day after the first retrieval.
5. With an account you get an email when a reply comes in, and Passit can email the link to your client on your behalf, including the key. For that one request a compromised server could swap the key; that is why the email always shows the verified account address, and why client emails are switched on per account by hand.

What the server does see

• Encrypted text and files, with an expiry date. No keys.
• For a request: the title, the message and the field names, in plain text. Your client has to be able to read them before they have a key. So do not put secrets in them.
• A hashed version of your IP address, for an hour at most, to slow down abuse.
• An activity log per link: when it was viewed, opened or answered, with the country and browser family (for example “Chrome, Windows”). No IP address. The sharer or requester sees that; the recipient and the client know it is shared.
• With an account: your email address, encrypted at rest, and the name, logo and accent colour you set yourself. Name and logo become visible to your clients 7 days after creating the account.

Passit does not verify who creates a request. Only fill in if you know the sender of a link. And as with any service that encrypts in the browser: the code that encrypts comes from the server. If that code is compromised, so is the promise. That is why the code is deliberately kept small.

The technology

Sharing

AES-256-GCM with a random 256-bit key and a 96-bit IV. The key sits as base64url in the URL fragment. The ciphertext is bound to the id of the secret, so it cannot be moved to another id. A password on the link is stretched with PBKDF2 and mixed into the key in your browser; the server only stores a check value.

Requesting

ECDH on P-256. The requester’s public key sits in the fragment of the request link, together with a SHA-256 of title, message and fields: if the server changes any of that, the client’s browser refuses. For every reply the client’s browser creates a one-time key pair, derives an AES key with HKDF-SHA256 and encrypts with that.

Opening once

One atomic database operation that returns the secret and counts the opening at the same time. Two people clicking at once: exactly one gets it.

WebCrypto only

No home-made cryptography and no external libraries; everything via the browser’s built-in Web Crypto API.