>>>>> "Thorsten" == Thorsten Glaser <t...@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.
