Oblivious Pseudorandom Functions (OPRF): The Quiet Workhorse of Modern Privacy

A pseudorandom function (PRF) is a keyed function whose output looks random to anyone without the key. HMAC is a familiar example: given a key and an input, it produces an output that is deterministic if you know the key and unpredictable if you do not. See our note on HMAC for the building block. The "oblivious" variant adds a constraint that seems almost contradictory at first.

In an OPRF there are two parties. The client has an input x. The server has a secret key k. At the end of the protocol the client learns F(k, x) and nothing else, and the server learns nothing at all. The server cannot see x, cannot see the output, and cannot link two requests to the same input. The client gets a correctly keyed result without ever holding the key.

How it works: blinding

The standard construction lives in a prime-order group, the same kind of elliptic-curve setting used elsewhere in modern cryptography. The trick is called blinding, and the math is short enough to follow.

1. The client hashes its input onto a curve point, P = H(x), and picks a random secret scalar r. It sends the blinded point P · r to the server. Because r is random, the blinded point reveals nothing about x.
2. The server multiplies by its key: it returns (P · r) · k. It is operating on a point it cannot interpret.
3. The client removes its blind by multiplying by the inverse of r, leaving P · k. It hashes that, together with x, into the final output.

The server applied its secret key to the client's input without ever learning the input, and the client got a key-bound result without ever learning the key. The randomness r is fresh each time, so two queries for the same x look unrelated to the server. That unlinkability is the property that makes the rest possible.

Three flavors, standardized

The CFRG specified these constructions in RFC 9497, which defines three modes over prime-order groups such as ristretto255 and NIST P-256.

Mode	What it adds
OPRF	The base protocol. Client learns F(k, x), server learns nothing.
VOPRF	Verifiable. The server attaches a zero-knowledge proof (a DLEQ proof) that it used the one committed key, so a malicious server cannot quietly use a different key per client to deanonymize.
POPRF	Partially oblivious. Allows a public input alongside the private one, useful for binding a result to a non-secret label such as a date or a rate-limit bucket.

The verifiable mode is the one that matters for anonymity systems. Without the proof, a server could hand each user a slightly different key, and later tell users apart by which key produced a token. The DLEQ proof, a relative of the zero-knowledge proofs covered elsewhere, closes that gap by forcing one key for everyone.

Where OPRFs already run

Anonymous tokens

Privacy Pass uses a VOPRF so a service can issue you tokens for passing a challenge once, which you later redeem without the service linking redemption back to issuance. You prove you earned a token without revealing which token-earning event was yours. This is how a network can rate-limit or vouch for clients without building a behavioral profile.

Password login that hides the password

OPAQUE, the asymmetric password-authenticated key exchange, uses an OPRF at its core. Your password is the client input; the server's OPRF key turns it into a strong secret used to unlock your stored credentials, and the server never sees the password, not even briefly, not even as a hash it could attack offline after a breach. Compare that to traditional password hashing, where the server does receive the password during login.

Private breach and set membership checks

Checking whether your password appears in a breach corpus usually relies on k-anonymity, which leaks a hash prefix. An OPRF-based design can do better: the service evaluates its key on your secret without learning it, so you can test membership against its database while revealing neither your query nor letting you enumerate its contents. The same shape underlies many private set intersection protocols, where two parties find their common elements and nothing else.

What an OPRF does not give you

It is a two-party building block, not a finished system, and it has clear edges.

The server cannot see the input. It can still see that someone made a request, from some address, at some time. An OPRF protects the contents of the query, not the fact that a query happened.

• It is interactive. Every evaluation needs a round trip to the key holder. The server is online and load-bearing, even if it is blind.
• It does not hide network metadata. Address and timing are still visible to the server and the network. Pair it with other measures if those matter.
• Online guessing still costs the attacker a query each. The OPRF stops offline brute force against a stolen database, which is the major win, but a malicious client can still try inputs one online query at a time, so rate limiting remains necessary.
• The base mode trusts the server's key choice. If you need the deanonymization protection, you need the verifiable mode and its proof, not the plain one.

None of these are flaws. They are the boundary of what a single primitive should claim. The reason OPRFs show up everywhere is that they solve one problem cleanly: letting a server apply a secret key to data it is not allowed to read. Once you can do that, a surprising amount of privacy engineering becomes a matter of composition. It sits alongside private information retrieval and Oblivious HTTP in the toolkit for systems that work without trusting the operator to behave.

That is also the posture we prefer when building Haven: lean on primitives whose guarantees are structural rather than promises, and be precise about where the guarantee stops.