Re: FYI/RFC: early-rng-init-tools

[Sam Hartman <hartmans@debian.org>]

>>>>> "Thorsten" == Thorsten Glaser <tg@debian.org> writes:

    Thorsten> It’s not about what we feed to the kernel, but about the
    Thorsten> property of it distributing the input evenly across the
    Thorsten> output. The basic tenet here is that, if I have 128 bytes
    Thorsten> of random input from the seed file, then, if I write the
    Thorsten> output of an SRNG to both the kernel and back to the seed
    Thorsten> file, each has about 128 bytes worth of entropy iff only
    Thorsten> one is used (and somewhat less otherwise, but, again,
    Thorsten> according to tytso and I believe even Ben in some Debbug
    Thorsten> against OpenSSL, 16 or 32 bytes of input “should be
    Thorsten> enough”).

Not exactly.
The entropy is also capped at the internal state of your SRNG whatever
it is.
I'd strongly  recommend finding a design where you don't use your own
RNG and just use the kernel's RNG entirely.

I think it complicates the analysis and may introduce problems to have
multiple PRNGs involved: your security is the weakest link in this
instance.

Let me see if I understand the issue that makes this hard for you.

You want to  avoid crediting the entropy before the new seed is written.
You cannot call getrandom before you credit the entropy.
So you cannot use getrandom to  produce the new seed file.

That's ugly, and if I've got it right, I at least understand your
constraints.

I'd probably do something like:

1) read the seed file

2) remove the seed file; fsync the directory.

3) write to kernel; credit the entropy

4) mix in other stuff

5) call getrandom and generate a new seed file.

You're in a bad position if you crash between reading and writing the
seed file, but I think your other options are also bad.