On Sun, Dec 11, 2016 at 04:30:31PM +0100, Jason A. Donenfeld wrote:
> Hi Greg,
>
> Thanks for the review. Responses to your suggestions are inline below:
>
> On Sat, Dec 10, 2016 at 1:37 PM, Greg KH wrote:
> > Please use u64 and u8 instead of the userspace uint64_t and uint8_t
> > types for kern
Hi Greg,
Thanks for the review. Responses to your suggestions are inline below:
On Sat, Dec 10, 2016 at 1:37 PM, Greg KH wrote:
> Please use u64 and u8 instead of the userspace uint64_t and uint8_t
> types for kernel code. Yes, the ship has probably sailed for trying to
> strictly enforce it, b
> There's a 32-bit secret random salt (inet_ehash_secret) which means
> that in practice, inet_ehashfn() will select 1 out of 2^32 different
> hash functions at random each time you boot the kernel; without
> knowing which one it selected, how can a local or remote attacker can
> force IPv4 connect
On 9 December 2016 at 19:36, Jason A. Donenfeld wrote:
> SipHash is a 64-bit keyed hash function that is actually a
> cryptographically secure PRF, like HMAC. Except SipHash is super fast,
> and is meant to be used as a hashtable keyed lookup function.
>
> SipHash isn't just some new trendy hash f
On Fri, Dec 09, 2016 at 07:36:59PM +0100, Jason A. Donenfeld wrote:
> SipHash is a 64-bit keyed hash function that is actually a
> cryptographically secure PRF, like HMAC. Except SipHash is super fast,
> and is meant to be used as a hashtable keyed lookup function.
>
> SipHash isn't just some new
SipHash is a 64-bit keyed hash function that is actually a
cryptographically secure PRF, like HMAC. Except SipHash is super fast,
and is meant to be used as a hashtable keyed lookup function.
SipHash isn't just some new trendy hash function. It's been around for a
while, and there really isn't any
