[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 is
>> different from, 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, and 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 as the result prefix, but use it to determine 
whether we flip the 9th bit. And hash value of determines 
whether to flip the 10th bit, and so on. For your reference, the paper 
by Xu et. al. can be found at: 

>> (Or, try to anonymize 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.


More information about the Bro mailing list