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