Bitcoin Forum

Does this effect any bitcoin address created from a wallet on Linux?

Insecurities in the Linux /dev/random (https://www.schneier.com/blog/archives/2013/10/insecurities_in.html)

New paper (http://eprint.iacr.org/2013/338.pdf): "Security Analysis of Pseudo-Random Number Generators with Input: /dev/random is not Robust, by Yevgeniy Dodis, David Pointcheval, Sylvain Ruhault, Damien Vergnaud, and Daniel Wichs.

    Abstract: A pseudo-random number generator (PRNG) is a deterministic algorithm that produces numbers whose distribution is indistinguishable from uniform. A formal security model for PRNGs with input was proposed in 2005 by Barak and Halevi (BH). This model involves an internal state that is refreshed with a (potentially biased) external random source, and a cryptographic function that outputs random numbers from the continually internal state. In this work we extend the BH model to also include a new security property capturing how it should accumulate the entropy of the input data into the internal state after state compromise. This property states that a good PRNG should be able to eventually recover from compromise even if the entropy is injected into the system at a very slow pace, and expresses the real-life expected behavior of existing PRNG designs. Unfortunately, we show that neither the model nor the specific PRNG construction proposed by Barak and Halevi meet this new property, despite meeting a weaker robustness notion introduced by BH. From a practical side, we also give a precise assessment of the security of the two Linux PRNGs, /dev/random and /dev/urandom. In particular, we show several attacks proving that these PRNGs are not robust according to our definition, and do not accumulate entropy properly. These attacks are due to the vulnerabilities of the entropy estimator and the internal mixing function of the Linux PRNGs. These attacks against the Linux PRNG show that it does not satisfy the "robustness" notion of security, but it remains unclear if these attacks lead to actual exploitable vulnerabilities in practice. Finally, we propose a simple and very efficient PRNG construction that is provably robust in our new and stronger adversarial model. We present benchmarks between this construction and the Linux PRNG that show that this construction is on average more efficient when recovering from a compromised internal state and when generating cryptographic keys. We therefore recommend to use this construction whenever a PRNG with input is used for cryptography.

If I remember correctly, OpenSSL on Linux uses /dev/random and time(NULL) for generating a seed for the private keys.

No. It is not indicating any insecurity in any meaningful sense. It basically says that if an attacker captures your kernel internal random number state (how?) and then controls the input into the RNG (how?) the problems with the entropy estimator can make the output remain deterministic to them.

It's interesting from a cryptography perspective, but they are not suggesting that this is a weakness which matters in any normal application.

(It's also worth pointing out that their suggested "fix" is to replace /dev/random with what is fairly similar to AES-GCM with the galois counter perturbed by input randomness. Considering people's violently negative response to Intel's bull mountain AES based rng, I can't see something like their proposal being adopted anytime soon)

/dev/random's maintainer responds (https://news.ycombinator.com/item?id=6550256).