> 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) Good point about the possibility of manipulation; it sounds a bit far-fetched but so did a lot of other exploits before they became a reality. > 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. Or carry forward entropy across reboots, provided that can be done without exposing another attack surface; or obtaining entropy from a trusted source if you can figure out how to make a secure connection with that source. My experience with "lean[ing] on device manufacturers" is not all that positive. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
