Sam Leffler wrote: > gathering through fast paths. I've suggested for a long time that > this sort of collection should be enabled only under dire > circumstances and never by default. Regardless the last time I > looked at the entropy harvesting it used a model where entropy was > unilateraly sent for harvest and discarded when too plentiful. I > term this the "push model". I've advocated a "pull model" where the > PRNG requests entropy when a low water mark is hit and/or a hybrid > scheme where producers have some sort of flow control or feedback > mechanism. > > Everything that goes on inside the PRNG is a separate issue. > > Sam In general, by using a push model, you open yourself up to the possibility that the attacker could exhaust the entropy at just the right time so he can control what entropy is harvested on the next run of the PRNG. But in this case, we might be able to get away with it, since the PRNG is still cryptographically strong even when there is no new entropy flowing into the system (as long at the attacker doesn't know the initial state of the pool). Rekeying and reseeding the pool are primarily to give you forward security and to recover if the entropy pool has been compromised. But a push system is still better if it doesn't impact performance too much. Richard Coleman rcoleman_at_criticalmagic.comReceived on Thu Aug 05 2004 - 12:32:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:04 UTC