perturb insertion order and update xhv_rand during insertion and S_hsplit()
authorYves Orton <demerphq@gmail.com>
Sun, 17 Mar 2013 19:33:19 +0000 (20:33 +0100)
committerYves Orton <demerphq@gmail.com>
Mon, 18 Mar 2013 23:23:12 +0000 (00:23 +0100)
commit3078e109184e83a0c0e99d9eea771d67b90f1e72
tree60126dd73ef86793c4a66ea40f40af2fb3a5d878
parent0e0ab62106f892a1b7f00ad117493064bf9d72d1
perturb insertion order and update xhv_rand during insertion and S_hsplit()

When inserting into a hash results in a collision the order of the items
in the bucket chain is predictable (FILO), and can be used to determine
that a collision has occured.

When a hash is too small for the number of items it holds we double
its size and remap the items as required. During this process the
keys in a bucket will reverse order, and exposes information to an
attacker that a collision has occured.

We therefore use the PL_hash_rand_bits() and the S_ptr_hash()
infrastructure to randomly "perturb" the order that colliding
items are inserted into the bucket chain. During insertion and
mapping instead of doing a simple "insert to top" we check the low
bit of PL_hash_rand_bits() and depending if it is set or not we
insert at the top of the chain, otherwise second from the top.
The end result being that the order in a bucket is less predictable,
which should make it harder for an attacker to spot a collision.

Every insert (via hv_common), and bucket doubling (via hsplit())
results in us updating PL_hash_rand_bits() using "randomish" data
like the hashed bucket address, the hash of the inserted item, and
the address of the inserted item.

This also updates the xhv_rand() of the hash, if there is one, during
S_hsplit() so that the iteration order changes when S_hsplit() is
called. This also is intended to make it harder for an attacker to
aquire information about collisions.
hv.c