vOPRF Nullifiers

Generate deterministic, scope-bound nullifiers using a verifiable oblivious pseudorandom function (vOPRF) whose secret key is held by a threshold committee. The client blinds its input, the committee jointly evaluates the OPRF, and the client unblinds the response to derive a nullifier. The server key prevents offline reconstruction from a leaked client secret; verifiability lets the client detect a malicious committee response.

Works best when

  • You need deterministic per-scope nullifiers or pseudonyms for credentials and signals without revealing the underlying identifier.
  • You want to bound the damage from client-key compromise. Without the server key, an attacker cannot reconstruct past nullifiers from a leaked client secret alone.
  • You can operate or rely on a threshold committee with clear governance, uptime, and abuse controls.

Avoid when

  • A local nullifier (hash of user secret with scope) is sufficient and offline linkage from client compromise is acceptable.
  • An online dependency is not acceptable for latency, availability, or regional deployment reasons.
  • Trust and compliance for the threshold committee or operator set cannot be established.

I2I vs I2U — context differences

Institution to institution

I2I

Between institutions the committee is typically contracted between known parties with SLAs and legal recourse. The online dependency is a liveness concern for high-frequency operations and needs active-active deployment. Governance of the committee key material is bilateral or consortium-based.

Institution to end user

I2U

For users the committee must be permissionless or operator-diverse so that no coalition can recover the base identifier. Economic bonding with slashing and a public audit log of evaluation requests protect against silent collusion. Without operator diversity the user has no recourse if the committee is coerced.

Post-quantum exposure

Risk · high
Vector
Current OPRF constructions rely on the DDH assumption in a prime-order elliptic-curve group, which is broken by a CRQC. HNDL risk applies to any recorded blinded request, since a future adversary with quantum capability plus the committee key could de-blind and reconstruct nullifiers.
Mitigation
Post-quantum OPRF constructions (lattice-based, VDF-based) are in research. Migration requires re-keying the committee, versioning scopes with a key identifier, and accepting larger message sizes. See Post-Quantum Threats.

Components

  • Client-side input framing combines a stable identifier (credential identifier, membership secret, device key), a scope (service identifier, action identifier, epoch), and a domain-separation tag into the OPRF input.
  • Blinding and unblinding routines implement the hash-to-curve and blind or unblind operations of the chosen OPRF instantiation.
  • Threshold vOPRF committee holds the server private key in t-of-n shares. Each node evaluates its share on the blinded input; the client combines t responses into a single evaluation.
  • Committee public key used by the client to verify that the combined evaluation corresponds to the advertised key.
  • Rate-limit and abuse gate in front of the committee (authenticated tokens, fees, proof-of-eligibility) to prevent exhaustive-query attacks that would reveal mappings.
  • Nullifier registry records used nullifiers to enforce one-use-per-scope semantics (on-chain contract or off-chain log).

Protocol

  1. user Derive the scoped input x by hashing a domain tag with the base identifier, the scope descriptor, epoch, and chain context.
  2. user Hash x to a curve point, blind it with a random scalar, and submit the blinded point and scope metadata to the committee along with any required rate-limit token.
  3. operator Each committee node evaluates its key share on the blinded point and returns its share plus a verifiability proof.
  4. user Combine t shares, verify the response against the committee public key, and discard the result if verification fails.
  5. user Unblind the response to obtain y, then derive a domain-separated seed and the final nullifier by hashing.
  6. contract Register the nullifier in the on-chain registry, or attach it to a zero-knowledge proof or credential presentation as the anti-replay handle.

Guarantees & threat model

Guarantees:

  • Deterministic per-scope output: the same base identifier under the same scope always produces the same nullifier.
  • Input privacy against the committee: the committee does not learn the base identifier in the vOPRF model.
  • Verifiability: the client can detect a committee response that does not correspond to the advertised public key.
  • Reduced offline linkage: a leaked client secret alone cannot reconstruct past nullifiers without live committee access.

Threat model:

  • Honest-threshold assumption on the committee. A coalition of t or more nodes can evaluate arbitrary inputs offline and reconstruct all nullifiers for any recorded base identifier.
  • An attacker who compromises the client can reissue evaluation requests with the same inputs and regenerate nullifiers. Determinism is a feature, and this path must be mitigated with scoped epochs, access controls, or proof-of-eligibility.
  • Abuse and denial of service on the committee. The evaluation endpoint must be gated to prevent committee exhaustion or mapping attacks that brute-force small identifier spaces.
  • Committee metadata (timing, IP, volume) is out of scope for the vOPRF layer and must be handled by a network-anonymity layer.

Trade-offs

  • Online dependency: evaluation requires a live committee, adding latency and an availability risk.
  • Committee governance overhead: threshold key generation, share rotation, incident response, and key versioning are operational burdens. Rotating keys changes outputs unless scopes include an explicit key identifier.
  • Scope design is delicate. Too-broad scopes create cross-service linkability; too-narrow scopes defeat the anti-replay or rate-limit purpose.
  • Denial-of-service surface on the committee requires rate-limit tokens, fees, or proof-of-eligibility.

Example

A KYC issuer gives a user a credential with an internal credential identifier. A downstream service wants to enforce one active session per user per day without learning who the user is. The scope is the hash of the service identifier, the action "daily-session", and the day bucket. The user derives the OPRF input from the credential identifier and the scope, blinds it, and submits to the committee. After verification and unblinding, the user derives a nullifier, and the service records it to reject any duplicate submission within the day.

See also

Open-source implementations