PRIVATE AGGREGATION
How VDAFs verify contributions without reconstructing each report.
Many measurements are useful only in aggregate. A service may need the number of clients experiencing a failure, the sum of selected values or a histogram of software versions. Collecting every individual report in clear form obtains that result by first creating a more sensitive dataset than the result requires.
Verifiable Distributed Aggregation Functions take a different route. Each client encodes and splits its measurement among several aggregators. The aggregators verify that the hidden contribution is well formed and combine their shares. Only the aggregate is reconstructed.
The cryptography protects individual reports. The surrounding protocol determines whether they remain private, count once and represent anything true.
The client never sends one complete report
A VDAF client produces an input share for each aggregator. No single share reveals the underlying measurement. Each aggregator receives its share through an authenticated and encrypted channel and processes it as part of a task.
At aggregation time, compatible output shares can be combined into the desired statistic. The collector learns the aggregate result, not a list of plaintext inputs.
This is stronger than encrypting reports to one central service. There is no moment at which that service needs to decrypt every individual value before computing the sum.
Non-collusion is the central assumption
Privacy depends on at least one aggregator not colluding with the others. If all input shares for a report are combined outside the protocol, its measurement can be reconstructed.
Organizational separation therefore matters. Two aggregator processes operated by one administrator in one account may satisfy the message flow while providing little independent protection.
A deployment should state who operates each aggregator, which logs and backups they share, how legal access is handled and whether software updates can compromise them simultaneously.
Verifiability prevents malformed inputs, not false observations
Secret sharing alone lets a malicious client submit values that corrupt the aggregate. A client asked for a bit might encode a large field element instead. Enough such inputs could dominate the result.
A VDAF preparation phase lets aggregators jointly verify that the hidden measurement belongs to the permitted input domain without revealing it. Prio-style constructions prove arithmetic validity over shares.
This establishes that the report is structurally admissible. It does not establish that the client measured reality honestly. A valid report can still contain a fabricated but in-range value.
The measurement function is a cryptographic interface
Count, sum, vector sum and histogram-like tasks have different input-validity requirements. The VDAF must encode those requirements into its circuit or arithmetic checks.
A sum over values from zero to one thousand needs a range proof or bounded construction. A one-hot vector needs to prove that exactly one position is selected. A mean requires a count as well as a sum.
The application specification should identify the measurement type, bounds, field, aggregation parameter and result interpretation. Otherwise two conforming cryptographic implementations can compute different statistics.
DAP coordinates the distributed computation
The Distributed Aggregation Protocol supplies the network workflow around VDAFs. It defines tasks, report submission, preparation exchanges, batching, collection and error handling.
This separation is useful. The VDAF defines the mathematical transformation. DAP defines how parties transport and sequence it.
It also means security properties cross the boundary. Report identifiers, task identifiers, aggregation jobs and batch selection influence replay protection and privacy even though they are not part of the measurement arithmetic.
A private report must also count once
An attacker can try to submit the same report repeatedly or make aggregators process inconsistent copies. Duplicate detection needs stable report identity within a task without creating an identifier that links a client across unrelated tasks.
Aggregators must agree on which reports belong to an aggregation job and reject replays according to the protocol. Retries after uncertain failures require care: a client should not create multiple valid contributions merely because it did not receive an acknowledgment.
Exactly-once semantics remain difficult in distributed systems. Privacy does not remove that difficulty.
Batch size is a privacy parameter
An aggregate over one report reveals that report. Small batches, narrow time windows and differencing between overlapping queries can recover individual contributions even when the cryptography is flawless.
The collector’s query interface therefore needs minimum batch sizes, controlled windows and limits on repeated or overlapping collections. Withholding a result can be as important as protecting an input share.
Cryptographic aggregation limits who sees raw reports. Statistical disclosure control limits what can be inferred from permitted results.
Differential privacy is separate
VDAFs do not automatically add noise. They can compute an exact aggregate while keeping each input distributed.
Differential privacy addresses a different question: how much the published output changes when one person’s contribution is added or removed. It generally requires calibrated noise and a privacy budget.
The two techniques can be combined, but their trust assumptions need to be explicit. If one party chooses all noise, it may remove it. Distributed noise generation can reduce that trust at the cost of another protocol.
Metadata remains visible
Aggregators can observe report timing, network origin, task selection and message size unless the transport hides them. A rare task submitted at a distinctive time may be identifying even when its numeric value remains secret.
Batching, relays and traffic shaping can reduce some metadata. None follows automatically from secret sharing.
A complete privacy statement should distinguish hidden measurement content from visible submission metadata.
Malicious aggregators can attack availability
An aggregator that cannot learn an individual input may still drop it, delay a job, return an invalid preparation message or refuse collection. Robustness and accountability are separate from confidentiality.
Signed protocol messages and reproducible job identifiers can help diagnose disagreement, but public evidence must not expose report shares. Operators need failure records that show which stage failed without becoming a side channel.
Private telemetry with a narrow purpose
The strongest use cases start with a sharply defined aggregate. Examples include counting exposure events, measuring protocol deployment, collecting browser metrics or obtaining bounded sums for public statistics.
If analysts later want arbitrary joins, drill-down and per-user histories, the architecture will resist them by design. That resistance is not a limitation to remove. It is the privacy property.
A VDAF system should collect enough structure to answer the declared question and no hidden reserve of individual data for future questions.
The aggregate is not the ground truth
Private aggregation can prove that accepted reports were well formed and combined according to a specified function. It cannot prove that clients were honest, representative or unique people.
As with a ledger that preserves claims without making them true, cryptography protects a relationship between inputs and output. Measurement validity, sampling bias and device integrity remain outside that relationship.
The important achievement is narrower and substantial: useful population-level information can be computed without first centralizing every individual’s contribution.
