diff options
author | Jason A. Donenfeld <Jason@zx2c4.com> | 2016-07-05 17:14:59 +0200 |
---|---|---|
committer | Jason A. Donenfeld <Jason@zx2c4.com> | 2016-07-22 16:48:51 +0200 |
commit | 86bd8deff00b748049bf156ccb8aaf59e5c33658 (patch) | |
tree | e258d47b1133edc1d203e625d0dd39e8cdd593fe /src/hashtables.h | |
parent | cookie: do not expose csprng directly (diff) | |
download | wireguard-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.h | 2 |
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; |