[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