On 12/28/11 4:36 PM, "Anthony Ferrara" <ircmax...@gmail.com> wrote:
>Tom, >First off, /dev/random doesn't report anything. If the entropy pool >is depleted, it will block until it has enough entropy to fufil the >request. On Linux, yes. Not on BSD or OSX. I don't know about others. > That may seem good, but it's a HUGE DOS vulnerability if you >are using them for non CS applications (which the VAST majority of PHP >applications fall into). Even Linux is ok if users users will just RTFM. The Linux random(4) man page explicitly says "Since reads from /dev/random may block, users will usually want to open it in nonblocking mode (or perform a read with timeout), and provide some sort of user notification if the desired entropy is not immediately available." It also says that /proc offers: "The read-only file entropy_avail gives the available entropy." Which is what I meant by reporting its status. >Secondly, you seem to be under the impression that you can secure >anything on a shared host. The truth is that by very nature a shared >host will always by cryptographically insecure. That's because you >don't have access to the underlying system. Not running the very >latest kernel? You're not secure. Having applications on the same >server that hit the CS entropy pool unnecessarially? That's not >secure. If you don't have access to the config, it's not secure >(since someone can chroot your vhost, and point /dev/random to another >compromised entropy source)... > >In short, if you don't control the system from the top to bottom, you >can't have cryptographic level security... Fair points but not germane to my main argument: I proposed that the base PHP API should allow the PHP programmer uniform access to the system's CS random byte source, which is CryptDevRandom on Windows. My proposal was countered by pointing out ways the runtime environment can be configured to provide access. I responded to that with the claim that the PHP programmer sometimes has no control over the runtime environment. I believe this should not prevent her from delivering portable, quality code. It is often somebody else's job to secure the runtime environment. >> CryptGenRandom is a FIPS verified CSPRNG. I am no cryptographer or >> security expert but I would not attempt to pass off mixing up >>microtime() >> to anyone that is. > >If you're implementing applications that require FIPS certification, >you're not doing it on a shared host either. So that argument is >moot. I'm not trying to talk up anything else, or talk down >CryptGenRandom. Instead, I'm pointing out that achieving an >acceptable quality RN for **MOST** uses should not call >CryptGenRandom. Instead, it should use PseudoRandom numbers. I did not intend to imply that a FIPS verified system should be a goal. My intent was to contrast the well scrutinized CryptGenRandom with microtime() as source of random bytes. >I tried to avoid the Ad Hominem argument (if anything sounded like >that, please forgive me). Not at all. Afaict, we just disagree on some fine points and on the general stance wrt what a PHP programmer should be allowed in the API. >I hope that clarifies things from my point of view... Yes, thanks. As a noob here, what should I do next in order to pursue my objective? Is this what the PHP RFC is for? Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
