H. Peter Anvin wrote:
On 06/13/2011 05:39 PM, Kent Borg wrote:
I was assuming that drivers, responding to an interrupt from some
external event, would want to make this call.
Such as a network driver.
Those already are doing this.
Two points:
1. Why look at the high-order bits? How are they going to have values
that cannot be inferred? If you are looking for entropy, the low-order
bits is where they're going keep it. (Think Willie Sutton.) If looking
at the low-byte is cheaper, then let's be cheap. If, however, if
looking at more bytes *is* as cheap, then there is no harm. But in any
case let's keep the code lean enough that it can be called from an
interrupt service routine.
Consider the case where the TSC is running in steps of 64 and you're
using the low 6 bits.
What if we mix the low byte into the pool, but only increase the entropy
estimate if a comparison with the prior read actually shows a change?
Another thought is to perhaps mix the counter value with a value read
from ansi_cprng, which is similar to a tactic referred to in NIST's
140sp750.pdf.
Peter, as long as I've got your attention here... Patch 3 in the set
adds essentially the same sort of support using the hpet instead of the
tsc. Is that less contentious, as far as precision in the low byte(s) to
provide entropy data?
My initial local implementation was actually hpet-only, before reworking
things to try to be more generic.
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
