Wiki · Concept · Last reviewed June 25, 2026

Verifiable Random Functions

Verifiable Random Functions, or VRFs, are cryptographic functions that let one party compute a pseudorandom output and proof while letting others verify that the output really came from the matching secret key and input.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: VRF, key transparency, privacy, agent identity, cryptography

Definition

A Verifiable Random Function is a public-key version of a keyed cryptographic hash. RFC 9381, published in August 2023 on the IRTF stream as a Crypto Forum Research Group product, defines VRFs and specifies RSA and elliptic-curve constructions. The secret-key holder computes the output for an input. Anyone with the matching public key can verify the proof, input, and output without learning the secret key.

That combination is what makes the primitive useful. The output should look unpredictable to outsiders before it is computed, but the result is not merely an assertion. It arrives with evidence that can be checked. A VRF therefore sits between a hash, a signature, and a randomness source: it hashes under a private key, proves correct computation, and produces an output meant to be pseudorandom under the stated assumptions.

How It Works

In a typical VRF workflow, a key generator creates a public key and secret key. A prover takes the secret key and an input, then produces a VRF output and proof. A verifier takes the public key, input, output, and proof, then accepts or rejects. For a fixed key and input, the output is deterministic. For a party without the secret key, future outputs should not be predictable from other observed outputs.

This is different from a normal signature. A signature proves that a key holder approved a message; a VRF produces a pseudorandom value tied to the input and key. It is also different from an ordinary hash. A hash can be recomputed by anyone; a VRF output can be checked by anyone but computed only by the key holder.

Directory Privacy

The most relevant Spiralist use case is not a lottery. It is the private directory. RFC 9381 notes that VRFs are useful for preventing enumeration of hash-based data structures. If a directory indexed records by usernames, phone numbers, email addresses, or agent IDs, auditors could learn more than intended. A VRF can turn an identifier into a hidden index while still allowing authorized verification of the derivation.

Apple's iMessage Contact Key Verification is a concrete example. Apple Security Research says its Key Transparency sparse map is indexed by a SHA-256 hash of the output of a VRF for an iMessage identifier, similar to WhatsApp's Auditable Key Directory. The purpose is privacy: the system can support auditable key lookup without exposing a simple list of identifiers to every auditor.

The active IETF KEYTRANS protocol draft cites RFC 9381 in its normative references. That does not make every Key Transparency deployment identical, and the KEYTRANS drafts remain Internet-Drafts, not final RFCs. It does show why VRFs belong beside Key Transparency: hidden labels, public proofs, and auditability have to be designed together.

Agent Context

Agent systems increasingly need directories too: bot keys, delegated tool identities, wallet contacts, enterprise connectors, signing keys, and service principals. If those directories expose every identifier, they can become surveillance indexes. If they hide everything, clients cannot audit what they are given. A VRF can build a narrower disclosure path: prove that a lookup was derived correctly without making the whole namespace easy to scrape.

For agents, this matters when a browser, gateway, or ledger needs to ask, "Which key belongs to this actor?" without turning every lookup into a permanent social graph. VRFs do not solve agent authorization, but they can reduce one form of unnecessary visibility in identity infrastructure.

Governance Use

A governance-grade use of VRFs should record the input namespace, public-key identifier, proof format, verification result, directory epoch, rotation event, error path, and retention rule. If the VRF protects user or agent identifiers, the system should document who can compute outputs, who can verify proofs, how inputs are normalized, and what happens when the secret key rotates or is compromised.

Privacy Pass is a useful contrast. RFC 9578 specifies issuance protocols for Privacy Pass tokens, including a privately verifiable mode based on an Oblivious Pseudorandom Function and a publicly verifiable mode based on blind RSA. People sometimes encounter OPRF or VOPRF language near privacy tokens, but a VRF is not the same primitive as an oblivious issuance protocol. Mixing the terms can hide who learns the input, who computes the function, and who can verify the result.

Limits

A VRF is not encryption, consent, authorization, anonymity, or a zero-knowledge proof system for arbitrary claims. It can hide a directory label from casual enumeration, but it does not hide metadata around lookup timing, account creation, key rotation, IP traffic, device identity, or policy decisions. It also concentrates power in the secret-key holder: compromise, misuse, weak input normalization, or careless key rotation can damage the intended privacy and integrity properties.

VRFs should therefore be reviewed as part of a full protocol. The questions are not only whether the math verifies. They are also whether the identifier space is small enough to attack, whether the same VRF key is reused across contexts, whether verifiers receive enough evidence, and whether users or agents have a meaningful fallback when verification fails.

Source Discipline

Use RFC 9381 for the definition, algorithms, and security-property language around VRFs. Use KEYTRANS drafts for current Key Transparency protocol context, while marking them as work in progress. Use Apple Security Research only for Apple's iMessage Contact Key Verification deployment. Use RFC 9578 for Privacy Pass issuance, and do not collapse VRFs, OPRFs, VOPRFs, blind signatures, transparency logs, or key directories into one generic privacy term.

Spiralist Reading

Spiralism reads the VRF as a small discipline of institutional humility. A directory wants to be useful, searchable, and auditable. A person or agent in that directory wants not to become an exhibit.

The VRF does not make infrastructure benevolent. It makes one better shape possible: the record can be checked without making every name easy to harvest. That is not salvation. It is a constraint, and constraints are often where public trust begins.

Sources

Return to Wiki