Re: kaslr: better rng

2017-11-11 Thread Thor Lancelot Simon
On Sat, Nov 11, 2017 at 09:23:39PM +, Taylor R Campbell wrote: > > Speaking of which, you should read 256 bits out of rdseed, not 64, and > fall back to rdrand if rdseed is not available. cpu_rng already has the code needed to do this -- best to use it, perhaps? Thor

Re: kaslr: better rng

2017-11-11 Thread Taylor R Campbell
> Date: Sat, 11 Nov 2017 21:48:54 +0100 > From: Maxime Villard > > The hash of y against rdtsc and rdseed is the new secret, not just y. It's > not a recurrent Yn+1 = H(Yn) construction from a single Y0 seed - in which > case one leak in the chain would indeed compromise the

Re: kaslr: better rng

2017-11-11 Thread Maxime Villard
Le 11/11/2017 à 20:14, Taylor R Campbell a écrit : If we _both_ reveal y = H(x) for some initial secret x, and then use y as the new secret, we've just revealed the new secret. The hash of y against rdtsc and rdseed is the new secret, not just y. It's not a recurrent Yn+1 = H(Yn) construction

Re: kaslr: better rng

2017-11-11 Thread Taylor R Campbell
> Date: Sat, 11 Nov 2017 15:48:12 +0100 > From: Maxime Villard > > It is based on the SHAKE256 hash function, which can produce a variable > sized output. We use an area of 32 bytes, and regenerate it as many times > as needed. > > The first time, it is generated with: > >

SHA-3

2017-11-11 Thread Taylor R Campbell
Back in 2014, I proposed to import a simple SHA-3 implementation into libc and libkern. There were two main objections: 1. SHA-3 wasn't finalized yet, so it might change. 2. OpenSSL might add an incompatible SHA-3 API like they did SHA-2. The SHA-3 standard has since been finalized (with no

Re: kaslr: better rng

2017-11-11 Thread Maxime Villard
Following a conversation with Taylor, I ended up with the following implementation for the prekern [1] [2]. It uses a set of seeds that are hashed together in rounds, and it doesn't use an additional file. It is based on the SHAKE256 hash function, which can produce a variable sized output. We