> But I don't think that the hash function is the problem in that case. > In fact, there is no hash function that solves that problem, since the > attacker can always feed you data that ruins the hash function, unless > of course you want the function to differ from one machine to the next > and in effect be another secret.
I agree that such secret localization is the only chance you have against attacks on the hashes. It may even be doable. > I suggest instead that the hash lookup be limited to a small number of > probes. If not found in, say, 10 probes, act like it's not there and > the table is full. For each packet, there is exactly one hash chain to look up. So you end up limiting the _length_ of the single chain when creating new entries. To the user, that would mean random breakage long before saturation, for the sake of handling a hypothetical attack. Thus, you also need an "am I under attack" algorithm first, and enable that limiting behaviour only when that algorithm triggers. In practise, the denial of service attacks I've seen fill your slowest link, and there's nothing you can do about that except rate limit on the _other_ side. best regards Patrick
