Media tokens (Privacy Pass, RFC 9497)
Storing files costs money, so storage needs a limit. A limit normally means an account, and an account means the server knows who uploaded what. Tokens separate the two: you prove you're allowed to upload without saying who you are.
The scheme Built
- Verifiable oblivious pseudorandom function (VOPRF), RFC 9497, mode 0x01, suite ristretto255-SHA512, using the
voprfcrate (MIT). - This is the privately verifiable kind of Privacy Pass token: the issuer and the verifying node share the secret key.
- A token is 104 bytes. Its input is bound to a week, the node it's for, and a random nonce.
- Nodes check the week, the key id, the VOPRF output and the spent-token set, in that order, and refuse with HTTP 402 if any check fails.
What each side learns
The issuer learns which account asked, the week, how many tokens, the time and the IP address. Because the tokens are blinded, it never learns their nonces, so it can't tell later whether, when or where a token was spent.
A storage node learns only that a valid token for it was spent in a given week, never an account.
Tagging is prevented by using one key per week for everyone, with a DLEQ proof the client checks, so the issuer can't give one user a key nobody else has.
Status
| Piece | Status |
|---|---|
| Token code in the core (a 104-byte token; the issuer sees 40 bytes and answers with 96) | Built |
| The node-side check and the spent-token set | Built in the node library |
| The issuer, with a constant-time check of its secret-key path | Built, not deployed |
| The node program serving the token routes | Planned |
| The wallet in the apps that holds and spends tokens | Planned |
| A publicly verifiable variant, needed before any node run by someone else | Planned |
How many tokens an account gets each week isn't decided yet. The same issuer holds a second key for report tokens.
Sources: docs/specs/media-token-v1.md, docs/specs/media-issuer-v1.md, docs/specs/report-token-v1.md; crates/pigeon-issuer, crates/pigeon-core/src/media/token.rs.
Related: media encryption and padding.