Code change:
to the PA protocol: The helper handles each sub-request "PAAggregateSubReq" as follows. <del> It first checks that checks that "PAAggregateSubReq.proto == PAParam.proto".  If not, it aborts and alerts the leader with "incorrect protocol for sub-request".  Otherwise, it computes the HPKE context as where "sk" is its HPKE key and computes the body of the "PAAggregateSubResp".  It then updates its state according to the PA protocol.  After processing all of the sub-requests, the helper encrypts its updated state and constructs its response to the aggregate request. </del> <ins> It first looks up the HPKE config and corresponding secret key associated with "helper_share.config_id".  If not found, then the sub-response consists of an "unrecognized config" alert.  [TODO: We'll want to be more precise about what this means.  See issue#57.] Next, it attempts to decrypt the payload with the following procedure: where "sk" is the HPKE secret key.  If decryption fails, then the sub-response consists of a "decryption error" alert.  [See issue#57.] Otherwise, the helper handles the request for its plaintext input share "input_share" and updates its state as specified by the PA protocol. After processing all of the sub-requests, the helper encrypts its updated state and constructs its response to the aggregate request. </ins> 3.4.2.1.1.

Related discussion:
text: This behavior isn't accounted for in Definition 3.9, so when you try to "compile" this system into a ZKP on secret-shared data as described in Section 6.2 and consider its security with respect to Definition 6.4 (Setting I), you can no longer appeal to Theorem 6.6 to reason about its security. Our question is therefore: What impact do you expect this change to have on the soundness of the system? Can you think of an attack that exploits the fact that challenges can be replayed? My expectation is that the problem is merely theoretical, i.e., we ought to be able to close the gap with an appropriate refinement of Definition of 3.9 and reproving Theorem 5.3. [1] URL
Thanks for looping me in. In the discussion below, I am assuming that the client sends its data vector (called "x" in the paper [1]) at the same time as it sends its proof to the verifier. Even if the client sends its data vector in the first message, it seems that the client can reuse an (R,N) pair from upload request 1 to later submit upload request 2, in which case the client sees (R, N) before it chooses its data vector and proof. So I think we can assume that the client's data vector and proof can depend on the verifier's random value R. (I'll call this value "r" to match the paper.) For soundness: the client/prover must commit to its data vector before it learns the verifier's random value r. If the prover can choose its data value and proof in a way that depends on the verifier's randomness r, the soundness guarantee no longer holds. There is also an efficient attack. So I suspect that the stateless-verifier optimization is unsound. The attack works as follows: given r, the verifier finds a non-satisfying vector x such that sumi ri C(Ai(x)) = 0, again using the notation from Theorem 5.3 in the paper [1]. For the circuits C used in most applications, it will be easy to find such a vector x. Then, the prover constructs a proof that x that sumi ri C(Ai(x)) = 0.