Am Freitag, 10. Januar 2020, 00:02:37 CET schrieb Kurt Roeckx:

Hi Kurt,

On Thu, Jan 09, 2020 at 05:40:11PM -0500, Theodore Y. Ts'o wrote:

quoted

On Thu, Jan 09, 2020 at 11:02:30PM +0100, Kurt Roeckx wrote:

quoted

One thing the NIST DRBGs have is prediction resistance, which is
done by reseeding. If you chain DRBGs, you tell your parent DRBG
that you want prediction resistance, so your parent will also
reseed. There currently is no way to tell the kernel to reseed.

It would be simple enough to add a new flag, perhaps GRND_RESEED, to
getrandom() which requests that the kernel reseed first.  This would
require sufficient amounts of entropy in the input pool to do the
reseed; if there is not enough, the getrandom() call would block until
there was enough.  If GRND_NONBLOCK is supplied, then getrandom()
would return EAGAIN if there wasn't sufficient entropy.

Is this what you want?

I think some people might want to see it, but I think you
shouldn't add it.

Just for your information: I played with that already as seen in [1] which 
does not require any kernel change.

The only issue that is currently there are the two races noted in [1]. These 
races seem to be only addressable when the reseeding and the gathering of 
random numbers are atomic. I was toying with the idea that the RNDRESEEDCRNG 
allows the user to specify an output buffer which would be filled in an atomic 
operation when the reseed is invoked. That buffer should only be at most in 
size of the security strength of the DRNG.

[1] https://github.com/smuellerDD/lrng/blob/master/test/syscall_test.c#L101

quoted

quoted

I don't think we want that. As far as I know, the only reason for
using /dev/random is that /dev/urandom returns data before it
has sufficient entropy.

Is there any objections to just using getrandom(2)?

It provides the interface we want, so no. But there are still
people who don't have it for various reasons. OpenSSL actually
does the system call itself if libc doesn't provider a wrapper for
it.


Kurt

Ciao
Stephan