3.3.8 · D4Hashing

Exercises — Universal hashing — probabilistic guarantee

3,300 words15 min readBack to topic

Reminder of the tools we lean on (all built in the parent note):


Level 1 — Recognition

L1·Q1 — Spot the universal family

Which of these families is universal, and which merely feels safe?

  • (a) , a single fixed function chosen once by the library author.
  • (b) The family with random .
Recall Solution

(b) is universal. A family must contain many functions so we can pick one by coin flip; (a) has exactly one function, so is either or — there is no randomness to average over. An adversary who reads the source code of (a) hands you colliding keys and wins. (b) ranges over different functions; the parent note proves (exactly when ). ✔ universal.

L1·Q2 — Read the definition literally

True or false: "Universal hashing assumes the input keys are random."

Recall Solution

False. The randomness lives entirely in the choice of . The keys are fixed and arbitrary — even adversarial. The probability is taken over , written . Mantra: RANDOM the FUNCTION, never the DATA.

L1·Q3 — Which quantity is the load factor?

A table has slots holding keys. What is ?

Recall Solution

It is the average number of keys per slot. See the bucket picture below — is just "how tall, on average, is each stack".

The figure below shows 6 slots holding 8 keys. What to observe: the individual stacks are uneven (slot 2 is empty, slot 3 holds three keys), yet the pink dashed line — the average height — sits at . That dashed line is : universal hashing controls the average stack, never promising every stack is equal. Carry that mental image into every expected-cost problem below.

Figure — Universal hashing — probabilistic guarantee

Level 2 — Application

L2·Q1 — Compute a hash

With , , , , compute for .

Recall Solution
  • (WHY: apply the linear map first.)
  • (WHY: mod — this is the universality engine.)
  • (WHY: squeeze into .) So . (Note , so every slot is reachable — no wasted buckets.)

The figure traces this as a pipeline of four boxes. What to observe: the arrows are one-directional — you can never skip a box or swap the order. Notice the labels under the arrows: "mod p first!" sits before "into [0,m)". This is the visual antidote to the L2 trap below; the whole reason the family is universal is that the blue box (mod ) happens strictly before the pink box (mod ).

Figure — Universal hashing — probabilistic guarantee

L2·Q2 — Expected chain length

Universal hashing, slots, keys already inserted. A new key (not yet in the table) arrives. Bound the expected number of keys already sitting in 's slot, and the expected search cost.

Recall Solution

Recall the collision indicator from the top of the page: exactly when the existing key lands in the same slot as , else . The number of keys sharing 's slot is the sum over the keys already present. Because is not yet inserted, all existing keys are candidates. Using and Linearity of expectation: Expected search cost comparisons (the = touch 's slot header). Constant, independent of which 48 keys.

L2·Q3 — When is the bound exactly ?

For , name the condition under which holds exactly, and give the honest bound otherwise.

Recall Solution

Exactly iff divides (), because only then do the residues split into perfectly equal buckets. In general (with but ) the buckets are uneven ( vs residues), giving the almost-universal bound


Level 3 — Analysis

L3·Q1 — Why

Show concretely that allowing destroys universality. Use .

Recall Solution

If then , which is the same constant for every key . So for any distinct : always, i.e. . The requirement (never ) is exactly what keeps a bijection, so distinct keys get distinct residues before the final squeeze. ✔

L3·Q2 — Count colliding function-pairs by hand

Let , , and fix keys . Over all valid with , (that's functions), what fraction collide? Compare to the almost-universal bound.

Recall Solution

Collision happens iff and land in the same class mod . Direct enumeration over the 42 functions gives 14 collisions, fraction . Bound: (almost-universal), and . Observe , so this pair sits exactly at the truly-universal ceiling and comfortably under the almost-universal ceiling — no pair exceeds . ✔ (verified numerically).

The figure shows why the bound is and not exactly . What to observe: the seven residues are dealt into three buckets by "value mod 3", and bucket 0 gets three residues while buckets 1 and 2 get only two each. That single overloaded bucket is the extra collision risk — it is why the honest ceiling is , slightly above the ideal . Uneven buckets ⇒ almost-universal, not exactly universal.

Figure — Universal hashing — probabilistic guarantee

L3·Q3 — Variance of the analysis is not needed

The parent bounds using linearity of expectation without independence. Explain in one line why independence would have been the wrong assumption.

Recall Solution

Collisions are correlated: if and , then automatically — the events are chained, not independent. Linearity holds regardless of dependence, so we never need (and never have) independence. Assuming it would be false here.


Level 4 — Synthesis

L4·Q1 — Design for a target cost

You must guarantee expected search cost comparisons for a table that will hold up to keys. What is the largest load factor you may allow, and hence the minimum number of slots ?

Recall Solution

Expected cost . Require . Minimum slots . need not be prime — 50000 is perfectly fine (a common choice is even a power of two for a fast final ). The only primality requirement is on the modulus : you must pick a prime (bigger than every key), for example only if that exceeds your largest key; if keys can be large, must be a much bigger prime. So: slots, = any prime above the maximum key. This ties directly to Load factor and rehashing: keep low by resizing.

L4·Q2 — Combine with rehashing

Starting from , you double (rehash, drawing a fresh random ) whenever would exceed . You insert keys one at a time up to . How many resizes occur, and what is right after the last resize?

Recall Solution

Resize triggers when , i.e. at (), (), (). At , ; inserting up to crosses , so one more: (). That's 4 resizes (). After the last resize (, ): . Comfortably below , and fresh random each time preserves the per-pair guarantee.

The sawtooth figure makes the policy visible. What to observe: the blue curve climbs as keys are inserted, and every time it touches the pink threshold line at it instantly drops (a resize doubles , halving ). The yellow "resize" arrows sit exactly at . The takeaway: is never allowed above , so expected cost stays for the whole run.

Figure — Universal hashing — probabilistic guarantee

L4·Q3 — Why fresh randomness on rehash matters

Argue why we draw a new at each resize instead of reusing the old one.

Recall Solution

The universal guarantee is "for fixed keys, over the random draw of ". If we reuse , an adversary who has watched the table (timing, which keys collided) gains information that correlates future keys with the now-known — exactly the fixed-function weakness returning. A fresh independent draw restores the secret, so the bound applies anew to all pairs. See Adversarial inputs and randomized algorithms.


Level 5 — Mastery

L5·Q1 — Prove the bucket-imbalance bound

Prove that for and distinct ,

Recall Solution

Fix distinct . Set , . Bijection step (WHY): since is prime and , the map is a bijection onto all ordered pairs with (subtracting the two equations, , and is invertible mod ). So choosing uniformly is the same as choosing an ordered pair , , uniformly. Collision condition: iff . Fix ; among the other residues , how many satisfy ? Each residue class mod holds at most of the residues, so excluding itself leaves at most valid . Count: Final step (WHY each piece): we claim . Start from the ceiling fact that for any integers, (a ceiling never rounds up by a whole unit or more), so . Multiplying the ceiling of counts at most rounded up; subtracting therefore gives at most . Concretely, because (the smallest multiple of that is is at most ). Dividing both sides of by gives exactly . ∎ (This is the engine behind Perfect hashing (FKS) — uses universal hashing as a building block.)

L5·Q2 — Second-level FKS sizing

In FKS perfect hashing you build a small second-level table for the keys that fell into one bucket, using slots so that the expected number of collisions inside it is . Using a universal family, verify that expectation is for .

Recall Solution

Number of unordered pairs among keys is . Each collides with prob . By linearity: So with we expect fewer than collisions; by Markov, a collision-free second-level table exists with probability , so a few random draws find one. That's the heart of FKS's two-level -space, -worst-case scheme.

L5·Q3 — Sum over all buckets

Continuing FKS: if bucket holds keys and , the total second-level space is . Show its expectation is when the first-level table has buckets from a universal family.

Recall Solution

Step 1 — split the square (WHY: separate the diagonal). For each bucket use the identity , where counts unordered distinct pairs inside bucket . Summing over all buckets: (Used .) Step 2 — count colliding pairs in expectation (WHY: this is where universality enters). is exactly the number of unordered pairs of keys that landed in the same bucket. For one fixed pair , the probability they share a bucket is . There are pairs total, so by Linearity of expectation: Step 3 — plug in . Then . Step 4 — combine. So the whole two-level structure uses linear expected space while giving worst-case lookups — exactly the FKS guarantee. ∎


Self-test grid

Fresh on rehash — why?
Reusing leaks it; adversary correlates new keys with the known function, reviving the fixed-function attack.
Cost formula for a search under universal hashing?
where .
FKS second-level slot count for a bucket of keys?
, giving expected collisions .
Identity converting to pair counts?
.
Total FKS space with buckets?
.
Exact-universal condition for ?
(and always keep so no bucket is wasted).
Does have to be prime?
No — only must be prime with ; can be any size (often a power of two).
What does denote?
The indicator that keys collide; .

Connections

Difficulty ladder

L1 Recognition: spot the family

L2 Application: compute h and cost

L3 Analysis: why a nonzero, count pairs

L4 Synthesis: size m, rehash, fresh h

L5 Mastery: prove bound, FKS space

Perfect hashing FKS