Opened 21 months ago

Closed 14 months ago

Last modified 9 months ago

#22955 closed task (implemented)

Specify how PrivCount will work with Tor

Reported by: teor Owned by: nickm
Priority: Medium Milestone: Tor: 0.3.3.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: privcount, prop280, TorCoreTeam201711.1
Cc: robgjansen, amj703 Actual Points:
Parent ID: Points:
Reviewer: Sponsor: SponsorQ-can


PrivCount is an experimental statistics collection protocol, which provides secure aggregation of a differentially private set of statistics.

We need to work out which parts of the experimental protocol are useful, and how they could work on tor relays, and provide results to Tor metrics.

Child Tickets

#22897closedRevise privcount patch series to use trace modulesCore Tor/Tor

Change History (9)

comment:1 Changed 19 months ago by nickm

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final

comment:2 Changed 17 months ago by nickm

Cc: teor robgjansen amj703 added
Keywords: prop280 added
Owner: set to nickm
Status: newaccepted

I started some work here as prop280, and gotten some feedback. Carolin Zöbelein has also written some outlines for a Shamir-based protocol. I've taken a shot at a variation of a Shamir-based protocol at , where it appears as a python prototype.

Current open question: does Shamir-style secret sharing actually do anything to help with the case where some Data Collectors are misbehaving? So far as I can tell, it only really helps us handle malfunctioning Tally Reporters.

comment:3 Changed 17 months ago by nickm

Keywords: TorCoreTeam201711.1 added

comment:4 Changed 17 months ago by nickm

I've put a draft proposal in the doc directory of ; I'll send it to tor-dev next week, but I think teor wanted to add some stuff first.

comment:5 Changed 17 months ago by cypherpunks

Privcount is not going to be acceptable.

comment:6 Changed 17 months ago by amj703

An answer to Nick's question: secret sharing only helps deal with failures of Tally Reporters. Handling failures (i.e. crashes/dropouts) of DCs can be done simply by having the TRs agree on all the DCs they have data from before adding their individual shares from those DCs. Handling malicious inputs can be mitigated somewhat by choosing multiple different DC subsets, aggregating each one, and taking the median of the resulting values.

Also, I would be interested to hear cypherpunks' concerns in more detail.

comment:7 Changed 14 months ago by nickm

Resolution: implemented
Status: acceptedclosed

comment:8 Changed 14 months ago by teor

I opened #25153 for follow-up: "Specify how PrivCount in Tor statistics are configured and interpreted"

comment:9 Changed 9 months ago by teor

Cc: teor removed

Remove useless CC

Note: See TracTickets for help on using tickets.