aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/src/hashtables.h
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2016-07-05 17:14:59 +0200
committerJason A. Donenfeld <Jason@zx2c4.com>2016-07-22 16:48:51 +0200
commit86bd8deff00b748049bf156ccb8aaf59e5c33658 (patch)
treee258d47b1133edc1d203e625d0dd39e8cdd593fe /src/hashtables.h
parentcookie: do not expose csprng directly (diff)
downloadwireguard-monolithic-historical-86bd8deff00b748049bf156ccb8aaf59e5c33658.tar.xz
wireguard-monolithic-historical-86bd8deff00b748049bf156ccb8aaf59e5c33658.zip
index hashtable: run random indices through siphash
If /dev/urandom is a NOBUS RNG backdoor, like the infamous Dual_EC_DRBG, then sending 4 bytes of raw RNG output over the wire directly might not be such a great idea. This mitigates that vulnerability by, at some point before the indices are generated, creating a random secret. Then, for each session index, we simply run SipHash24 on an incrementing counter. This is probably overkill because /dev/urandom is probably not a backdoored RNG, and itself already uses several rounds of SHA-1 for mixing. If the kernel RNG is backdoored, there may very well be bigger problems at play. Four bytes is also not so many bytes.
Diffstat (limited to 'src/hashtables.h')
-rw-r--r--src/hashtables.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/src/hashtables.h b/src/hashtables.h
index 495a6f0..ed9506b 100644
--- a/src/hashtables.h
+++ b/src/hashtables.h
@@ -20,6 +20,8 @@ struct wireguard_peer *pubkey_hashtable_lookup(struct pubkey_hashtable *table, c
struct index_hashtable {
DECLARE_HASHTABLE(hashtable, 10);
+ uint8_t key[SIPHASH24_KEY_LEN];
+ atomic64_t counter;
spinlock_t lock;
};
struct index_hashtable_entry;