VERIFIABLE RANDOM FUNCTIONS
How one secret key produces a unique, random-looking output that anyone can check.
A keyed hash lets the holder of a secret key compute a pseudorandom output. Other parties cannot verify that output without learning the same key.
A verifiable random function adds a proof. The secret-key holder evaluates the function on an input and produces an output with evidence. Anyone holding the public key can verify that the output is the unique result for that input.
This combines unpredictability before evaluation with public verifiability afterward. It does not create an unbiased public random beacon by itself.
A public-key version of a keyed hash
For a fixed VRF key and input, evaluation produces one defined output. Only the private-key holder can compute it efficiently, while the proof lets verifiers confirm correctness.
The output should look pseudorandom to a party that has not obtained an evaluation for that input. Uniqueness prevents the key holder from presenting two different valid outputs under the same key and input.
Those properties make VRFs useful where a service must commit to a hidden mapping and later prove individual results.
Proof and output have different roles
Evaluation first produces a proof. A proof-to-hash operation derives the VRF output from a valid proof. Verification checks the proof against the public key and input, then obtains the same output.
Applications should not treat arbitrary proof bytes as the random result. Proof encodings can contain structure or admit format changes across suites, while the specified output extraction provides the intended pseudorandom value.
Both proof and output need suite and key context when stored.
The input must be canonical
A VRF is deterministic. Different byte strings are different inputs even if an application considers them the same name, account or event.
Unicode normalization, case handling, version numbers, tenant identifiers and length prefixes should be resolved before evaluation. Otherwise one logical label can occupy several VRF positions.
Domain separation prevents an output used for a directory label from being reused as a lottery value or protocol nonce under the same key.
Hash to curve is inside the security boundary
Elliptic-curve VRF suites map the input into a curve point, apply the secret scalar and prove the relationship. Correct hash-to-curve behaviour, point decoding and subgroup validation are essential.
RFC 9381 defines complete ciphersuites rather than inviting implementations to assemble a curve, hash and encoding independently.
Supporting the same named curve used for signatures does not imply that a secure element supports the VRF’s hash-to-curve and proof operations.
A VRF can hide map positions
In key transparency, a directory can evaluate a VRF over an account label and use the output as a pseudorandom location in a searchable tree. A client receives a proof that the location was derived correctly.
An observer of the tree cannot enumerate obvious labels by hashing likely email addresses, because it lacks the VRF private key.
The directory operator still sees queries and holds the evaluation key. The construction limits public enumeration; it does not make the label unknown to the service.
Stable outputs can be linkable
The unique output for one key and input is stable. Anyone who sees it twice can recognize equality.
This is useful for deterministic indexing and harmful when independent contexts should not be correlated. Separate keys or domain-separated inputs can create scoped mappings.
Rotating the key changes every output, which improves epoch separation but requires migration of any structure indexed by previous outputs.
Verifiable does not mean unbiased
If a party can choose among many inputs, keys or publication times, it may evaluate alternatives and reveal only the favorable result. Every revealed output can verify correctly while the selection process remains biased.
A lottery can prevent this by fixing the public key and input before the outcome is knowable, perhaps using an externally committed event value. A distributed random beacon can reduce trust in one key holder.
The VRF proves correct evaluation of the chosen input. It does not prove that the input was chosen fairly.
Unpredictability has a time boundary
Before evaluation is released, outsiders should not predict the output. After the proof is published, everyone can compute or verify it.
If the private key is later compromised, an attacker can evaluate past and future inputs. Forward unpredictability requires key evolution or deletion that a basic VRF does not provide.
Applications should specify when an input becomes fixed, when evaluation is permitted and what key compromise reveals.
The key holder can deny service
A VRF prevents the holder from producing two valid outputs for one input. It cannot force the holder to produce any output.
Selective refusal can bias protocols that wait for an evaluation or make directory entries unavailable. Replication of the private key improves availability but enlarges the trust boundary.
Threshold VRFs can distribute this role, at the cost of another multi-party protocol.
Side channels target the secret scalar
VRF evaluation uses the long-lived secret key in curve operations influenced by attacker-chosen inputs. Implementations should be constant-time and validate inputs before secret-dependent computation.
A service exposed as a VRF oracle also needs rate limits and separation between authorized application domains. Public verifiability does not imply unrestricted evaluation access.
A VRF is not a signature
Both constructions use a private key and public verification, but their outputs have different meanings. A signature authenticates a message and is generally randomized or deterministic without promising a pseudorandom unique value. A VRF proves one deterministic function output.
Using a signature hash as a lottery value can permit multiple valid signatures, encoding choices or randomized retries. Using a VRF proof as general message authentication ignores signature semantics and ecosystem support.
Verifiable randomness with defined control
A VRF gives a key holder controlled evaluation and gives every verifier a common answer. That is useful for hidden directory positions, deterministic selection and public audit.
The application must still fix the key, input, domain and publication rules. It must account for grinding, refusal, rotation and compromise.
A random-looking output can carry a proof. The proof establishes its origin and uniqueness, not the fairness of the process that chose to reveal it.
