Re: [dsfjdssdfsd] What has gone wrong with RNGs in practice

[Nick Mathewson <[e-mail]>]

On Fri, Nov 15, 2013 at 11:36 AM, Nick Mathewson <[e-mail]> wrote:
> Hi!
  [....]
> G. Using the same RNG state to generate two bitstreams.
>
> Example: The SecureRandom structure in Android was initialized once,
> and then used as the initial SecureRandom for multiple processes. This
> led to a large compromise in Android bitcoin wallets. [7]
>
> Example: Python had the same problem [8]: the same RNG state was used
> after fork.

I have received a correction for this one. The original reporter of
the Python bug (Christian Heimes) informs me that the bug is not in
the main Python secure RNG (which just reads /dev/urandom or the local
equivalent), but in OpenSSL's RNG as used in Python, which ought to be
reseeded or invalidated on fork() when Python is using OpenSSL, but
which is difficult to reset from an at_fork() handler because of
issues as discussed in [14].




Additionally, Tanja Lange mentioned [12] another category of
real-world vulnerability as discussed in [13].  These might be called:

J. Using unreliable hardware entropy sources directly rather than as
inputs to a PRNG.

(The cautious behavior is to design your PRNG such that it produces
good outputs if its inputs have *ever* been random enough.)

or

K. Omitting run-time tests for hardware entropy sources

While some failures are undetectable, it's just tempting fate to omit
tests for detectable failures of hardware components.



[12] https://twitter.com/hyperelliptic/status/401831967177461760
[13] http://smartfacts.cr.yp.to/analysis.html
[14] http://bugs.python.org/issue19227

best wishes,
-- 
Nick