Hi Anthony, Thanks again for your time responding.
On 12/21/11 2:35 PM, "Anthony Ferrara" <ircmax...@gmail.com> wrote: >Tom, > >> I think it nicely demonstrates a degree of sophistication that should >> not be expected from typical PHP usrs. > >Which is why it should be available in a library of some form. Could >it be in core? Absolutely. Does it need to be? Nope... Under the hood there is php_win32_get_random_bytes(). But there is no consistent way to access it. Rectifying that in PHP is easy and is, in my view, the right way to get CS random bytes on Windows. > >> [I don't think mixing mt_rand() + rand() + uniqid() + microtime() is >> really much better than mixing only mt_rand() + microtime().] > >The key is not the sources, but how they are mixed. The RFC quoted >shows how to mix in a way that as long as you have one non-compromised >source, the final output is always at least as random as the strongest >non-compromised source. In practice it will be significantly stronger >since most compromises of sources are not total. The entropy coming out of the mixer cannot be bigger than the entropy going in. A good mixer is important if you have more than one source of real entropy and need to combine them. I do not believe this is the case here. mt_rand() and rand() are not random in any CS sense so the entropy they contribute should be counted as zero. In the situations we are discussing, uniqid() also adds no entropy because it fall back on the same microtime() that you have in your function. So the entropy going into the mixer is whatever you you think microtime() provides. Considering unknown clock resolution and that digits above 100ms, say, are predictable, maybe 20 to 25 bits? Not much more anyway. Best you can do is reply to the caller with 2 or 3 bytes of result based on that. But now you have to refuse subsequent calls because microtime() will give no more entropy unless the time between calls to it are truly random. 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. >> 1. PHP users cannot be trusted with access to the system's entropy> >>pool lest they dangerously deplete it. >Honestly, if you need to access the system's entropy pool, then go for >it. But creating a new _rand() function will give easy access without >any warning or frankly need. I'll explain later... > >> 2. Keeping things as they are protects the entropy pool from overuse. > >No, it makes it so that it's hard to *accidentally* use the entropy >pool just because you saw the function somewhere. If you need it, >it's there... > >With respect to the cs_rand() proposal, there is another argument >against it. In PHP, there's *very* little use for a Cryptographically >Secure random integers. There are significant uses for random >strings, but not numbers. Sure, you can convert an integer to a >string fairly easily. But it's actually pretty hard to do so in a >manner that maintains the cryptographic security of the values... So >why add a function that has little direct use, but can be >significantly abused? Especially when using them for generating >random strings can be difficult to the point where it's easy to >generate non-secure strings from a secure source. Actually what I want is a function that returns a string of random bytes. I guess I confused matters with the proposed name. Ideal would be something identical to openssl_random_pseudo_bytes() but not dependent on any extension, compile- or run-time option. >If you want to add a cryptographically secure PRNG to PHP, add it so >that it returns a string of the specified length. But again, I'm >concerned about adding it since it will be abused. Even your original >point about salts would abuse such a function. CSPRNs do have >important uses. But they should NOT be used for cases where you don't >truly need cryptographic security (as each use reduces the available >entropy in the system, and can under certain circumstances make other >secure applications less secure). That's reasonable. I am inclined to the view that users who actually need a CS string should be catered to. Idiot users will always have, and have always had, the opportunity to spoil the utility of a multi-user system for the other users. And it should go without saying that they cannot be protected from themselves. Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
