On Thu, Dec 04, 2014 at 12:52:04PM -0500, Ted Unangst wrote:
> Ah, so this won't work. That's not how siphash works.
>
> The key needs to last as long as the hash table does, which is
> generally as long as the program. Different keys result in different
> hashes, which makes it hard to look thing
On 2014/12/04 17:41, Dimitris Papastamos wrote:
> Admittedly it would have been better to store the key in the struct
> and then use arc4random_buf() only once or so. I am not familiar with the
> code so I will investigate this option.
>
I suspect attr_alloc() is going to be a rather hot functio
On Thu, Dec 04, 2014 at 17:32, Dimitris Papastamos wrote:
> Hi,
>
> This is my attempt at converting bgpd to use siphash. This does
> *not* link as is because the userland implementation of siphash
> is currently missing.
Indeed. That should be coming in a few days. I have a diff ready.
>
> +
Admittedly it would have been better to store the key in the struct
and then use arc4random_buf() only once or so. I am not familiar with the
code so I will investigate this option.
Hi,
This is my attempt at converting bgpd to use siphash. This does
*not* link as is because the userland implementation of siphash
is currently missing.
In certain cases where multiple data is hashed in succession, it might
have been better to use a siphash context and call SipHash24_Update().
