[Bro] Re: Bug on Anon.cc

Ruoming Pang rpang at cs.princeton.edu
Sun Sep 11 08:12:27 PDT 2005


> Ruoming Pang wrote:
>>> (b) it did the hash of an 8-byte
>>> struct composed of the prefix length and the input, instead of the
>>> prefix of the input (4 bytes).
>> I think this is not correct. For example, prefix 10.0.0.0/8 is
>> different from 10.0.0.0/9, and should be hashed differently; otherwise
> If you add the prefix length, then you have a "fixed-prefix length
> anonymizer." By this, I mean an anonymizer for each /X class. It's
> equivalent to have a hash key for /4 addresses, and another for /5
> addresses. This scheme only preserves prefixes when the /X suffix is
> the same. For example, 10.0.0.0/8 and 10.0.0.0/9 will not have the
> same prefix. Is this what the function is supposed to do?

I see. There is some misunderstanding here. We do not take the hash 
value of 10.0.0.0/8 as the result prefix, but use it to determine 
whether we flip the 9th bit. And hash value of 10.0.0.0/9 determines 
whether to flip the 10th bit, and so on. For your reference, the paper 
by Xu et. al. can be found at: 
http://www.imconf.net/imw-2001/imw2001-papers/69.ps.gz.

>> (Or, try to anonymize 128.0.0.0 with 1000 different keys, and see
>> how many distinct results one can get.)
> That's an artifact of the padding being 0...0. The f_0 function is
> a constant dependent on the hash key, so x'_0 is random. x'_1 to
> x'_{31} are all the same, as PAD(x_0) = PAD(x_0 x_1) = ... =
> PAD(x_0 ... x_{31}).

By the way, the PAD function in the paper does include the prefix 
length, instead of padding with only 0.

Ruoming




More information about the Bro mailing list