Power management is an issue. Therefore entropy collection cannot be
periodic, not with high frequency anyways.
Instead collection must happen as needed and/or opportunistically, and
as much entropy should be collected as possible without increasing
latency by too much. Opportunistic collection is fine, but
opportunistic pushing into the mixer when there's no demand for CSPRNG
outputs... is not power management friendly.
Therefore:
- for initial CSPRNG seeding the question is irrelevant: whether
push or pull, we must wait until we have enough entropy from all the
sources at hand;
(since we're blocking and there may/should be multiple sources,
some of which may involve slow I/O, async/concurrent polling is
necessary so as to wait no longer than we must wait for the slowest
source)
- for opportunistic (but not periodic, at least not with short
periods) mixing-in of new seeds, mixers should use consume entropy
from all pools that have available entropy, without discriminating as
to origin (since, after all, we're positing a properly-seeded CSPRNG).
Remember, we started this long set of long threads because of a paper
about /dev/urandom robustness. The assumption is partial compromise,
and the goal is to recover (i.e., cause the attacker's knowledge of
CSPRNG state to become stale) quickly. Suspend/resume, buses that
allow external device-initated DMA to all physical memory, ... these
are potential sources of partial compromise.
Anytime there's a suspend event the system should encrypt sensitive
state (e.g., filesystem keys, CSPRNG state), and decrypt it on resume.
Since the encryption key in that case is likely to be a
password-derived (i.e., weak) key, or it may be missing altogether
(the user doesn't want to bother), CSPRNG reseeding on resume is...
highly desirable.
Nico
--
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
