[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 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?
With this scheme, you may also have collisions. It may be the case
that 0.0.0.0/24 hashes to 4.4.4.0/24, and that 255.255.0.0/16 hashes
to 4.4.0.0/16. 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 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}).
Therefore, you can get 0.0.0.0, 128.0.0.0, 127.255.255.255, and
255.255.255.255.
-Chema
More information about the Bro
mailing list