[tor-dev] Proposal xyz : Count Unique IP addresses in an anonymous way

George Kadianakis desnacked at riseup.net
Tue Mar 21 11:08:51 UTC 2017

teor <teor2345 at gmail.com> writes:

> Hi Jaskaran,
>> On 17 Mar 2017, at 23:42, Jaskaran Singh <jvsg1303 at gmail.com> wrote:
>> ยง2. Research
>> There are three ways to solve this problem. All the three ways are
>> actually Big Data
>> Algorithms. A few problems arises for each of these algorithms since
>> they are made for
>> big data but the data we would provide is not necessarily big.
> As we discussed on IRC, there's a simpler way to solve the problem of
> storing IP addresses in memory: store a (keyed) hash of the IP address
> instead.
> The hash can be tuned to be sufficiently hard to make brute-forcing
> impractical. (As long as each 'country' has sufficiently many IP
> addresses. And as long as the threat model excludes adversaries which
> only want to confirm a few addresses.)

Hey teor,

I feel like replying to this thread is basicaly moot without a precise
threat model, since it seems like each person here has a different
threat model in mind. There are many attacks and scenarios applicable
and it's unclear which ones we are trying or hoping to cover.

For example, I'm confused on how a keyed hash is better than a simple
hash (or scrypt) of the IP address (which most people agree is not a
good solution). That is, if an attacker pwns a box and steals the hash
key and the list of hashes, the attacker can easily brute-force the 2^32
keyed hashes at that point and derive the list of connected IP
addresses. What's the difference?

> The key can be rotated at a suitable interval, ensuring that past
> addresses can not be discovered by future attackers.

Hmm, is this attack in the threat model? And how does it work exactly?

Also how does salted hash vs normal hash make a difference here, since
even in the normal hash variant, if you memwipe/rotate the hash list
everyday, an attacker should not be able to discover past addresses.

All in all, I think it will be hard to choose a scheme here without a
precise threat model, and I don't see the original proposal making an
attempt to define that.

Greetings from Amsterdam!

More information about the tor-dev mailing list