I welcome the proposal for an easy-to-use PHP function for obtaining crypto-secure randomness. I have a number of comments and suggestions.
I think the function name(s) should indicate that these functions are for getting crypto-secure randomness. I proposed cs_random_bytes() previously (https://wiki.php.net/rfc/csrandombytes) and I still it works. First, it's important that users understand this distinction. Second, given all the shared environments, it's good for the world at large if people aren't draining the operating system's "entropy pool" for work that doesn't need crypto-secure randomness, e.g. Monte Carlo simulations that are better served with a different source. CS random strings are often required but I haven't ever seen requirements for arbitrary alphabets, charsets and encodings. In Yii we provided a method that returns a string using the 64-character set [a-zA-Z0-9_-] which is nice because they are all transparent in URLs. There are many uses for such strings and it seems to meet the needs of most users, as they haven't requested more flexibility. I don't understand the requirement for crypto-secure random integers. I have never encountered this requirement. [Btw: the proposed patch implements this function using a loop that's not guaranteed to terminate in any given amount of time.] I believe that simplicity is of *paramount importance*. I also believe in only addressing the requirements of 90% of the users if addressing the 10% specialists means complicating the API and adding potential footguns. For example, the number of users that actually need to do something better than read from /dev/urandom is small. A user that is concerned about the status of the system's "entropy pool" (whatever that might mean) or that feels the need to check the "degree of seededness" of the system's CSPRNG (again, whatever that might mean) is a very specialized user. There's no need to cater to them in these "Reliable, userfriendly RNG APIs". The (metaphorical) 1% can look after themselves. Whatever its size, it's a small minority that genuinely cannot accept the kind of randomness that /dev/urandom on Linux or /dev/random on FreeBSD or OS X offer. Further, the concepts of seededness of an RNG are very advanced matters that are not well understood and that vary from one system to another. Standardizing these semantics across platforms is hard. So making these complications portable over different operating systems is, I imagine, beyond difficult. And if you aim to make an API that exposes such subtleties, you need to be able to clearly explain in the manual what it means in both technically accurate terms and in practical terms that a non- specialist application developer can base a design decision on. I certainly couldn't do that. To, to summarize. - The requirement for a easy-to-use function to obtain crypto-secure randomness is very clear. Has been for years in my view. - Name the functions so the crypto-secure feature is obvious, e.g. cs_random_bytes() - The functions should not expose or allow selection of degrees of "strength" of crypto-secureness (it's both a footgun and a semantic tar pit). Just use the non-blocking system source and make a note in the manual so the specialist users know what's going on. - A function to get a random text string drawn from the 64-byte alphabet of URL-transparent chars is very useful. - Don't complicate the random string getter without first establishing the requirement for such complication. - Don't offer a crypto-secure random integer getter unless the requirement for such a thing is clear. Otherwise, great stuff, good luck! Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
