[Bro] Re: Bug on Anon.cc

Jose M. Gonzalez chema at cs.berkeley.edu
Sat Sep 10 21:06:46 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? 

With this scheme, you may also have collisions. It may be the case 
that hashes to, and that hashes 
to The hashed addresses share a 16-bit prefix, while 
the input addresses share no prefix. 

BTW, if this is the case, for the code to work, you cannot change 
prefix.len during the "for" loop in AnonymizeIPAddr_PrefixMD5::anonymize().

> the 9th and 10th most significant bits will always be flipped the same 
> way. (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}). 

Therefore, you can get,,, and 


More information about the Bro mailing list