[openssl-users] PRNG is not seeded

chris.gray at kiffer.be chris.gray at kiffer.be
Thu Jun 7 19:38:25 UTC 2018

> 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

> 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

More information about the openssl-users mailing list