wiki:org/meetings/2019BrusselsNetworkTeam/Notes/privcount

PrivCount presentation


+ Current system: Currently relays send stats to dirauths

++ Various statistics can cause issues and leaks: Bridge country stats, bandwidth statistics

+ Privcount system: In Privcount relays send encrypted noisy statistics to "tally reporters".

++ "Tally reporters" talk amongst themselves in an encrypted way to aggregate statistics from all relays

++ "Tally reporters" come up with a single (rounded) "network total", instead of a per-relay total

++ "Tally reporters" feed the final data into "metrics collectors".

++ "Tally reporters" are not relays; they are extra servers that are run by people (maybe relay operators, or externals).

++ "Tally reporters" produce a signed statement with the network totals, and a public API that collectors can use, like currently with dirauths.

++ Relays use Shamir Secret Sharing (SSS) to encrypt stuff into N shares that are then sent to tally reporters, and then k tally reporters are needed to decrypt that data (e.g. N=5, k=3).

++ "Tally reporter" threat model: If we are not doing SSS, we require all tally reporters to be honest to get accurate totals. If we are doing SSS,

++ There will be a period of time each day where relays submit their statistics to the system.

+ Detecting bad statistics:

++ Relays can still send fake statistics in privcount.

++ Issues: A relay might submit one share, but not be able to submit the other shares to the tally reporters (TR).

++ Solution: There needs to be a way for TRs to do _consistency check_ with each other to communicate which relays have submitted to them, and that shares are good.

For consistency check, two check counters (0 and 1) are used. The latter counter is used to count the number of relays, whereas the former is used as a sanity check to make sure that adding many zero counters together still returns zero. There is also a "noise counter" to make sure that all relays are adding noise. All these counters are used to find honest mistakes.

++ Issues: Relays can report bad statistics

++ Solution: We can split relays into partitions. And use the small partition to tell us that the results of the big partition are about correct. Shared Random Value of v3s could be used to make sure that relays cannot cheat by replaying stuff or pretending to be in other partitions.

+ What can we collect?

++ Counters are numbers between -262 and 262.

++ Using these counters we can collect bandwidth, onion services traffic (cells).

++ You can split an event into categories and you dont need to add that much noise.

+++ e.g. for bandwidth there are 4 categories: Guard, Exit, Guard&Exit, Middle you can have a counter split into these 4 categories and add noise only once.

++ All of the observations need to be something that you can add against a running total. Also, you need to add stuff against the total network totals: you can do means, but you can't do medians.

++ It's really hard to collect stuff like "number of unique onion addresses", but we can estimate it similarly we how we currently do it.

+++ Perhaps we can do it with something like HyperLogLog.

+ Open questions/Challenges:

++ The current system is really easy to debug because everything is public and everywhere. Privcount is much harder to debug because stuff is encrypted and hidden.

+++ We can dump check counters etc. in the extrainfo descriptors for debugging purposes, and to make sure that results are equivalent to the current system.

++ When doing G/E/G&E/M statistics, does the relay pick the counter to add, or does the tally reporter pick it? (counter vs complex aggregation)

++ Which consistency checks do we need?

++ Per-subset or whole-network relay result checks?

++ Open questions on core structure and how we should structure the privcount library and how much we need to mod tor.

++ Metrics has open questions on how we get from the results to graphs..

++ Configuration and how to incrementally add new stats.

Last modified 3 months ago Last modified on Jan 31, 2019, 9:29:29 AM