Secure random numbers for PHP developers

[Timo H]

Hey all,

yesterday I posted a small blog post about random numbers in PHP: http://timoh6.github.io/2013/11/05/Secure-random-numbers-for-PHP-developers.html

I outlined a few common common quirks related to secure random number generation in PHP and (to put it short) suggested that we should just trust the experts and simply get the random numbers from /dev/urandom.

[Kevin McArthur]

Hi Timo,

/dev/urandom is an exhaustible source and therefore it is not theoretically suitable for direct use in cryptography. (esp on a webserver where entropy exhaustion may be forced through repeated requests)

You should not read large volumes of random from the kernel, and instead should use it to seed a crypto-secure prng (as openssl does); here's why

"

       The kernel random-number generator is designed to produce a small
       amount of high-quality seed material to seed a cryptographic pseudo-
       random number generator (CPRNG).  It is designed for security, not
       speed, and is poorly suited to generating large amounts of random
       data.  Users should be very economical in the amount of seed material
       that they read from /dev/urandom (and /dev/random); unnecessarily
       reading large quantities of data from this device will have a
       negative impact on other users of the device.

"

http://man7.org/linux/man-pages/man4/random.4.html

Keeping an eye on the forking issue, and understanding where the openssl random is being seeded (ie, that you're not cloning the random generator's seed) is important, but directly reading urandom isnt really the solution either and may result in problems down the road.

--

Kevin McArthur

--
You received this message because you are subscribed to the Google Groups "PHP Security Technical Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sectg+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Timo H]

Hi Kevin,

I believe the current understanding on the field is that Linux urandom will be fine. The answer by Thomas Pornin, which I linked from the post says:

> The man page for urandom is somewhat misleading, arguably downright wrong, when it suggests that /dev/urandom may "run out of entropy" and /dev/random should be preferred; the only instant where /dev/urandom might imply a security issue due to low entropy is during the first moments of a fresh, automated OS install; if the machine booted up to a point where it has begun having some network activity then it has gathered enough physical randomness to provide randomness of high enough quality for all practical usages

http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939

According to that and the other indications (i.e. https://news.ycombinator.com/item?id=6216101)

> Secure programs should rely on /dev/urandom, to the exclusion of other CSPRNGs, and should specifically eschew userland CSPRNG engines even when they're seeded from /dev/urandom.

I believe this stands on the web app scenario too. Thoughts?

Timo

[Kevin McArthur]

Timo,

I'd take that with an enormous grain of salt. The discussions there talk to repeating output (which is never the problem)... The issue rather is that the output is correlated to some known state that the attacker can control, then predict or produce collisions to reduce the effective security. I would suggest that the urandom man page is correct, though the scenarios for making it run out of entropy are similar to the scenarios to making /dev/random block and are not well defined. If your php script results in a read from urandom, then what are the implications to 100,000 calls to that page, does the information available to the attacker betray the state of the rng over many observations if the entropy pool is exhausted? Lots of speculation in this area, but very little in the way of a 'proof'.

Bottom line, I'd recommend the cprng approach rather than reading urandom. However, I just checked openssl.c in PHP and that /totally/ needs an audit and has different rand seeding methods going on depending on the function. (Bring on the debate about whether popen to openssl rand is the right approach)...

Only thing thats clear here is that finding good sources of entropy in real-world web systems is very difficult. I would be nervous making any concrete recommendations for <this is how you do it> at this time.

--

Kevin

[Timo H]

Interesting.

I was not able to find practical security issues reported on urandom (excpect those things mentioned, like cold boot on "special" devices and the first moments of a fresh, automated OS install etc). It seems if the OS is running on a regular server hardware and it is connected to the network, it will be able to keep the internal state to contain enough entropy unknown to the adversary. Of course this is just my speculation, and I prefer to follow what is said on the crypto community.

Would be great to get some feedback from the crypto community on this, especially on how urandom stands under an active attack on web app situation (like if the app leaks, say, 32 bytes of raw data from urandom on every request).

Timo

[Kevin McArthur]

My guess would be that urandom will deplete at about the same frequency that /dev/random will block. We know there to be problems using /dev/random in web apps (ddos via deliberate blocking for example), so if that assumption is correct, it would follow that you can force depletion of urandom in a similar way, except it wont block. Think of this as a soft-fail pattern, random if available, but deterministic if depleted? Are there active exploits in this area? I'm not sure how researched it is, as the man page is pretty clear -- don't do this. Overriding the manual recommendation would tend to require extraordinary proof, which I'm also not seeing.

When it comes to entropy, its usually good to apply the same thinking as you would about a perpetual motion machine. The reason I'd be weary of urandom depletion is that I dont know what it does once its depleted -- is it recycling a massive pool in the way the cprng's do? Does it give any assurances that when recycling that the algorithm doesn't reveal state the way the cprngs do? That said, I've not looked at the kernel code around urandom myself so I have very little idea of what its doing in that scenario and what assertions its making.

--

Kevin