Of course people have been harvesting entropy, or trying to, from network sources for decades. There's a famous paragraph regarding it in RFC 4086, which is an expanded version of a similar statement from RFC 1750 (1994):
Other external events, such as network packet arrival times and
lengths, can also be used, but only with great care. In particular,
the possibility of manipulation of such network traffic measurements
by an adversary and the lack of history at system start-up must be
carefully considered. If this input is subject to manipulation, it
must not be trusted as a source of entropy.
(RFC 4086, 3.5)
More generally: It's often possible to harvest quite a bit of information that can't be adequately predicted or statistically modeled by an attacker from network sources, and these days distilling CPRNG entropy from such inputs is straightforward thanks to the use of cryptographic compression functions. It's the edge cases that bite you. 4086 mentions attacker manipulation (flooding network sources with known data to flush entropy out of the pool) and start-up (if you don't have persistent storage of adequate seed material). Embedded devices may suffer from too little, or too predictable, network traffic in their limited reception area.
You can get stronger guarantees from hardware entropy devices, which are cheap (in every sense: component cost, power consumption, size, ...). So there's not a lot of incentive to do more research into gathering entropy from external sources - it makes more sense to lean on device manufacturers, or use add-on devices.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
