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

[George Kadianakis <desnacked@xxxxxxxxxx>]

teor <teor2345@xxxxxxxxx> writes:

> Hi Jaskaran,
>
>> On 17 Mar 2017, at 23:42, Jaskaran Singh <jvsg1303@xxxxxxxxx> 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!
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev