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 [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
