Draft: draft-pda-core

Commentary: That seems fine .
Paragraph (version A):
This document describes an instantiation of Prio, a cryptosystem
system designed by Henry Corrigan-Gibbs and others [GB17, BGG+19]
that allows for privacy-preserving computation of statistics over
sensitive user data.  It works by distributing the computation over a
set of servers in such a way that, as long as at least one server
executes the protocol honestly, no input is ever seen in the clear.
Paragraph (version A):
The goal of this document is to specify a protocol for executing Prio
computations among a set of servers.  We begin in overview with an
overview of the protocol and a brief introduction cryptographic
techniques underlying Prio.  In the next section (security-
requirements) we enumerate the security goals and non-goals of our
protocol.  In section operational-requirements we list the use cases
our system needs to support, how it is configured, and any other
operational constraints for the protocol.  In protocol we specify the
protocol itself.
Paragraph (version B):
This document describes a framework for specifying protocols for
privacy-preserving data-aggregation.  Each protocol is executed by a
large set of clients and a small set of servers.  The servers' goal
is to compute some aggregate statistic over the clients' inputs
without learning the inputs themselves.  This is made possible by
distributing the computation among the servers in such a way that, as
long as at least one of them executes the protocol honestly, no input
is ever seen in the clear by any server.
Paragraph (version A):
The protocol is executed by a large set of clients and a small set of
servers.  We call the servers the _aggregators_. Each client's input
to the protocol is a set of measurements (e.g., counts of some user
behavior).  Given the input set of measurements x[1], ..., x[n] held
by n users, the goal is to compute y = F(x[1], ..., x[n]) for some
aggregation function F, while revealing nothing else about the
measurements.
Paragraph (version A):
Prio achieves this goal using additive secret sharing.  Rather than
send its input in the clear, each client "splits" its measurements
into a sequence of "shares" and sends a share to each of the
aggregators.  This secret-sharing procedure has two important
properties: first, it is impossible to deduce the measurement given
only a proper subset of the shares; and second, it allows the
aggregators to compute the final output by first adding up their
measurements shares locally, then combining the results to obtain the
final output.
Paragraph (version A):
Consider an illustrative example.  Suppose there are three clients
and two aggregators.  Each client i holds a single measurement in the
form of a positive integer x[i], and our goal is to compute the sum
of the measurements of all clients.  In this case, the protocol input
is a single measurement consisting of a single positive integer; no
additional encoding is done.  Given this input, the first client
splits its measurement x[1] with additive secret-sharing into a pair
of integers x[1,1] and x[1,2] for which x[1] = x[1,1] + x[1,2] modulo
a prime p.  (For convenience, we will omit the the "mod p" in the
rest of this section.)  It then uploads x[1,1] to one sever x[1,2] to
the other.  The second client splits its measurement x[2] into x[2,1]
and x[2,2], uploads them to the servers, and so on.
Paragraph (version A):
Now the first aggregator is in possession of shares x[1,1], x[2,1],
and x[3,1], and the second aggregator is in possession of shares
x[1,2], x[2,2], and x[3,2].  Each aggregator computes the sum of its
shares.  Let A[1] denote the first aggregator's share of the sum and
let A[2] denote the second aggregator's share of the sum.  In the
last step, aggregators combine their sum shares to obtain the final
output y = A[1] + A[2].  This is correct because modular addition is
commutative.  I.e.,
Paragraph (version B):
The protocol is executed by a large set of clients and a small set of
servers.  We call the servers the _aggregators_. Each client's input
to the protocol is a set of measurements (e.g., counts of some user
behavior).  Given the input set of measurements "x_1, ..., x_n" held
by "n" users, the goal of a _private aggregation (PA) protocol_ is to
compute "y = F(x_1, ..., x_n)" for some aggregation function "F"
while revealing nothing else about the measurements.
Paragraph (version B):
The main cryptographic tool used for achieving this privacy goal is
_additive secret sharing_. Rather than send its input in the clear,
each client splits its measurements into a sequence of _shares_ and
sends a share to each of the aggregators.  Additive secret sharing
has two important properties: - It's impossible to deduce the
measurement without knowing _all_ of the shares.  - It allows the
aggregators to compute the final output by first adding up their
measurements shares locally, then combining the results to obtain the
final output.
Paragraph (version B):
Consider an illustrative example.  Suppose there are three clients
and two aggregators.  Each client "i" holds a single measurement in
the form of a positive integer "x[i]", and our goal is to compute the
sum of the measurements of all clients.  In this case, the protocol
input is a single measurement consisting of a single positive
integer; no additional encoding is done.  Given this input, the first
client splits its measurement "x[1]" with additive secret-sharing
into a pair of integers "X[1,1]" and "X[1,2]" for which "x[1]" is
equal to "X[1,1] + X[1,2]" modulo a prime number "p".  (For
convenience, we will omit the mod "p" operator in the rest of this
section.)  It then uploads "X[1,1]" to one server "X[1,2]" to the
other.  The second client splits its measurement "x[2]" into "X[1,2]"
and "X[2,2]", uploads them to the servers, and so on.
Paragraph (version B):
Now the first aggregator is in possession of shares "X[1,1]",
"X[2,1]", and "X[3,1]" and the second aggregator is in possession of
shares "X[2,1]", "X[2,2]", and "X[2,3]".  Each aggregator computes
the sum of its shares; let "A[1]" denote the first aggregator's share
of the sum and let "A[2]" denote the second aggregator's share of the
sum.  In the last step, aggregators combine their sum shares to
obtain the final output "y = A[1] + A[2]".  This is correct because
modular addition is commutative.  I.e.,
Paragraph (version A):
A crucial task of any data collection pipeline is ensuring that the
input data is valid.  Going back to the example above, it's often
useful to assert that each measurement is in a certain range, e.g.,
[0, 2^k) for some k.  This straight-forward task is complicated in
Prio by the fact that the inputs are secret shared.  In particular, a
malicious client can corrupt the computation by submitting random
integers instead of a proper secret sharing of a valid input.
Paragraph (version A):
To solve this problem, Prio introduces a light-weight zero-knowledge
proof system designed to operate on secret shared data.  In addition
to its input share, each client sends to each aggregator a share of a
"proof" of the input's validity.  The aggregators use these proof
shares in a protocol designed to establish the input's validity,
without leaking the input itself.  We describe this input-validation
protocol in detail in .
Paragraph (version B):
An essential task of any data collection pipeline is ensuring that
the input data is "valid".  Going back to the example above, it's
often useful to assert that each measurement is in a certain range,
e.g., "[0, 2^k)" for some "k".  This straight-forward task is
complicated in our setting by the fact that the inputs are secret
shared.  In particular, a malicious client can corrupt the
computation by submitting random integers instead of a proper secret
sharing of a valid input.
Paragraph (version B):
To solve this problem, in each PA protocol, the client generates a
zero-knowledge proof of its input's validity that the aggregators use
to verify that their shares correspond to as valid input.  The
verification procedure is designed to ensure that the aggregators
learn nothing about the input beyond its validity.
Paragraph (version B):
After encoding its measurements as an input to the PA protocol, the
client generates a _proof_ of the input's validity.  It then splits
the proof into shares and sends a share of both the proof and input
to each aggregator.  The aggregators use their shares of the proof to
decide if their input shares correspond to a valid input.
Paragraph (version A):
The client uses the statistic to be computed in order to know how to
encode the measurement.  For instance, if the statistic is mean, then
the measurement can be encoded directly.  However, if the statistic
is standard deviation, then the client must send both x and x^2.
Section [TODO: cite to internal description of how to encode]
describes how to encode measurements for each statistic.  The client
uses the validity rules to construct the zero knowledge proof showing
that the encoded measurement is valid.
Paragraph (version A):
At a high level, the flow of data from clients to the data-collection
endpoint is as follows.
Paragraph (version A):
Note: Two non-colluding aggregators -- one leader and one standard
aggregator -- are required to provide protect the inputs' privacy.
Additional aggregators may be used to make the system more resilient;
see .
Paragraph (version B):
Each PA task in this document is divided into three sub-protocols as
follows.