Opened 2 years ago

Closed 19 months ago

Last modified 14 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

Description

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

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

Change History (9)

comment:1 Changed 2 years ago by nickm

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

comment:2 Changed 22 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 https://github.com/nmathewson/privcount_shamir , 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 22 months ago by nickm

Keywords: TorCoreTeam201711.1 added

comment:4 Changed 22 months ago by nickm

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

comment:5 Changed 22 months ago by cypherpunks

Privcount is not going to be acceptable.

comment:6 Changed 21 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 19 months ago by nickm

Resolution: implemented
Status: acceptedclosed

comment:8 Changed 19 months ago by teor

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

comment:9 Changed 14 months ago by teor

Cc: teor removed

Remove useless CC

Note: See TracTickets for help on using tickets.