Re: kaslr: better rng

Le 14/11/2017 à 19:33, Thor Lancelot Simon a écrit : On Tue, Nov 14, 2017 at 02:25:00PM +0100, Maxime Villard wrote: Le 11/11/2017 ?? 22:23, Taylor R Campbell a ??crit : Can you just use the SHA1 in libkern (and the SHA3 that will with any luck soon be in libkern), or are there constraints on

Re: kaslr: better rng

On Tue, Nov 14, 2017 at 02:25:00PM +0100, Maxime Villard wrote: > Le 11/11/2017 ?? 22:23, Taylor R Campbell a ??crit : > > Can you just use the SHA1 in libkern (and the SHA3 that will with any > > luck soon be in libkern), or are there constraints on the size of the > > prekern that prevent you

Re: kaslr: better rng

Le 11/11/2017 à 22:23, Taylor R Campbell a écrit : Can you just use the SHA1 in libkern (and the SHA3 that will with any luck soon be in libkern), or are there constraints on the size of the prekern that prevent you from doing so? No, there are no constraints. I just didn't know we could use

Re: kaslr: better rng

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

> 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

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

> 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: > >

Re: kaslr: better rng

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

re: kaslr: better rng

> Ah alright. But in my mail (that you were answering to) I did understand that > the entropy file comes from the previous run; what I was saying was, I would > prefer the file in question to contain random data right away and not just a > seed. In such a way that whoever wants to get random uints

Re: kaslr: better rng

> Date: Wed, 8 Nov 2017 18:23:11 +0100 > From: Maxime Villard > > Le 08/11/2017 à 18:17, Maxime Villard a écrit : > > Le 08/11/2017 à 17:37, Taylor R Campbell a écrit : > >> What's the advantage of (a) changing the on-disk file hierarchy and > >> generating the data on

Re: kaslr: better rng

Le 08/11/2017 à 18:17, Maxime Villard a écrit : Le 08/11/2017 à 17:37, Taylor R Campbell a écrit : Date: Wed, 8 Nov 2017 17:08:42 +0100 From: Maxime Villard Ah alright. But in my mail (that you were answering to) I did understand that the entropy file comes from the previous

Re: kaslr: better rng

Le 08/11/2017 à 17:37, Taylor R Campbell a écrit : Date: Wed, 8 Nov 2017 17:08:42 +0100 From: Maxime Villard Ah alright. But in my mail (that you were answering to) I did understand that the entropy file comes from the previous run; what I was saying was, I would prefer the

Re: kaslr: better rng

> Date: Wed, 8 Nov 2017 17:08:42 +0100 > From: Maxime Villard > > Ah alright. But in my mail (that you were answering to) I did understand that > the entropy file comes from the previous run; what I was saying was, I would > prefer the file in question to contain random data

Re: kaslr: better rng

Le 07/11/2017 à 17:21, Taylor R Campbell a écrit : Date: Tue, 7 Nov 2017 09:16:25 +0100 From: Maxime Villard Le 06/11/2017 à 19:47, Taylor R Campbell a écrit : The entropy file is supposed to be rewritten each time it's read, and on shutdown, or something like that. Yes, I

Re: kaslr: better rng

> On Nov 7, 2017, at 11:21 AM, Taylor R Campbell > wrote: > >> Date: Tue, 7 Nov 2017 09:16:25 +0100 >> From: Maxime Villard >> ... >> Well yes, my initial plan was two different files. > > What's the security goal you hope to achieve by

Re: kaslr: better rng

> Date: Tue, 7 Nov 2017 09:16:25 +0100 > From: Maxime Villard > > Le 06/11/2017 à 19:47, Taylor R Campbell a écrit : > > The entropy file is supposed to be rewritten each time it's read, and > > on shutdown, or something like that. > > Yes, I know that. But what is the point

Re: kaslr: better rng

Answering to each of your mails at once: Le 06/11/2017 à 19:47, Taylor R Campbell a écrit : The entropy file is supposed to be rewritten each time it's read, and on shutdown, or something like that. Yes, I know that. But what is the point you're trying to make? Le 06/11/2017 à 21:57,

Re: kaslr: better rng

> On Nov 6, 2017, at 12:51 PM, Maxime Villard wrote: > > Le 06/11/2017 à 18:28, Thor Lancelot Simon a écrit : >> On Mon, Nov 06, 2017 at 07:30:35AM +0100, Maxime Villard wrote: >>> I'm in a point where I need to have a better rng before continuing - and an >>> rng that can be

Re: kaslr: better rng

On Mon, Nov 06, 2017 at 06:51:33PM +0100, Maxime Villard wrote: > > > > What is the reason for using only part of the file, in any application? > > I meant to say that the components don't take random values from the same > area in the file, for them not to use the same random numbers twice.

Re: kaslr: better rng

Le 06/11/2017 à 18:28, Thor Lancelot Simon a écrit : On Mon, Nov 06, 2017 at 07:30:35AM +0100, Maxime Villard wrote: I'm in a point where I need to have a better rng before continuing - and an rng that can be used in the bootloader, in the prekern and in the kernel (early). I would like to use

Re: kaslr: better rng

> Date: Tue, 07 Nov 2017 07:57:58 +1100 > from: matthew green > > > Well, we could indeed extend /var/db/entropy-file. However, I would really > > prefer the random area to be generated from a previous run of the system, > > and > > not from the bootloader taking a seed in

re: kaslr: better rng

> Well, we could indeed extend /var/db/entropy-file. However, I would really > prefer the random area to be generated from a previous run of the system, and > not from the bootloader taking a seed in the file. Unless there is a > combination of both? it would be nice if the lack of this file

Re: kaslr: better rng

> Date: Mon, 6 Nov 2017 19:04:44 +0100 > From: Maxime Villard > > Well, we could indeed extend /var/db/entropy-file. However, I would really > prefer the random area to be generated from a previous run of the system, and > not from the bootloader taking a seed in the file.

Re: kaslr: better rng

Le 06/11/2017 à 18:35, Taylor R Campbell a écrit : Date: Mon, 6 Nov 2017 07:30:35 +0100 From: Maxime Villard I would like to use a system similar to the /var/db/entropy-file implementation. That is to say, when running the system generates /var/db/random-file, which would

Re: kaslr: better rng

> Date: Mon, 6 Nov 2017 07:30:35 +0100 > From: Maxime Villard > > I would like to use a system similar to the /var/db/entropy-file > implementation. That is to say, when running the system generates > /var/db/random-file, which would contain at least 256bytes of random > data.

Re: kaslr: better rng

On Mon, Nov 06, 2017 at 07:30:35AM +0100, Maxime Villard wrote: > I'm in a point where I need to have a better rng before continuing - and an > rng that can be used in the bootloader, in the prekern and in the kernel > (early). > > I would like to use a system similar to the /var/db/entropy-file

kaslr: better rng

I'm in a point where I need to have a better rng before continuing - and an rng that can be used in the bootloader, in the prekern and in the kernel (early). I would like to use a system similar to the /var/db/entropy-file implementation. That is to say, when running the system generates