ee76b0979f
siphash24() is wildly used by projects nowadays. It's certainly slower then our djb hashing that we used before. But quite likely it's fast enough for us, given how wildly it is used. I think it would be hard to profile NetworkManager to show that the performance of hash tables is the issue, be it with djb or siphash24. Certainly with siphash24() it's much harder to exploit the hashing algorithm to cause worst case hash operations (provided that the seed is kept private). Does this better resistance against a denial of service matter for us? Probably not, but let's better be safe then sorry. Note that systemd's implementation uses a different seed for each hash table (at least, after the hash table grows to a certain size). We don't do that and use only one global seed.
24 lines
627 B
C
24 lines
627 B
C
#pragma once
|
|
|
|
#include <inttypes.h>
|
|
#include <stddef.h>
|
|
#include <stdint.h>
|
|
#include <sys/types.h>
|
|
|
|
struct siphash {
|
|
uint64_t v0;
|
|
uint64_t v1;
|
|
uint64_t v2;
|
|
uint64_t v3;
|
|
uint64_t padding;
|
|
size_t inlen;
|
|
};
|
|
|
|
void siphash24_init(struct siphash *state, const uint8_t k[16]);
|
|
void siphash24_compress(const void *in, size_t inlen, struct siphash *state);
|
|
#define siphash24_compress_byte(byte, state) siphash24_compress((const uint8_t[]) { (byte) }, 1, (state))
|
|
|
|
uint64_t siphash24_finalize(struct siphash *state);
|
|
|
|
uint64_t siphash24(const void *in, size_t inlen, const uint8_t k[16]);
|