Wiki · Concept · Last reviewed June 25, 2026

Oblivious Pseudorandom Functions

Oblivious Pseudorandom Functions, or OPRFs, are two-party cryptographic protocols for computing a keyed pseudorandom output without exposing the client's input to the server or the server's key to the client.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: OPRF, VOPRF, Privacy Pass, OPAQUE, privacy, credentials

Definition

An Oblivious Pseudorandom Function is an interactive protocol between a client and a server. RFC 9497 defines the server as holding the PRF private key and the client as holding the PRF input. At the end of the protocol, the client learns the PRF output. The client does not learn the private key, and the server does not learn the client's input or output.

That separation makes OPRFs useful where a service must participate in a computation without seeing the thing being checked. The output is still deterministic for the relevant key and input, but the exchange is designed so the server is not simply handed the input in cleartext. RFC 9497 was published in December 2023 as an Informational RFC from the IRTF Crypto Forum Research Group; it is not an Internet Standards Track specification.

How It Works

In simplified terms, the client blinds an input, the server evaluates the blinded value with its private key, and the client unblinds the response to obtain the PRF output. The actual RFC 9497 protocol is more careful: it defines OPRF suites over prime-order groups, including elliptic-curve groups, and specifies serialization, hashing, proof, and input-validation details that implementations cannot safely improvise.

OPRFs are close to Verifiable Random Functions in vocabulary, but not in role. A VRF is a public-verification primitive: a key holder computes an output and proof that anyone can check. An OPRF is an interactive privacy primitive: the client and server cooperate so the client gets a keyed result while the server stays blind to the private input.

Variants

RFC 9497 specifies three related modes. OPRF mode gives the basic oblivious computation. VOPRF, or Verifiable OPRF, adds a proof so the client can verify that the server used the private key corresponding to the public key the client expected. POPRF, or Partially Oblivious PRF, lets the client and server include public input as part of the computation while keeping the private input hidden.

The distinction matters for governance. If a protocol claims verifiability, the client needs a way to know which public key it is verifying against. If a protocol uses public input, that input may become policy metadata: account class, issuer name, rate-limit bucket, origin, tool family, or application context.

Privacy Pass and OPAQUE

Privacy Pass shows the access-control side. RFC 9578, published in June 2024 on the IETF Standards Track, defines two issuance protocols for Privacy Pass tokens: a privately verifiable variant based on OPRF and a publicly verifiable variant based on blind RSA. In that setting, the primitive helps a client obtain a token without turning the issuance interaction into a stable identity record.

OPAQUE shows the password side. RFC 9807, published in July 2025 as an Informational IRTF RFC, describes OPAQUE as an augmented password-authenticated key exchange protocol. The document says OPAQUE uses an OPRF as one of its cryptographic dependencies and is designed to hide the password from the server, including during registration. That does not make OPRF a password manager by itself; it means OPRF is one component inside a larger protocol.

Agent Context

Agent infrastructure increasingly needs privacy-preserving checks: whether a browser, device, wallet, crawler, or delegated tool can present an access signal without revealing a stable identifier. OPRF-based protocols can support that pattern when the system needs participation from an issuer or server but should not disclose the client's private input.

For agents, the governance question is concrete. Does the issuer learn the requested origin, tool, task, user account, device class, or client identity? Does the verifier learn only a token result, or also metadata about issuance? The cryptographic primitive narrows one leak; it does not decide the whole policy.

Governance Use

A serious OPRF deployment should record the mode, ciphersuite, key identifier, issuer or server role, input domain, public-input fields, proof requirement, token or output lifetime, replay policy, key-rotation path, and error behavior. It should also define whether failed evaluations are logged and whether logs retain enough metadata to reconstruct the private inputs the protocol was meant to protect.

The access rule should stay separate from the cryptographic result. A valid OPRF-derived output can mean that a protocol step completed under a known key. It does not prove consent, human authorship, legal authority, safe automation, licensing rights, or moral trustworthiness.

Limits

OPRFs do not erase traffic metadata, device fingerprinting, issuer concentration, side channels, weak input spaces, or implementation bugs. A small input domain can still invite guessing attacks in the surrounding system. A compromised server key can damage past or future assumptions depending on the protocol. A poorly scoped public input can recreate tracking under another name.

They are also not interchangeable with zero-knowledge proofs, blind signatures, secure multi-party computation, or VRFs. Each primitive hides and reveals different facts. Treating them as generic "privacy crypto" is how systems overclaim and users lose meaningful choice.

Source Discipline

Use RFC 9497 for OPRF, VOPRF, and POPRF definitions. Use RFC 9578 for Privacy Pass issuance claims. Use RFC 9807 only for OPAQUE and password-authenticated key exchange claims. Use RFC 9381 when contrasting OPRFs with VRFs. Do not cite OPRF as proof that a deployment is anonymous, compliant, decentralized, or fair.

Spiralist Reading

Spiralism reads OPRFs as a discipline for asking without confessing. The client needs help from an institution, but the institution does not automatically deserve the private input.

That is a modest but important design ethic for machine-mediated life. The future of agents will include many access gates. The question is whether every gate becomes a name collection point, or whether some gates can learn only what they need to decide.

Sources

Return to Wiki