Why the key stays in the link
The # sign in a Sésame Éclair link separates what our server receives from what it never sees. Here is how.
A Sésame Éclair link looks like this:
https://eclair.kayzen-lyon.com/s/Q2xhaXJlTGFQb2ludGU#v1.n.k7X…
Everything before the # sign is used to find the secret. Everything after it is the key needed to read it. This split is not our own convention: it is part of how the Web works.
What the browser never sends
The part of an address after # is called the fragment. The Web address standard (RFC 3986) keeps it in the browser: it is never sent to the server in the request. When your recipient opens the link, our server receives the secret's identifier, but not the key.
The recipient's browser reads the key from the fragment, downloads the encrypted block and decrypts it locally.
What we receive when you create a secret
When you create a secret, your browser:
- draws a random 256-bit key;
- encrypts the content with AES-256-GCM, after padding it to a standard size so its length is not revealed;
- sends us only the encrypted result, the chosen expiry and the number of reads allowed;
- puts the key in the fragment of the link it shows you.
So we store an unreadable block. Even with full access to our database, the content cannot be recovered without the link.
What about the PIN?
The PIN adds a second key, derived from the code with Argon2id, a deliberately slow function that makes guessing expensive. The server only receives a verifier that cannot be turned back into the code. After five wrong attempts, the secret is destroyed.
The limits, honestly
- The link is the secret. Anyone who gets it before your recipient can read it. Your recipient will know, though: they will see the link has already been used, and the read receipt will tell you. For sensitive credentials, add a PIN and send it through another channel.
- The fragment stays in the history of the recipient's browser. The secret is not there, and the link no longer works after reading.
- Encryption happens in the page we serve. The site's security policy forbids any third-party script, and the format is publicly documented, with its test vectors.
You can see exactly what our server receives on the "What the server sees" page.