ROBERT SEDGEWICK | KEVIN WAYN E
FOURTH EDITION
Algorithms
http://algs4.cs.princeton.edu
Algorithms
ROBERT SEDGEWICK | KEVIN WAY N E
3.4 HASH TABLES
‣
hash functions
‣
separate chaining
‣
linear probing
‣
context
Symbol table implementations: summary
Q. Can we do better?
A. Yes, but with different access to the data.
2
implementation
guarantee
guarantee
average case
average case
average case
ordered
ops?
key
interface
implementation
search
insert
delete
search hit
insert
delete
ordered
ops?
key
interface
sequential search
(unordered list)
N
N
N
½ N
N
½ N
equals()
binary search
(ordered array)
lg N
N
N
lg N
½ N
½ N
✔
compareTo()
BST
N
N
N
1.39 lg N
1.39 lg N
√
N
✔
compareTo()
red-black BST
2 lg N
2 lg N
2 lg N
1.0 lg N
1.0 lg N
1.0 lg N
✔
compareTo()
3
Hashing: basic plan
Save items in a key-indexed table (index is a function of the key).
Hash function. Method for computing array index from key.
Issues.
Computing the hash function.
Equality test: Method for checking whether two keys are equal.
Collision resolution: Algorithm and data structure
to handle two keys that hash to the same array index.
Classic space-time tradeoff.
No space limitation: trivial hash function with key as index.
No time limitation: trivial collision resolution with sequential search.
Space and time limitations: hashing (the real world).
hash("times") = 3
??
0
1
2
3
"it"
4
5
hash("it") = 3
http://algs4.cs.princeton.edu
ROBERT SEDGEWICK | KEVIN WAYN E
Algorithms
‣
hash functions
‣
separate chaining
‣
linear probing
‣
context
3.4 HASH TABLES
5
Computing the hash function
Idealistic goal. Scramble the keys uniformly to produce a table index.
Efficiently computable.
Each table index equally likely for each key.
Ex 1. Phone numbers.
Bad: first three digits.
Better: last three digits.
Ex 2. Social Security numbers.
Bad: first three digits.
Better: last three digits.
Practical challenge. Need different approach for each key type.
thoroughly researched problem,
still problematic in practical applications
573 = California, 574 = Alaska
(assigned in chronological order within geographic region)
key
table
index
6
Java’s hash code conventions
All Java classes inherit a method hashCode(), which returns a 32-bit int.
Requirement. If x.equals(y), then (x.hashCode() == y.hashCode()).
Highly desirable. If !x.equals(y), then (x.hashCode() != y.hashCode()).
Default implementation. Memory address of x.
Legal (but poor) implementation. Always return 17.
Customized implementations. Integer, Double, String, File, URL, Date, …
User-defined types. Users are on their own.
x.hashCode()
x
y.hashCode()
y
7
Implementing hash code: integers, booleans, and doubles
public final class Integer
{
private final int value;
...
public int hashCode()
{ return value; }
}
convert to IEEE 64-bit representation;
xor most significant 32-bits
with least significant 32-bits
Warning: -0.0 and +0.0 have different hash codes
public final class Double
{
private final double value;
...
public int hashCode()
{
long bits = doubleToLongBits(value);
return (int) (bits ^ (bits >>> 32));
}
}
public final class Boolean
{
private final boolean value;
...
public int hashCode()
{
if (value) return 1231;
else return 1237;
}
}
Java library implementations
Horner's method to hash string of length L: L multiplies/adds.
Equivalent to h = s[0]
·
31
L–1
+ … + s[L – 3]
· 31
2
+ s[L – 2]
·
31
1
+ s[L – 1]
·
31
0
.
Ex.
public final class String
{
private final char[] s;
...
public int hashCode()
{
int hash = 0;
for (int i = 0; i < length(); i++)
hash = s[i] + (31 * hash);
return hash;
}
}
8
Implementing hash code: strings
3045982 = 99·31
3
+ 97·31
2
+ 108·31
1
+ 108·31
0
= 108 + 31· (108 + 31 · (97 + 31 · (99)))
(Horner's method)
i
th
character of s
String s = "call";
int code = s.hashCode();
char
Unicode
…
…
'a'
97
'b'
98
'c'
99
…
...
Java library implementation
Performance optimization.
Cache the hash value in an instance variable.
Return cached value.
Q. What if hashCode() of string is 0?
public final class String
{
private int hash = 0;
private final char[] s;
...
public int hashCode()
{
int h = hash;
if (h != 0) return h;
for (int i = 0; i < length(); i++)
h = s[i] + (31 * h);
hash = h;
return h;
}
}
9
Implementing hash code: strings
return cached value
cache of hash code
store cache of hash code
10
Implementing hash code: user-defined types
public final class Transaction implements Comparable<Transaction>
{
private final String who;
private final Date when;
private final double amount;
public Transaction(String who, Date when, double amount)
{ /* as before */ }
...
public boolean equals(Object y)
{ /* as before */ }
public int hashCode()
{
int hash = 17;
hash = 31*hash + who.hashCode();
hash = 31*hash + when.hashCode();
hash = 31*hash + ((Double) amount).hashCode();
return hash;
}
}
typically a small prime
nonzero constant
for primitive types,
use hashCode()
of wrapper type
for reference types,
use hashCode()
11
Hash code design
"Standard" recipe for user-defined types.
Combine each significant field using the 31x + y rule.
If field is a primitive type, use wrapper type hashCode().
If field is null, return 0.
If field is a reference type, use hashCode().
If field is an array, apply to each entry.
In practice. Recipe works reasonably well; used in Java libraries.
In theory. Keys are bitstring; "universal" hash functions exist.
Basic rule. Need to use the whole key to compute hash code;
consult an expert for state-of-the-art hash codes.
or use Arrays.deepHashCode()
applies rule recursively
Hash code. An int between -2
31
and 2
31
- 1.
Hash function. An int between 0 and M - 1 (for use as array index).
12
Modular hashing
typically a prime or power of 2
private int hash(Key key)
{ return key.hashCode() % M; }
bug
private int hash(Key key)
{ return Math.abs(key.hashCode()) % M; }
private int hash(Key key)
{ return (key.hashCode() & 0x7fffffff) % M; }
correct
1-in-a-billion bug
hashCode() of "polygenelubricants" is -2
31
x.hashCode()
x
hash(x)
13
Uniform hashing assumption
Uniform hashing assumption. Each key is equally likely to hash to an
integer between 0 and M - 1.
Bins and balls. Throw balls uniformly at random into M bins.
Birthday problem. Expect two balls in the same bin after ~ π M / 2 tosses.
Coupon collector. Expect every bin has ≥ 1 ball after ~ M ln M tosses.
Load balancing. After M tosses, expect most loaded bin has
Θ ( log M / log log M ) balls.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
14
Uniform hashing assumption
Uniform hashing assumption. Each key is equally likely to hash to an
integer between 0 and M - 1.
Bins and balls. Throw balls uniformly at random into M bins.
Hash value frequencies for words in Tale of Two Cities (M = 97)
Java's String data uniformly distribute the keys of Tale of Two Cities
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
http://algs4.cs.princeton.edu
ROBERT SEDGEWICK | KEVIN WAYN E
Algorithms
‣
hash functions
‣
separate chaining
‣
linear probing
‣
context
3.4 HASH TABLES
16
Collisions
Collision. Two distinct keys hashing to same index.
Birthday problem ⇒ can't avoid collisions unless you have
a ridiculous (quadratic) amount of memory.
Coupon collector + load balancing ⇒ collisions are evenly distributed.
Challenge. Deal with collisions efficiently.
hash("times") = 3
??
0
1
2
3
"it"
4
5
hash("it") = 3
Use an array of M < N linked lists. [H. P. Luhn, IBM 1953]
Hash: map key to integer i between 0 and M - 1.
Insert: put at front of i
th
chain (if not already there).
Search: need to search only i
th
chain.
17
Separate-chaining symbol table
Hashing with separate chaining for standard indexing client
st[]
0
1
2
3
4
S 0X 7
E 12A 8
P 10L 11
R 3C 4H 5M 9
S 2 0
E 0 1
A 0 2
R 4 3
C 4 4
H 4 5
E 0 6
X 2 7
A 0 8
M 4 9
P 3 10
L 3 11
E 0 12
null
key
hash
value
public class SeparateChainingHashST<Key, Value>
{
private int M = 97; // number of chains
private Node[] st = new Node[M]; // array of chains
private static class Node
{
private Object key;
private Object val;
private Node next;
...
}
private int hash(Key key)
{ return (key.hashCode() & 0x7fffffff) % M; }
public Value get(Key key) {
int i = hash(key);
for (Node x = st[i]; x != null; x = x.next)
if (key.equals(x.key)) return (Value) x.val;
return null;
}
}
Separate-chaining symbol table: Java implementation
18
no generic array creation
(declare key and value of type Object)
array doubling and
halving code omitted
public class SeparateChainingHashST<Key, Value>
{
private int M = 97; // number of chains
private Node[] st = new Node[M]; // array of chains
private static class Node
{
private Object key;
private Object val;
private Node next;
...
}
private int hash(Key key)
{ return (key.hashCode() & 0x7fffffff) % M; }
public void put(Key key, Value val) {
int i = hash(key);
for (Node x = st[i]; x != null; x = x.next)
if (key.equals(x.key)) { x.val = val; return; }
st[i] = new Node(key, val, st[i]);
}
}
Separate-chaining symbol table: Java implementation
19
Proposition. Under uniform hashing assumption, prob. that the number of
keys in a list is within a constant factor of N / M is extremely close to 1.
Pf sketch. Distribution of list size obeys a binomial distribution.
Consequence. Number of probes for search/insert is proportional to N / M.
M too large ⇒ too many empty chains.
M too small ⇒ chains too long.
Typical choice: M ~ N / 4 ⇒ constant-time ops.
20
Analysis of separate chaining
M times faster than
sequential search
equals() and hashCode()
Binomial distribution (N = 10
4
, M = 10
3
, ! = 10 )
.125
0
0 10 20
30
(10, .12511...)
Goal. Average length of list N / M = constant.
Double size of array M when N / M ≥ 8.
Halve size of array M when N / M ≤ 2.
Need to rehash all keys when resizing.
21
Resizing in a separate-chaining hash table
A B C D E F G H I J
K L M N O P
0
1
K I
P N L E
0
1
2
3
before resizing
after resizing
J F C B
O M H G D
A
x.hashCode() does not change
but hash(x) can change
st[]
st[]
Q. How to delete a key (and its associated value)?
A. Easy: need only consider chain containing key.
22
Deletion in a separate-chaining hash table
before deleting C
K I
P N L
0
1
2
3
J F C B
O M
st[]
K I
P N L
J F B
O M
after deleting C
0
1
2
3
st[]
Symbol table implementations: summary
23
* under uniform hashing assumption
implementation
guarantee
guarantee
average case
average case
average case
ordered
ops?
key
interface
implementation
search
insert
delete
search hit
insert
delete
ordered
ops?
key
interface
sequential search
(unordered list)
N
N
N
½ N
N
½ N
equals()
binary search
(ordered array)
lg N
N
N
lg N
½ N
½ N
✔
compareTo()
BST
N
N
N
1.39 lg N
1.39 lg N
√
N
✔
compareTo()
red-black BST
2 lg N
2 lg N
2 lg N
1.0 lg N
1.0 lg N
1.0 lg N
✔
compareTo()
separate chaining
N
N
N
3-5 *
3-5 *
3-5 *
equals()
hashCode()
http://algs4.cs.princeton.edu
ROBERT SEDGEWICK | KEVIN WAYN E
Algorithms
‣
hash functions
‣
separate chaining
‣
linear probing
‣
context
3.4 HASH TABLES
Open addressing. [Amdahl-Boehme-Rocherster-Samuel, IBM 1953]
When a new key collides, find next empty slot, and put it there.
25
Collision resolution: open addressing
null
null
linear probing (M = 30001, N = 15000)
jocularly
listen
suburban
browsing
st[0]
st[1]
st[2]
st[30000]
st[3]
Hash. Map key to integer i between 0 and M-1.
Insert. Put at table index i if free; if not try i+1, i+2, etc.
Linear-probing hash table demo
0 1 2 3 4 5 6 7 8 9
st[]
10 11 12 13 14 15
M = 16
linear-probing hash table
Hash. Map key to integer i between 0 and M-1.
Search. Search table index i; if occupied but no match, try i+1, i+2, etc.
Linear-probing hash table demo
0 1 2 3 4 5 6 7 8 9
st[]
10 11 12 13 14 15
M = 16
S EA C H R XMP L
search
hash(K) = 5
K
K
search miss
(return null)
Hash. Map key to integer i between 0 and M-1.
Insert. Put at table index i if free; if not try i+1, i+2, etc.
Search. Search table index i; if occupied but no match, try i+1, i+2, etc.
Note. Array size M must be greater than number of key-value pairs N.
28
Linear-probing hash table summary
0 1 2 3 4 5 6 7 8 9
st[]
10 11 12 13 14 15
M = 16
S EA C H R XMP L
public class LinearProbingHashST<Key, Value>
{
private int M = 30001;
private Value[] vals = (Value[]) new Object[M];
private Key[] keys = (Key[]) new Object[M];
private int hash(Key key) { /* as before */ }
private void put(Key key, Value val) { /* next slide */ }
public Value get(Key key)
{
for (int i = hash(key); keys[i] != null; i = (i+1) % M)
if (key.equals(keys[i]))
return vals[i];
return null;
}
}
Linear-probing symbol table: Java implementation
29
array doubling and
halving code omitted
public class LinearProbingHashST<Key, Value>
{
private int M = 30001;
private Value[] vals = (Value[]) new Object[M];
private Key[] keys = (Key[]) new Object[M];
private int hash(Key key) { /* as before */ }
private Value get(Key key) { /* previous slide */ }
public void put(Key key, Value val)
{
int i;
for (i = hash(key); keys[i] != null; i = (i+1) % M)
if (keys[i].equals(key))
break;
keys[i] = key;
vals[i] = val;
}
}
Linear-probing symbol table: Java implementation
30
Cluster. A contiguous block of items.
Observation. New keys likely to hash into middle of big clusters.
31
Clustering
Model. Cars arrive at one-way street with M parking spaces.
Each desires a random space i : if space i is taken, try i + 1, i + 2, etc.
Q. What is mean displacement of a car?
Half-full. With M / 2 cars, mean displacement is ~ 3 / 2.
Full. With M cars, mean displacement is ~ π M / 8 .
32
Knuth's parking problem
displacement = 3
Proposition. Under uniform hashing assumption, the average # of probes
in a linear probing hash table of size M that contains N = α M keys is:
Pf.
Parameters.
M too large ⇒ too many empty array entries.
M too small ⇒ search time blows up.
Typical choice: α = N / M ~ ½.
33
Analysis of linear probing
⇥
1
2
1+
1
1
⇥
⇥
1
2
1+
1
(1 )
2
⇥
search hit
search miss / insert
# probes for search hit is about 3/2
# probes for search miss is about 5/2
Goal. Average length of list N / M ≤ ½.
Double size of array M when N / M ≥ ½.
Halve size of array M when N / M ≤ ⅛.
Need to rehash all keys when resizing.
34
Resizing in a linear-probing hash table
keys[]
0
1
2
3
4
5
6
7
E
S
R
A
1
0
3
2
vals[]
keys[]
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
A
S
E
R
2
0
1
3
vals[]
after resizing
before resizing
Q. How to delete a key (and its associated value)?
A. Requires some care: can't just delete array entries.
35
Deletion in a linear-probing hash table
keys[]
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
P
M
A
C
S
H
L
E
R
X
10
9
8
4
0
5
11
12
3
7
vals[]
before deleting S
keys[]
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
P
M
A
C
H
L
E
R
X
10
9
8
4
5
11
12
3
7
vals[]
after deleting S ?
doesn't work, e.g., if hash(H) = 4
ST implementations: summary
36
* under uniform hashing assumption
implementation
guarantee
guarantee
average case
average case
average case
ordered
ops?
key
interface
implementation
search
insert
delete
search hit
insert
delete
ordered
ops?
key
interface
sequential search
(unordered list)
N
N
N
½ N
N
½ N
equals()
binary search
(ordered array)
lg N
N
N
lg N
½ N
½ N
✔
compareTo()
BST
N
N
N
1.39 lg N
1.39 lg N
√
N
✔
compareTo()
red-black BST
2 lg N
2 lg N
2 lg N
1.0 lg N
1.0 lg N
1.0 lg N
✔
compareTo()
separate chaining
N
N
N
3-5 *
3-5 *
3-5 *
equals()
hashCode()
linear probing
N
N
N
3-5 *
3-5 *
3-5 *
equals()
hashCode()
http://algs4.cs.princeton.edu
ROBERT SEDGEWICK | KEVIN WAYN E
Algorithms
‣
hash functions
‣
separate chaining
‣
linear probing
‣
context
3.4 HASH TABLES
38
War story: algorithmic complexity attacks
Q. Is the uniform hashing assumption important in practice?
A. Obvious situations: aircraft control, nuclear reactor, pacemaker.
A. Surprising situations: denial-of-service attacks.
Real-world exploits. [Crosby-Wallach 2003]
Bro server: send carefully chosen packets to DOS the server,
using less bandwidth than a dial-up modem.
Perl 5.8.0: insert carefully chosen strings into associative array.
Linux 2.4.20 kernel: save files with carefully chosen names.
malicious adversary learns your hash function
(e.g., by reading Java API) and causes a big pile-up
in single slot that grinds performance to a halt
0
1
2
3
st[]
4
5
6
7
39
War story: algorithmic complexity attacks
A Java bug report.
Description
Comment 2
Comment 11
Format For Printing - XML - Clone This Bug - Last Comment
Bug 750533 - (CVE-2012-2739) CVE-2012-2739 java: hash table collisions
CPU usage DoS (oCERT-2011-003)
Status: ASSIGNED
Aliases: CVE-2012-2739 (edit)
Product: Security Response
Component: vulnerability (Show other bugs)
Version(s): unspecified
Platform: All Linux
Priority: medium Severity: medium
Target Milestone: ---
Target Release: ---
Assigned To: Red Hat Security Response Team
QA Contact:
URL:
Whiteboard: impact=moderate,public=20111228,repor...
Keywords: Reopened, Security
Depends On:
Blocks: hashdos/oCERT-2011-003 750536
Show dependency tree / graph
Reported: 2011-11-01 10:13 EDT by Jan Lieskovsky
Modified: 2012-11-27 10:50 EST (History)
CC List: 8 users (show)
See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-29 07:40:08
Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)
Groups: None (edit)
Jan Lieskovsky 2011-11-01 10:13:47 EDT
Julian Wälde and Alexander Klink reported that the String.hashCode() hash function is not sufficiently collision
resistant. hashCode() value is used in the implementations of HashMap and Hashtable classes:
http://docs.oracle.com/javase/6/docs/api/java/util/HashMap.html
http://docs.oracle.com/javase/6/docs/api/java/util/Hashtable.html
A specially-crafted set of keys could trigger hash function collisions, which can degrade performance of HashMap
or Hashtable by changing hash table operations complexity from an expected/average O(1) to the worst case O(n).
Reporters were able to find colliding strings efficiently using equivalent substrings and meet in the middle
techniques.
This problem can be used to start a denial of service attack against Java applications that use untrusted inputs
as HashMap or Hashtable keys. An example of such application is web application server (such as tomcat, see bug
#750521) that may fill hash tables with data from HTTP request (such as GET or POST parameters). A remote
attack could use that to make JVM use excessive amount of CPU time by sending a POST request with large amount
of parameters which hash to the same value.
This problem is similar to the issue that was previously reported for and fixed
in e.g. perl:
http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf
Jan Lieskovsky 2011-11-01 10:18:44 EDT
Acknowledgements:
Red Hat would like to thank oCERT for reporting this issue. oCERT acknowledges Julian Wälde and Alexander Klink
as the original reporters.
Tomas Hoger 2011-12-29 07:23:27 EST
This issue was presented on 28C3:
http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html
Details were posted to full-disclosure:
http://seclists.org/fulldisclosure/2011/Dec/477
Goal. Find family of strings with the same hash code.
Solution. The base-31 hash code is part of Java's string API.
40
Algorithmic complexity attack on Java
2
N
strings of length 2N that hash to same value!
key
hashCode()
"AaAaAaAa"
-540425984
"AaAaAaBB"
-540425984
"AaAaBBAa"
-540425984
"AaAaBBBB"
-540425984
"AaBBAaAa"
-540425984
"AaBBAaBB"
-540425984
"AaBBBBAa"
-540425984
"AaBBBBBB"
-540425984
key
hashCode()
"BBAaAaAa"
-540425984
"BBAaAaBB"
-540425984
"BBAaBBAa"
-540425984
"BBAaBBBB"
-540425984
"BBBBAaAa"
-540425984
"BBBBAaBB"
-540425984
"BBBBBBAa"
-540425984
"BBBBBBBB"
-540425984
key
hashCode()
"Aa"
2112
"BB"
2112
41
Diversion: one-way hash functions
One-way hash function. "Hard" to find a key that will hash to a desired
value (or two keys that hash to same value).
Ex. MD4, MD5, SHA-0, SHA-1, SHA-2, WHIRLPOOL, RIPEMD-160, ….
Applications. Digital fingerprint, message digest, storing passwords.
Caveat. Too expensive for use in ST implementations.
known to be insecure
String password = args[0];
MessageDigest sha1 = MessageDigest.getInstance("SHA1");
byte[] bytes = sha1.digest(password);
/* prints bytes as hex string */
Separate chaining vs. linear probing
Separate chaining.
Performance degrades gracefully.
Clustering less sensitive to poorly-designed hash function.
Linear probing.
Less wasted space.
Better cache performance.
42
Hashing with separate chaining for standard indexing client
st[]
0
1
2
3
4
S 0X 7
E 12A 8
P 10L 11
R 3C 4H 5M 9
S 2 0
E 0 1
A 0 2
R 4 3
C 4 4
H 4 5
E 0 6
X 2 7
A 0 8
M 4 9
P 3 10
L 3 11
E 0 12
null
key
hash
value
keys[]
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
P
M
A
C
S
H
L
E
R
X
10
9
8
4
0
5
11
12
3
7
vals[]
Hashing: variations on the theme
Many improved versions have been studied.
Two-probe hashing. [ separate-chaining variant ]
Hash to two positions, insert key in shorter of the two chains.
Reduces expected length of the longest chain to log log N.
Double hashing. [ linear-probing variant ]
Use linear probing, but skip a variable amount, not just 1 each time.
Effectively eliminates clustering.
Can allow table to become nearly full.
More difficult to implement delete.
Cuckoo hashing. [ linear-probing variant ]
Hash key to two positions; insert key into either position; if occupied,
reinsert displaced key into its alternative position (and recur).
Constant worst-case time for search.
43
Hash tables vs. balanced search trees
Hash tables.
Simpler to code.
No effective alternative for unordered keys.
Faster for simple keys (a few arithmetic ops versus log N compares).
Better system support in Java for strings (e.g., cached hash code).
Balanced search trees.
Stronger performance guarantee.
Support for ordered ST operations.
Easier to implement compareTo() correctly than equals() and hashCode().
Java system includes both.
Red-black BSTs: java.util.TreeMap, java.util.TreeSet.
Hash tables: java.util.HashMap, java.util.IdentityHashMap.
44