[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: regarding the changes to kernel entropy gathering
> Date: Mon, 5 Apr 2021 01:16:56 +0000 (UTC)
> From: RVP <rvp%SDF.ORG@localhost>
> Then, the issue here is one of predictability. NetBSD doesn't want,
> for extremely valid reason, to incorporate any perturbation sources
> which have been pooh-poohed in the technical literature.
Why do you say that? We do incorporate many sources that are not
well-studied -- every keystroke, for example, and the CPU cycle
counter at the time of the keystroke, affects the output of
We just don't _count_ these sources for the purpose of detecting and
reporting the potential security problem of low entropy, because we
don't have a good model by which we can confidently claim they are
actually unpredictable to an adversary.
> Or, perhaps statistical tests of the raw in-kernel sources will
> demonstrate exactly why things like timing jitter have been
> pooh-poohed in the literature?
What do you mean by `things like timing jitter have been pooh-poohed
in the literature'? Timing jitter in ring oscillators arising from
thermal noise in the silicon is the main source of entropy in most
on-die hardware RNGs on the market that I'm aware of. This design is
reasonably well-studied in the literature.
We even try to use something like it by default in NetBSD when nothing
else is available -- we use the periodic hardclock interrupt timer to
sample the CPU cycle counter, in the hope that these clocks are driven
by independent oscillators with some timing jitter.
However, this is a generic mechanism that works on any machine -- and
on some machines, there is no CPU cycle counter so it might fall back
to using the hardclock timer as a substitute, defeating the purpose.
And even if there is a CPU cycle counter, it might be clocked by the
same oscillator as the hardclock timer, &c. So we conservatively
count the hardclock entropy source as having zero entropy.
Main Index |
Thread Index |