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