17 \h'-\w'\\$1\ 'u'\\$1\ \c
36 .TH unihash 3 "5 July 2003" "Straylight/Edgeware" "mLib utilities library"
38 unihash \- simple and efficient universal hashing for hashtables
46 .B "#include <mLib/unihash.h>"
48 .B "typedef struct { ...\& } unihash_info;"
50 .B "unihash_info unihash_global;"
52 .BI "void unihash_setkey(unihash_info *" i ", uint32 " k );
53 .BI "uint32 UNIHASH_INIT(const unihash_info *" i );
54 .ta \w'\fBuint32 unihash_hash('u
55 .BI "uint32 unihash_hash(const unihash_info *" i ", uint32 " a ,
56 .BI " const void *" p ", size_t " sz );
57 .BI "uint32 unihash(const unihash_info *" i ", const void *" p ", size_t " sz );
58 .BI "uint32 UNIHASH(const unihash_info *" i ", const void *" p ", size_t " sz );
63 system implements a simple and relatively efficient
64 .IR "universal hashing family" .
65 Using a such a universal hashing family means that it's provably
66 difficult for an adversary to choose input data whose hashes collide,
67 thus guaranteeing good average performance even on maliciously chosen
76 \- in addition to the data to be hashed, the function takes as input a
77 32-bit key. This key should be chosen at random each time the program
79 .SS "Preprocessing a key"
80 Before use, a key must be
82 into a large (16K) table which is used by the main hashing functions.
83 The preprocessing is done by
85 pass it a pointer to a
87 structure and the 32-bit key you've chosen, and it stores the table in
92 don't contain any pointers to other data and are safe to free when
93 you've finished with them; or you can just allocate them statically or
94 on the stack if that's more convenient.
100 .BI "const unihash_info *" i
101 A pointer to the precomputed tables for a key.
104 An accumulator value. This should be
105 .BI UNIHASH_INIT( i )
106 for the first chunk of a multi-chunk input, or the result of the
109 call for subsequent chunks.
112 A pointer to the start of a buffer containing this chunk of data.
115 The length of the chunk.
117 The function returns a new accumulator value, which is also the hash of
118 the data so far. So, to hash multiple chunks of data, do something like
120 uint32 a = UNIHASH_INIT(i);
121 a = unihash_hash(i, a, p_0, sz_0);
122 a = unihash_hash(i, a, p_1, sz_1);
124 a = unihash_hash(i, a, p_n, sz_n);
130 are convenient interfaces to
132 if you only wanted to hash one chunk.
133 .SS "Global hash info table"
134 There's no problem with using the same key for several purposes, as long
135 as it's secret from all of your adversaries. Therefore, there is a
140 This initially contains information for a fixed key which the author
141 chose at random, but if you need to you can set a different key into it
143 it gets used to hash any data (otherwise your hash tables will become
145 .SS "Theoretical issues"
146 The hash function implemented by
149 .RI ( l \ +\ 1)/2\*(ss32\*(se-almost
152 is the length (in bytes) of the longest string you hash. That means
153 that, for any pair of strings
157 and any 32-bit value \*(*d, the probability taken over all choices of the
161 .IR H\*(usk\*(ue ( x )\ \c
163 .RI \ H\*(usk\*(ue ( y )\ =\ \*(*d
165 .RI ( l \ +\ 1)/2\*(ss32\*(se.
167 This fact is proven in the header file, but it requires more
168 sophisticated typesetting than is available here.
170 The function evaluates a polynomial over GF(2\*(ss32\*(se) whose
171 coefficients are the bytes of the message and whose variable is the key.
172 Details are given in the header file.
174 For best results, you should choose the key as a random 32-bit number
175 each time your program starts. Choosing a different key for different
176 hashtables isn't necessary. It's probably a good idea to avoid the keys
177 0 and 1. This raises the collision bound to
178 .RI ( l \ +\ 1)/(2\*(ss32\*(se\ \-\ 2)
179 (which isn't a significant increase) but eliminates keys for which the
180 hash's behaviour is particularly poor.
184 actually performed better than
186 so if you want to just use it as a fast-ish hash with good statistical
187 properties, choose some fixed key
190 We emphasize that the proof of this function's collision behaviour is
192 dependent on any unproven assumptions (unlike many `proofs' of
193 cryptographic security, which actually reduce the security of some
194 construction to the security of its components). It's just a fact.
196 .BR unihash-mkstatic (3),
200 Mark Wooding (mdw@distorted.org.uk).