summaryrefslogtreecommitdiffstatshomepage
path: root/src/hashtables.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* headers: cleanup noticesJason A. Donenfeld2016-11-211-1/+1
|
* c89: the static keyword is okay in c99, but not in c89Jason A. Donenfeld2016-11-051-1/+1
|
* Rework headers and includesJason A. Donenfeld2016-09-291-2/+16
|
* hashtables: use rdrand() instead of counterJason A. Donenfeld2016-08-221-1/+0
|
* c: specify static array size in function paramsJason A. Donenfeld2016-08-021-1/+1
| | | | | | | | | | | | | | | The C standard states: A declaration of a parameter as ``array of type'' shall be adjusted to ``qualified pointer to type'', where the type qualifiers (if any) are those specified within the [ and ] of the array type derivation. If the keyword static also appears within the [ and ] of the array type derivation, then for each call to the function, the value of the corresponding actual argument shall provide access to the first element of an array with at least as many elements as specified by the size expression. By changing void func(int array[4]) to void func(int array[static 4]), we automatically get the compiler checking argument sizes for us, which is quite nice.
* index hashtable: run random indices through siphashJason A. Donenfeld2016-07-221-0/+2
| | | | | | | | | | | | | | 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.
* Initial commitJason A. Donenfeld2016-06-251-0/+33