Change:
"batch_interval" is the batch interval of the request. <ins> "report_count" is the number of reports included in the aggregation. "checksum" is the checksum computed over the set of client reports, computed as described above. </ins> "helper_state" is the helper's state, which is carried across requests from the leader. To respond to an AggregateShareReq message, the helper first looks up the PPM parameters associated with task "task_id".  Then, using the procedure in batch-parameter-validation, it ensures that the request <del> meets the requirements of the batch parameters.  If so, it aggregates all valid output shares that fall in the batch interval into an aggregate share.  The response contains an opaque, VDAF-specific message: </del> <ins> meets the requirements of the batch parameters.  It also computes a checksum based on its view of the output shares included in the batch window, and checks that the "report_count" and "checksum" included in the request match its computed values.  If so, it aggregates all valid output shares that fall in the batch interval into an aggregate share.  The response contains an opaque, VDAF-specific message: </ins> Next, the helper encrypts the aggregate share "agg_share" under the collector's public key as follows:

Discussion:
This is intended to allow PPM implementations to discover if the leader & helper(s) have fallen out-of-sync in their views of what shares are included in the aggregation. Notes: it would be trivial for an adversary to generate sets of nonces that collide with one another. Since the goal is to provide a check against server malfunction, rather than a security check against malicious clients or other actors in the system, I think this is acceptable. I evaluated a number of collision-resistant multiset-hash constructions[1], but none of them were currently standardized & specifying them would be more effort than seems necessary given the goals of this checksum.
The hash function wouldn't matter in that setting, as the attacker could generate a pool of a few hundred/thousand nonces and their hashes, fix one set of nonces, and use a system of equations over GF(2)^(digest length) to determine what the other set of nonces should be to match the checksum. Equivalently, they could start with generating a pool of nonces and hashes, treat them as vectors in GF(2)^(digest length), put them in a matrix, and find the kernel of that matrix. Pick two unique vectors that are in the kernel and have the same Hamming weight, then each entry determines whether the corresponding nonce from the pool should be included. These two vectors will give you two unique sets of nonces from the pool, such that they form two batches of the same size with the same checksum. Using a MAC would require sorting at some point, and would preclude accumulating the checksum as each prepare request comes in, like with LtHash or this XOR construction. Long term, we need to more rigorously handle ordering of prepare and collect interactions, gracefully handling communication failures and retries between the leader and helper, and agreement on reports to be collected, but I agree this is fine for now as an error heuristic.
I think any hash function would permit an attacker to create a collision. Treating the hash function as a random oracle, the attacker could try random nonces until they find hash values that produce a basis for (where is the output size of the hash in bits). I think this is expected to take right around hash computations if I remember my linear algebra correctly. Then they can use this basis to select a set of nonces producing any desired checksum value.

By repeating the process and finding a different basis, they can then produce a distinct set of nonces producing any desired checksum value. (I think this is similar to/the same as David's argument above.) Swapping out SHA256 for HMAC-SHA256 with the key kept secret by the aggregators would fix that particular issue since clients could no longer predict how a given nonce would contribute to the checksum; but as far as I'm aware there are no security proofs for this construction so there may be other attacks. The lack of collision-resistance may be acceptable for two reasons IMO: (a) there are other mechanisms in PPM to make sure the aggregators are aggregating the same set of client reports, this is intended as a check against server malfunction/distributed systems errors; (b) since we are currently implementing the client-uploads-to-leader-only model, clients can't provide different sets of nonces to different aggregators. I'm still not entirely happy with it, however. I added an OPEN ISSUE and I think we should revisit this later.
Collectors will want to know how many inputs are included in the aggregations they receive, for a number of reasons: they may wish to compute a mean over a privately aggregated sum, or track metrics on how many clients are providing inputs. struct should include a count of how many contributions went into an aggregation.
The linked PR only added a to the structure, which communicates it to the helper. I'm reopening this issue because the collector does not yet receive this information. In addition to the statistics-related motivation above, a recent PR to the VDAF spec, cfrg/draft-irtf-cfrg-vdaf, expects the number of reports to be available when unsharding.
This was completed in .
I agree that we don't care about a malicious aggregator here, but we do care about malicious clients. We need to think through what an attacker can do if it controls a subset of the clients and can disrupt the transmission of messages between the aggregators. Specifically, suppose the leader has computed the checksum and the helper has computed the checksum where and are distinct sets of nonces (i.e., they differ by at least one element). Suppose further that the attacker controls the values of the nonces. The attacker's goal is to choose the nonce sets so that .

Thus the question is what we need to assume about to ensure that this is hard. It's not clear to me that this amounts to a standard assumption about cryptographic hash functions like SHA256. We might be better off using a MAC here instead. That said, I think it would be best to keep this change as simple as possible. I would be OK with merging as-is, so long as we add a note about the attack above in an "OPEN ISSUE" in the text.LGTM at least provisionally.This would This LGTM, though I'm eager to hear what NAME thinks about using XORed SHA256 here.