Draft: draft-ppm-protocol

Commentary: Aggregators merely counting the number of input shares could compromise user privacy in some circumstances ( namely , it can break differential privacy if the number of records per user is not constant ) . This attack only applies to aggregators who can count the number of shares , so any protection still holds on the collector side . To address this attack , there are two possible mitigations , which both involve adding noise to the total number of input shares . This should be possible to do with " null " shares that do n't affect aggregate output ( i.e. inserting 0 into sums ) . 
 Specifically , this is about being able to count the number of contributions from an individual client , right ? If so , this would also be mitigated by putting an anonymizing proxy between clients and the leader which would scrub identifying information from reports . 
 An anonymizing proxy mitigates attacks but not in the worst case . I did n't mention in the PR ( I could if it is necessary ) , but the worst case attack involves the attackers having some side knowledge ( e.g. via client collusion ) such that if N reports arrive , then  did not contribute to this batch , and if  reports arrive , then  did contribute to the batch . This is related to the Sybil style attacks which do the same thing but with the value embedded in the report . In these kinds of attacks , no auxiliary information in the report ( like IP , etc ) is needed . In practice , I do n't believe this attack does much to meaningfully reduce user privacy . However , I think calling it out is important if we want to make differential privacy claims since DP requires us to think through worst - case attacks . 
 No this is not what I am talking about . This issue is not necessarily about attacks on , but rather about attacks on revealing to the helpers . In some settings , could be just as sensitive as . In your example you are using some local noise for each input ( just one possible way of implementing DP ) . I do n't think we would need this to protect . However , to protect we would only need to add false shares that truly sum to 0 ( i.e. no noise embedded in them at all ) . So that is hard to learn from the total # of input records . Great question . Let 's simplify this and say that you know for a fact that the true dataset contains either : records summing to , OR records summing to i.e. each record will always just have value 1 . Also let 's say that we 've properly hidden directly , and the adversary wants to learn from . I think it should be clear that if we can protect the true value of , we can protect the true value of as they are the same . True , will be close to N or N+1 , but the noise to the sum will be enough that both cases are reasonably probable , protecting both and . For example ( with Laplace noise with epsilon ln2 ) : ( ) - 
 Sharpening this a bit more : The concern is not whether the collector learns but whether the aggregators learn . The clients can add bogus reports to hide from the aggregators , or the leader can add bogus reports to hide from the helper . Is that right ? This would be a tad inconsistent with the current threat model , which assumes the collector may collude with an aggregator and , in particular , provide it with the final output . That said , I 'm fine with adding it as a security consideration . We just want to make it clear that it only appears to be achievable under stronger non - collusion assumptions . I see , thanks for clarifying . I think we need to be careful about what we mean when we say that the number of real ( i.e. , non - bogus ) inputs is " protected " . The output of the distributed aggregation function may be differentially private , but it does n't hide the number of real inputs . 
 Yes that 's right The collector colluding with an aggregator and providing the final output should be OK ( similarly , the aggregators providing the noisy count of raw records to the collector ) . In this case , the adversary has 2 views of the data ( noisy count and noisy output ) . You should still be able to prove DP protections in this case if each view is protected with DP ( this comes from the fact that DP composes well : ) . Yes , this is exactly the purpose of this PR . By default , we ca n't protect from the aggregators unless we add the bogus records . However , if we can directly hide the number of real records ( by adding bogus ones ) , and also _ ensure is DP , we can hide the true values of both and . 
 take another look . I 've tried to keep this short + sweet but let me know if you think it can be compressed further . 
 This should be ready to go 
 On the last design call ( 2021/08/04 ) we decided to split our work into two ( sets of ) documents : one for the " core " cryptographic protocols ( Prio , Hits , ... ) and another for the " wrapper " protocol ( basically the protocol bits we 've been working on so far ) . The next step is to specify the " interface " between these ( sets of ) documents . This is our goal for this issue . So far we 've been reasoning about this core - wrapper interface by analogy of HPKE and its applications ( ECH , OHTTP , etc . ) , which may indeed be an apt analogy , but it falls short of a precise definition . To that end , I 'd like to suggest that the interface needs to accomplish two things . ( 1 ) Specify the syntax of every PDA protocol . The syntax should cover : ( 1a ) generation of input shares from a measurement ; ( 1b ) the state machine of the leader and helper and how they respond to messages ( in the core protocol ) ; ( 1c ) accumulation of input shares into an output share ; and ( 1d ) combination of output shares into the output . ( 2 ) Specify the security requirements of every PDA protocol . This has three main components : ( 2a ) The expected communication model , which determines how much control over the network the adversary has . ( This may be different from the communication model of the wrapper protocol , as discussed below . ) ( 2b ) A baseline notion of privacy in the expected communication model that allows any number of clients and all but one aggregator to be corrupted . ( 2c ) A baseline notion of robustness in the expected communication that allows any number of corrupt clients to be corrupted , but requires all aggregators to be honest . Much of what we need is already worked out , but there are some gaps that require us to make some decisions . Two such gaps are discussed below . As observed in , we 've been considering attacks outside the formal model of either Prio or Hits ( specifically  and replay attacks ) . The communication model for the core protocol may therefore differ from ( i.e. , make stronger assumptions about the adversary than ) the communication model for the wrapper protocol . I would argue that this is perfectly reasonable . In fact , the main job of the wrapper protocol should be to " emulate " whatever communication model is expected by the core protocol . We are already well on our way here . The following mechanisms are used to provide properties that are implicit in the communication models of the papers : HPKE encryption creates a confidential channel between the client and each honest aggregator . The report 's timestamp and jitter fields define a total ordering on reports , which the aggregators can use to ensure each report is counted in at most one batch . Some bits are still missing , however : Who manages the report queue ? It seems simplest if the core protocol can assume in - order , non - repeated reports . The wrapper protocol can then do this enforcement . How are messages authenticated ? Currently , the adversary can impersonate the leader since leader - helper messages are not leader authenticated . This may lead to an attack on robustness . We should probably address this in the wrapper protocol such that the core protocol can assume these messages are authenticated . In Prio , the adversary learns nothing beyond the aggregate of the honest clients ' inputs . In contrast , in  , the adversary does n't just learn the heavy hitters ( HHs ) ; it may also learn the frequency of non - HH inputs that share a common prefix of a non - HH input with some HH . This leakage is inevitable because the aggregators learn each intermediate set of candidate prefixes at the start of each collect request . We 've observed that we can mitigate this leakage somewhat . Thus , one way to address this gap between Prio and Hits may be to require that each PDA protocol provide DP . This is probably too high a cost , however , given that not all PDA tasks need it . A simpler alternative might be to limit the syntax so that a single collect request is in scope . This seems natural , since a single round of  provides basically the same security properties as Prio . DP could still be , but this would merely augment whatever the baseline privacy goal aims to provide . 
 Left a couple of suggestions that I do n't think should block merging . let us know when you 've rebased or otherwise finished with this and we can merge it for you .
Paragraph (version B):
Aggregators can count the total number of input shares, which
could compromise user privacy (and differential privacy dp) if the
presence or absence of a share for a given user is sensitive.
Paragraph (version B):
Clients can ensure that aggregate counts are non-sensitive by
generating input independently of user behavior.  For example, a
client should periodically upload a report even if the event that
the task is tracking has not occurred, so that the absence of
reports cannot be distinguished from their presence.
Paragraph (version B):
Bogus inputs can be generated that encode "null" shares that do
not affect the aggregate output, but mask the total number of true
inputs.
Paragraph (version B):
Either leaders or clients can generate these inputs to mask the
total number from non-leader aggregators or all the
aggregators, respectively.
Paragraph (version B):
In either case, care must be taken to ensure that bogus inputs
are indistinguishable from true inputs (metadata, etc),
especially when constructing timestamps on reports.