Oblivious Pseudorandom Functions (OPRFs)

• OPRFs are defined as two-party protocols that allow a client to obtain F_K(x) without revealing its input while the server keeps the secret key K.
• Implementations include RSA-based and DDH-based constructions that use blinding to ensure correctness, obliviousness, and pseudorandomness.
• Extensions like Blocklisted OPRFs support privacy-preserving checks in federated authentication, secure password registration, and malware detection.

An Oblivious Pseudorandom Function (OPRF) is a two-party cryptographic primitive in which a client and a server jointly compute a keyed pseudorandom function $F_K(x)$—the client receives the output for its private input $x$, while the server holds the secret key $K$, but neither party learns anything more about the other's secret than what is inherent in the function output. OPRFs form a foundational building block for privacy-preserving protocols, enabling applications such as federated authentication, secure password registration, and blacklisting with input privacy maintained throughout. Their rigorous security stems from cryptographic assumptions such as the RSA inversion assumption or the Decisional Diffie-Hellman (DDH) problem, coupled with blinding techniques and, in advanced variants, privacy-preserving set intersection and embedding strategies (Buccafurri et al., 1 Dec 2025, Zhang et al., 21 Jul 2025).

1. Formal Definition and Properties

Let $\{F_K : D \to R\}_K$ denote a family of keyed functions, parameterized by server-generated key $K \leftarrow KeyGen(1^\lambda)$. An OPRF protocol operates between a client input $x \in D$ and a server holding $K$, satisfying three core guarantees:

• Correctness: Upon completion, the client obtains output $y = F_K(x)$.
• Obliviousness: The server learns nothing about $x$; the client learns nothing about $K$ beyond what is implied by $x$0.
• Pseudorandomness: $x$1 is computationally indistinguishable from uniform to the client, assuming an honest server.

This is formally realized by protocols decomposing into the sequence:

1. Client: Compute $x$2 and send $x$3 to server.
2. Server: $x$4 and send $x$5 to client.
3. Client: $x$6 to obtain $x$7.

Correct protocol execution ensures that $x$8 and the above security properties hold even if one party is malicious (Buccafurri et al., 1 Dec 2025, Zhang et al., 21 Jul 2025).

2. Concrete Constructions

RSA-Based OPRF

A standard OPRF construction uses RSA blind signatures. The server (central service) possesses an RSA key $x$9 with $K$0, $K$1. Hash functions $K$2 are modeled as random oracles. The PRF is defined as:

$K$3

Protocol steps:

• Client picks $K$4, computes $K$5; sends $K$6 to server.
• Server computes $K$7; returns $K$8.
• Client computes $K$9; output is $\{F_K : D \to R\}_K$0.

In some applications, the outer hash $\{F_K : D \to R\}_K$1 may be omitted and the domain-specific $\{F_K : D \to R\}_K$2 used directly (Buccafurri et al., 1 Dec 2025).

DDH-Based OPRF (Naor–Pinkas)

With cyclic group $\{F_K : D \to R\}_K$3 of prime order $\{F_K : D \to R\}_K$4 (DDH-hard), and hash $\{F_K : D \to R\}_K$5:

• Client chooses random $\{F_K : D \to R\}_K$6, sends $\{F_K : D \to R\}_K$7.
• Server computes $\{F_K : D \to R\}_K$8 for secret $\{F_K : D \to R\}_K$9.
• Client unblinds: $K \leftarrow KeyGen(1^\lambda)$0.
• Final output: $K \leftarrow KeyGen(1^\lambda)$1 using a key-derivation function $K \leftarrow KeyGen(1^\lambda)$2 (Zhang et al., 21 Jul 2025).

Security requires the DDH assumption, random oracle modeling, and blinding to protect $K \leftarrow KeyGen(1^\lambda)$3.

3. Extensions: Blocklisted OPRFs (B-OPRF)

Blocklisted OPRFs (B-OPRFs) generalize OPRFs to allow the server to enforce a blocklist $K \leftarrow KeyGen(1^\lambda)$4 (possibly “fuzzy,” via metric embedding). The evaluation only succeeds if $K \leftarrow KeyGen(1^\lambda)$5; otherwise, the process aborts without revealing $K \leftarrow KeyGen(1^\lambda)$6 (Zhang et al., 21 Jul 2025).

The architecture involves:

• Metric-space embedding: Transform $K \leftarrow KeyGen(1^\lambda)$7 to $K \leftarrow KeyGen(1^\lambda)$8 (embedding key $K \leftarrow KeyGen(1^\lambda)$9), compute $x \in D$0.
• Two-phase protocol:
  • Explicit check: OPRF-based embedding and private distance-aware set intersection. Abort if too close to $x \in D$1.
  • Commit token: Upon passing, compute $x \in D$2 ($x \in D$3), then OPRF on $x \in D$4 gives output; $x \in D$5 stores $x \in D$6.
  • Implicit check: For subsequent queries, $x \in D$7 recomputes $x \in D$8, $x \in D$9 allows efficient evaluation bypassing set intersection.
• Security: The client’s chance to evade blocklisting combines unpredictability of the permutation, PRF security, and false accept/reject rates parameterized by the blocklist embedding (Zhang et al., 21 Jul 2025).

4. Domain-Specific and Privacy-Preserving Transformations

To enforce unlinkability across federated authentication domains, a domain-specific exponent $K$0 is used by each identity provider (IdP):

• Each $K$1 applies $K$2 to the blinded input, yielding $K$3.
• CTS computes $K$4.
• IdP retrieves $K$5.

This transformation ensures that each IdP derives a pseudonymous identifier specific to its own domain, with no raw user identifier or possibility for cross-domain linkage, while still enabling global duplicate-registration checks (Buccafurri et al., 1 Dec 2025).

5. Security Analysis

The core security rests on established cryptographic assumptions:

• RSA inversion (for RSA-based OPRF): Given $K$6 and $K$7, inverting $K$8 is computationally infeasible.
• Random Oracle Model: $K$9 and $y = F_K(x)$0 (or $y = F_K(x)$1) behave as ideal random functions.
• DDH (for group-based OPRF): The indistinguishability of $y = F_K(x)$2 from random group elements.

Obliviousness for the input arises from the one-wayness of blinding (e.g., $y = F_K(x)$3 masks $y = F_K(x)$4), and pseudorandomness follows from standard reduction arguments. In B-OPRFs, cheating probabilities are bounded by the unpredictability of embedding permutations and the blocklist embedding’s statistical parameters. The security of embedding and blocklist checks is ensured through the use of additional OPRF/VOLE wrappers and cryptographic hashing that hides intermediate values (Buccafurri et al., 1 Dec 2025, Zhang et al., 21 Jul 2025).

6. Efficiency and Practical Implementations

The computational and communication overhead of OPRF protocols is well-understood and practical:

Actor	Computation	Communication
Client (IdP)	1 hash, 1 $y = F_K(x)$5, 2 exponentiations, 1 inversion	$y = F_K(x)$6-bit value to server; receives $y = F_K(x)$7-bit result
Server (CTS)	1 exponentiation	$y = F_K(x)$8-bit response

For $y = F_K(x)$9-bit RSA, evaluation time is in the low-millisecond range. OPRF-based blocklisting incurs higher cost due to private set intersection, but supports efficient repeat evaluations via token caching, reducing repeated cost to $x$0. In password-blocklisting experiments with $x$1 (embedded to $x$2), explicit check latency is $x$3 s and subsequent implicit check is $x$4 ms; communication is correspondingly $x$5 MB and $x$6 KB. For blocklisted MACs in malware applications with $x$7, explicit check is $x$8 s and $x$9 MB, implicit check just $K$0 s and $K$1 KB (Buccafurri et al., 1 Dec 2025, Zhang et al., 21 Jul 2025).

7. Applications and Protocol Flows

Federated Authentication

The privacy-preserving protocol for federated identity relies on OPRF for blinded registration and duplicate-enrollment detection while resisting cross-domain correlation. Each enrollment proceeds as:

1. User submits UPI to IdP.
2. IdP blinds UPI, applies domain exponent, and transmits to CTS.
3. CTS evaluates OPRF, returns result for unblinding.
4. IdP derives pseudonymous domain identifier and proves key possession.
5. CTS stores (PID, status) and issues a blind signature token (Buccafurri et al., 1 Dec 2025).

Blocklisting in PAKE and Executable MACs

B-OPRFs enable privacy-preserving password blocklisting in augmented PAKE and blocklisted MAC computation for malware-free executables:

• PAKE blocklisting: Input is checked against both exact and near matches of known weak passwords (edit distance $K$2); explicit check requires set intersection, implicit (repeat) check is fast.
• Executable MAC: Inputs are compared to blocklisted malware embeddings using PSI, with communication and latency improvements over monolithic approaches (Zhang et al., 21 Jul 2025).

These demonstrations highlight OPRFs’ adaptability to stringent privacy and efficiency requirements in diverse privacy-preserving distributed systems.