Patrick Schaaf writes:
> > You can now use '-c NUMBER' to set a seed for the CRC32 hash. You can now
> > use '-C' (without parameter) to set a random seed for the CRC32 hash.
> > These options are for testing the idea of "attack compensation by
> > inserting local variance". I'd like to hear opinions on this.
> At a higher level, though, I don't see much value in preventing an
> attacker from filling a single bucket when he can almost as easily do
> much more harm by filling the entire conntrack database!
On the other hand, if we do have a way to prevent an attacker from
filling the conntrack database, this does become interesting again.
Assuming, of course, the attacker can't skew the crc hash results by
feeding you particular data without knowing your seed. I still hope
to hear from some experts out there on this subject.
And now, since I think this is a useful approach it's worth while to
mention the following:
static u32 hash_crc32(struct ct_key *key)
{
u32 crc = crc32_seed;
u32 v32;
u16 v16;
crc = crc32(crc, (const char *) &key->proto, sizeof(key->proto));
v32 = ntohl(key->sip);
crc = crc32(crc, (const char *) &v32, sizeof(v32));
v32 = ntohl(key->dip);
crc = crc32(crc, (const char *) &v32, sizeof(v32));
v16 = ntohs(key->sport);
crc = crc32(crc, (const char *) &v16, sizeof(v16));
v16 = ntohs(key->dport);
crc = crc32(crc, (const char *) &v16, sizeof(v16));
return crc;
}
Isn't that the same (modulo order of data) as this?
return crc32(crc, (const char *) key, sizeof(struct ct_key));
On my 200MHz machine
your crc my change hash_conntrack
1.5usec 1.1usec .2usec gcc -o cttest cttest.c
1.1usec .53usec .14usec gcc -O9 -o cttest cttest.c
