| 1 | ===========================
|
| 2 | SipHash - a short input PRF
|
| 3 | ===========================
|
| 4 |
|
| 5 | :Author: Written by Jason A. Donenfeld <[email protected]>
|
| 6 |
|
| 7 | SipHash is a cryptographically secure PRF -- a keyed hash function -- that
|
| 8 | performs very well for short inputs, hence the name. It was designed by
|
| 9 | cryptographers Daniel J. Bernstein and Jean-Philippe Aumasson. It is intended
|
| 10 | as a replacement for some uses of: `jhash`, `md5_transform`, `sha1_transform`,
|
| 11 | and so forth.
|
| 12 |
|
| 13 | SipHash takes a secret key filled with randomly generated numbers and either
|
| 14 | an input buffer or several input integers. It spits out an integer that is
|
| 15 | indistinguishable from random. You may then use that integer as part of secure
|
| 16 | sequence numbers, secure cookies, or mask it off for use in a hash table.
|
| 17 |
|
| 18 | Generating a key
|
| 19 | ================
|
| 20 |
|
| 21 | Keys should always be generated from a cryptographically secure source of
|
| 22 | random numbers, either using get_random_bytes or get_random_once::
|
| 23 |
|
| 24 | siphash_key_t key;
|
| 25 | get_random_bytes(&key, sizeof(key));
|
| 26 |
|
| 27 | If you're not deriving your key from here, you're doing it wrong.
|
| 28 |
|
| 29 | Using the functions
|
| 30 | ===================
|
| 31 |
|
| 32 | There are two variants of the function, one that takes a list of integers, and
|
| 33 | one that takes a buffer::
|
| 34 |
|
| 35 | u64 siphash(const void *data, size_t len, const siphash_key_t *key);
|
| 36 |
|
| 37 | And::
|
| 38 |
|
| 39 | u64 siphash_1u64(u64, const siphash_key_t *key);
|
| 40 | u64 siphash_2u64(u64, u64, const siphash_key_t *key);
|
| 41 | u64 siphash_3u64(u64, u64, u64, const siphash_key_t *key);
|
| 42 | u64 siphash_4u64(u64, u64, u64, u64, const siphash_key_t *key);
|
| 43 | u64 siphash_1u32(u32, const siphash_key_t *key);
|
| 44 | u64 siphash_2u32(u32, u32, const siphash_key_t *key);
|
| 45 | u64 siphash_3u32(u32, u32, u32, const siphash_key_t *key);
|
| 46 | u64 siphash_4u32(u32, u32, u32, u32, const siphash_key_t *key);
|
| 47 |
|
| 48 | If you pass the generic siphash function something of a constant length, it
|
| 49 | will constant fold at compile-time and automatically choose one of the
|
| 50 | optimized functions.
|
| 51 |
|
| 52 | Hashtable key function usage::
|
| 53 |
|
| 54 | struct some_hashtable {
|
| 55 | DECLARE_HASHTABLE(hashtable, 8);
|
| 56 | siphash_key_t key;
|
| 57 | };
|
| 58 |
|
| 59 | void init_hashtable(struct some_hashtable *table)
|
| 60 | {
|
| 61 | get_random_bytes(&table->key, sizeof(table->key));
|
| 62 | }
|
| 63 |
|
| 64 | static inline hlist_head *some_hashtable_bucket(struct some_hashtable *table, struct interesting_input *input)
|
| 65 | {
|
| 66 | return &table->hashtable[siphash(input, sizeof(*input), &table->key) & (HASH_SIZE(table->hashtable) - 1)];
|
| 67 | }
|
| 68 |
|
| 69 | You may then iterate like usual over the returned hash bucket.
|
| 70 |
|
| 71 | Security
|
| 72 | ========
|
| 73 |
|
| 74 | SipHash has a very high security margin, with its 128-bit key. So long as the
|
| 75 | key is kept secret, it is impossible for an attacker to guess the outputs of
|
| 76 | the function, even if being able to observe many outputs, since 2^128 outputs
|
| 77 | is significant.
|
| 78 |
|
| 79 | Linux implements the "2-4" variant of SipHash.
|
| 80 |
|
| 81 | Struct-passing Pitfalls
|
| 82 | =======================
|
| 83 |
|
| 84 | Often times the XuY functions will not be large enough, and instead you'll
|
| 85 | want to pass a pre-filled struct to siphash. When doing this, it's important
|
| 86 | to always ensure the struct has no padding holes. The easiest way to do this
|
| 87 | is to simply arrange the members of the struct in descending order of size,
|
| 88 | and to use offsetofend() instead of sizeof() for getting the size. For
|
| 89 | performance reasons, if possible, it's probably a good thing to align the
|
| 90 | struct to the right boundary. Here's an example::
|
| 91 |
|
| 92 | const struct {
|
| 93 | struct in6_addr saddr;
|
| 94 | u32 counter;
|
| 95 | u16 dport;
|
| 96 | } __aligned(SIPHASH_ALIGNMENT) combined = {
|
| 97 | .saddr = *(struct in6_addr *)saddr,
|
| 98 | .counter = counter,
|
| 99 | .dport = dport
|
| 100 | };
|
| 101 | u64 h = siphash(&combined, offsetofend(typeof(combined), dport), &secret);
|
| 102 |
|
| 103 | Resources
|
| 104 | =========
|
| 105 |
|
| 106 | Read the SipHash paper if you're interested in learning more:
|
| 107 | https://131002.net/siphash/siphash.pdf
|
| 108 |
|
| 109 | -------------------------------------------------------------------------------
|
| 110 |
|
| 111 | ===============================================
|
| 112 | HalfSipHash - SipHash's insecure younger cousin
|
| 113 | ===============================================
|
| 114 |
|
| 115 | :Author: Written by Jason A. Donenfeld <[email protected]>
|
| 116 |
|
| 117 | On the off-chance that SipHash is not fast enough for your needs, you might be
|
| 118 | able to justify using HalfSipHash, a terrifying but potentially useful
|
| 119 | possibility. HalfSipHash cuts SipHash's rounds down from "2-4" to "1-3" and,
|
| 120 | even scarier, uses an easily brute-forcable 64-bit key (with a 32-bit output)
|
| 121 | instead of SipHash's 128-bit key. However, this may appeal to some
|
| 122 | high-performance `jhash` users.
|
| 123 |
|
| 124 | HalfSipHash support is provided through the "hsiphash" family of functions.
|
| 125 |
|
| 126 | .. warning::
|
| 127 | Do not ever use the hsiphash functions except for as a hashtable key
|
| 128 | function, and only then when you can be absolutely certain that the outputs
|
| 129 | will never be transmitted out of the kernel. This is only remotely useful
|
| 130 | over `jhash` as a means of mitigating hashtable flooding denial of service
|
| 131 | attacks.
|
| 132 |
|
| 133 | On 64-bit kernels, the hsiphash functions actually implement SipHash-1-3, a
|
| 134 | reduced-round variant of SipHash, instead of HalfSipHash-1-3. This is because in
|
| 135 | 64-bit code, SipHash-1-3 is no slower than HalfSipHash-1-3, and can be faster.
|
| 136 | Note, this does *not* mean that in 64-bit kernels the hsiphash functions are the
|
| 137 | same as the siphash ones, or that they are secure; the hsiphash functions still
|
| 138 | use a less secure reduced-round algorithm and truncate their outputs to 32
|
| 139 | bits.
|
| 140 |
|
| 141 | Generating a hsiphash key
|
| 142 | =========================
|
| 143 |
|
| 144 | Keys should always be generated from a cryptographically secure source of
|
| 145 | random numbers, either using get_random_bytes or get_random_once::
|
| 146 |
|
| 147 | hsiphash_key_t key;
|
| 148 | get_random_bytes(&key, sizeof(key));
|
| 149 |
|
| 150 | If you're not deriving your key from here, you're doing it wrong.
|
| 151 |
|
| 152 | Using the hsiphash functions
|
| 153 | ============================
|
| 154 |
|
| 155 | There are two variants of the function, one that takes a list of integers, and
|
| 156 | one that takes a buffer::
|
| 157 |
|
| 158 | u32 hsiphash(const void *data, size_t len, const hsiphash_key_t *key);
|
| 159 |
|
| 160 | And::
|
| 161 |
|
| 162 | u32 hsiphash_1u32(u32, const hsiphash_key_t *key);
|
| 163 | u32 hsiphash_2u32(u32, u32, const hsiphash_key_t *key);
|
| 164 | u32 hsiphash_3u32(u32, u32, u32, const hsiphash_key_t *key);
|
| 165 | u32 hsiphash_4u32(u32, u32, u32, u32, const hsiphash_key_t *key);
|
| 166 |
|
| 167 | If you pass the generic hsiphash function something of a constant length, it
|
| 168 | will constant fold at compile-time and automatically choose one of the
|
| 169 | optimized functions.
|
| 170 |
|
| 171 | Hashtable key function usage
|
| 172 | ============================
|
| 173 |
|
| 174 | ::
|
| 175 |
|
| 176 | struct some_hashtable {
|
| 177 | DECLARE_HASHTABLE(hashtable, 8);
|
| 178 | hsiphash_key_t key;
|
| 179 | };
|
| 180 |
|
| 181 | void init_hashtable(struct some_hashtable *table)
|
| 182 | {
|
| 183 | get_random_bytes(&table->key, sizeof(table->key));
|
| 184 | }
|
| 185 |
|
| 186 | static inline hlist_head *some_hashtable_bucket(struct some_hashtable *table, struct interesting_input *input)
|
| 187 | {
|
| 188 | return &table->hashtable[hsiphash(input, sizeof(*input), &table->key) & (HASH_SIZE(table->hashtable) - 1)];
|
| 189 | }
|
| 190 |
|
| 191 | You may then iterate like usual over the returned hash bucket.
|
| 192 |
|
| 193 | Performance
|
| 194 | ===========
|
| 195 |
|
| 196 | hsiphash() is roughly 3 times slower than jhash(). For many replacements, this
|
| 197 | will not be a problem, as the hashtable lookup isn't the bottleneck. And in
|
| 198 | general, this is probably a good sacrifice to make for the security and DoS
|
| 199 | resistance of hsiphash().
|