[PATCH v2] seedrng: limit poolsize to 256 bytes and document flock() and fsync() usage

[Jason A. Donenfeld]

Hi Steffen,

On Sat, Apr 30, 2022 at 8:50 PM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
>
> Jason A. Donenfeld wrote in
>  <CAHmME9p=NqMmKMetS_8UV4xNhwcjufjhf5sy32FrJnETaThK3Q at mail.gmail.com>:
>  ...
>  |Again, stop charging steadfastly toward creating vulnerabilities
>  |because you don't understand things. The scenario is:
>  |
>  |- RNG is seeded and credited using file A.
>  |- File A is unlinked but not fsync()d.
>  |- TLS connection does something and a nonce is generated.
>  |- System loses power and reboots.
>  |- RNG is seeded and credited using same file A.
>  |- TLS connection does something and the same nonce is generated,
>  |resulting in catastrophic cryptographic failure.
>
> But mind you.  Does the kernel _not_ incorporate system times and
> a few interrupts here and there unto this point already.  And some
> hardware crypto seed if available.  So if the _same_ nonce is
> generated even if a _VM_ is started a second time, inside the VM,
> which does generate its own random not virtio-rng, no matter what,
> then the system is broken per se.  Isn't it.

But mind you that you appear to misunderstand the problem space.

Many systems start with basically no entropy in pretty deterministic
states for a long period of time. The whole purpose of SeedRNG is to
mitigate this scenario by using a seed file.

> Haven't looked, but i'd assume that both the internal and the
> external pool (if it is done like this, i think it was so in the
> past) are not exposed but Blake2 (that you have chosen and were
> credited by Bruce Schneier for the decision) digested, what is
> used, then.  So assuming there is a sliding window on the internal
> seed pool that is actually digested (first), moving that window
> randomly is an option.  Ie like -fPIC swirling uses, but with
> a higher effective entropy as the internal seed buffer content is
> totally unknown.  So the mathematical formula that describes the
> theoretical actual entropy when done like this is stunning.
> You know, why always start at the beginning?  You know this of
> course.

This reads as complete gibberish to me, sorry. Please stop with this nonsense.

Denys - you see, this is what happens when you open the floodgates and
start trying to pick away at security properties in the service of 100
bytes or something: you pretty quickly veer off into madness. So again
I urge you to stop attempting to reduce SeedRNG's security model. I'm
happy to keep code golfing the implementation, and add any comments or
clarifications you need -- that's all good and productive and
sometimes fun too -- but I will not agree to reducing the security of
this or eliminating all error handling or something to that end.

Jason