| Hello, I won’t be able to be at this meeting, but I would like to make some comments: 1. Prio’s zero-knowledge proofs (i.e. SNIPs) are not secure against a single malicious server. If you are using them the decide whether or not to include a given input, then a malicious server can cause good inputs to be excluded or bad inputs to be included. This could be used to exclude all good inputs except for one target one or to repeatedly exclude-then-include the input of a target party over a sequence of meaurement periods to see how much it tends to affect the aggregate. The SNIP protocols can no doubt be upgraded to provide security against malicious servers, but as of yet no such protocol has been published, implemented, or evaluated. 2. A main application for using client-provided zero-knowledge proofs is to allow Boolean inputs to be added. A client's proof would guarantee that a given input is 0 or 1, despite the input being secret-shared using shares in a larger field (say, 32-bit values) and thus impossible to otherwise learn anything about its value. The server then could add up the inputs to determine how many clients had the Boolean flag set. This may well be useful for inputs from clients directly, which is the Mozilla case. In Tor’s case, there is no plan to have clients submit statistics themselves (e.g. from Tor Browser), because it raises obvious privacy/PR concerns (I believe these could be mitigated, but that discussion has yet to even seriously start as far as I can tell). In the Tor case, the inputs are coming from relays. To the extent that relays are reporting on client activity, the Boolean input case seems less useful, as the relays should really be reporting the total amount activity they saw instead of just if they saw something ever happen. I could imagine, however, that figuring out how many relays saw some weird event (like an error, or evidence of some attack) happen might be useful. Other than Boolean inputs, I’m not sure what we would want to be proved about the inputs. Of the examples in the Prio paper (Sec. 5.2), only frequency count and variance seem to use client proofs. Frequency count is the Boolean case I discussed. I’m not sure what would justify gathering the variance of the per-relay values. 3. PrivCount is compatible with Prio’s Affine Function Encodings, as such encodings compute aggregates simply by adding inputs. My overall opinion about Prio is that could be very useful to collect per-client statistics, such as from Tor Browser, but that doing so would require an upgraded version secure against malicious servers. Best, Aaron
|
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev