Count unique IPs in an anonymous way

Currently, pyobfsproxy (and obfsproxy) keep a list of IPs (or IP hashes) in memory to count connected unique IPs.

Velope suggested that we should find a more privacy-preserving way of counting unique IPs, and he is right.

Aaron suggested to look into https://git.eff.org/?p=cryptolog.git and nick suggested to "use a bloom filter; count bits; get a probabilistic answer".

changed milestone to %Tor: unspecified

added component::archived/obfsproxy maybe-bad-idea milestone::Tor: unspecified needs-discussion priority::medium research severity::normal status::new term-project-ideas type::defect version::tor 0.2.7 labels

(Moving this to a better component and marking as researchy.)

Would be nice to have. Probably not easy to do; there are various papers on this topic in anonbib.

Trac:
Keywords: N/A deleted, research added
Component: pyobfsproxy to Obfsproxy
Priority: normal to minor

I met a grad student who has the most marvelous solution for this; I will share the details once I have permission. :)

Trac:
Milestone: N/A to Tor: 0.2.7.x-final

(We should use the approach in Tor too!)

Trac:
Summary: Obfsproxy: Count unique IPs in an anonymous way to Count unique IPs in an anonymous way
Component: Obfsproxy to Tor

Trac:
Status: new to assigned
Owner: asn to N/A

Marking some tickets as triaged-in for 0.2.7 based on early triage

Trac:
Keywords: N/A deleted, 027-triaged-1-in added

Trac:
Points: N/A to medium
Keywords: N/A deleted, SponsorR added
Version: N/A to Tor: 0.2.7
Priority: minor to normal

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.8.x-final

Bulk-replace SponsorR keyword with SponsorR sponsor field in Tor component.

Trac:
Sponsor: N/A to SponsorR
Keywords: SponsorR deleted, N/A added

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.???

Trac:
Keywords: 027-triaged-1-in deleted, N/A added

Trac:
Keywords: N/A deleted, 6s194 added

These tickets were tagged "6s194" as ideas for possible term projects for students in MIT subject 6.S194 spring 2016. I'm retagging with term-project-ideas, so that the students can use the 6s194 tag for tickets they're actually working on.

Trac:
Keywords: 6s194 deleted, term-project-ideas added

Move those from SponsorR to SponsorR-can.

Trac:
Sponsor: SponsorR to SponsorR-can

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Milestone: Tor: 0.3.??? to Tor: unspecified
Keywords: N/A deleted, tor-03-unspecified-201612 added

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

Trac:
Status: assigned to new

Trac:
Reviewer: N/A to N/A
Owner: N/A to asn
Sponsor: SponsorR-can to N/A
Severity: N/A to Normal
Component: Core Tor/Tor to Obfuscation/Obfsproxy
Points: medium to N/A

Other privacy-preserving collation mechanisms may wind up replacing this. I still think it's a fun idea.

Trac:
Keywords: term-project-ideas deleted, term-project-ideas maybe-bad-idea needs-discussion added

Looking into doing a research masters in network security, think I'm an idiot if i were to do something like this? Any suggestions?

Trac:
Username: enda_sexton

Replying to enda_sexton:

Looking into doing a research masters in network security, think I'm an idiot if i were to do something like this? Any suggestions?

Hello not sure if this fits a research project. Perhaps it does, but might be too much engineering and not too much research. Might be worth checking out tho.

FWIW, last time this topic was brought up people thought that using PCSA is the best approach: https://lists.torproject.org/pipermail/tor-dev/2017-March/012001.html https://lists.torproject.org/pipermail/tor-dev/2017-March/012073.html

Replying to asn:

Replying to enda_sexton:

Looking into doing a research masters in network security, think I'm an idiot if i were to do something like this? Any suggestions?

Hello not sure if this fits a research project. Perhaps it does, but might be too much engineering and not too much research. Might be worth checking out tho.

FWIW, last time this topic was brought up people thought that using PCSA is the best approach: https://lists.torproject.org/pipermail/tor-dev/2017-March/012001.html https://lists.torproject.org/pipermail/tor-dev/2017-March/012073.html

Thanks so much for the fast reply asn! Looking at this now.

Trac:
Username: enda_sexton

Trac:
Username: beastr0
Cc: N/A to beastr0@protonmail.com

asn does not need to own any obfuscation tickets any more. Default owners are trouble.

Trac:
Owner: asn to N/A
Status: new to assigned

tickets are unassigned, reverting to 'new'

Trac:
Status: assigned to new

mentioned in issue #15469 (moved)