[Bro] Re: Bug on Anon.cc

Ruoming Pang rpang at cs.princeton.edu
Sun Sep 11 19:15:54 PDT 2005


> You're right: the padding requires adding the $i$ value (the prefix
> length). That's actually what makes 128.0.0.0 hash to something
> different than 4 possible values.

I'm glad that now we agree upon this.

> Still, you have to get rid of all the bits after the prefix you're
> currently hashing.

Yes, that's another bug in my old code, which, apparently, wasn't well 
tested. :-(

> Moreover, the padding also includes a 1 before the
> zeros (the padding is the same than in RFC 1321. I wonder which is
> the reason for adding a 1. Anyway, I'd respect it).

That is fine.

> The code would be now OK. A minor quirk: the way the old code uses $i$
> is different from the way the paper uses $i$ (they are related as
> $i_{paper} = 31 - i_{old_code}$). I changed the old code so that $i$
> is now the same than in the paper. Patch is enclosed.

That's fine, too.

However, there's another minor tweak we need to make (I learned that in 
writing and testing the same anonymization function in the TCPMKPUB 
code). The byte-by-byte value of struct prefix currently depends on 
byte order of the machine. In order for Bro to produce the same results 
for both byte orders, we have to put the 32 bit values back to network 
order when assigning the struct prefix.

Thanks for looking into the code and finding the bugs!

Ruoming




More information about the Bro mailing list