lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 8 Jul 2011 22:34:22 +0200 From: Michał Mirosław <mirqus@...il.com> To: David Miller <davem@...emloft.net> Cc: roland@...estorage.com, johnwheffner@...il.com, mj@....cz, netdev@...r.kernel.org Subject: Re: ipv4: Simplify ARP hash function. W dniu 8 lipca 2011 22:10 użytkownik Michał Mirosław <mirqus@...il.com> napisał: > 2011/7/8 David Miller <davem@...emloft.net>: >> From: David Miller <davem@...emloft.net> >> Date: Fri, 08 Jul 2011 12:51:18 -0700 (PDT) >> >>> From: Michał Mirosław <mirqus@...il.com> >>> Date: Fri, 8 Jul 2011 21:39:18 +0200 >>> >>>> With b[3] = b[0] ^ b[1] ^ b[2] you get 2^24 keys that hash to the same bucket. >>> >>> Ok, I'm convinced, thanks :-) >> >> Although, actually it's not this simple. The attack doesn't work. >> >> As they "attack" us, the ARP hash table grows and thus the hash mask >> changes to match. Then his old collisions won't collide any more. >> >> We could even adjust the fold shifts as the table grows to make this >> effect even more pronounced. > > There will still be 2^32/n_buckets known values that hash to the same > bucket for every n_buckets. So if the attacker knows when and how the > hash size changes, he can adapt accordingly. It should be easier to > see when you get rid of the XOR [random, but] constant part. BTW, am I correct, that neighbour hash tables never shrink? Looking at net/core/neighbour.c it seems that after the table reaches gc_thresh3 capacity, it is never reallocated again. Best Regards, Michał Mirosław -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists