Tom, On Wed, Feb 25, 2015 at 2:39 PM, Tom Worster <f...@thefsb.org> wrote: > 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.
Agree 100%. > - Name the functions so the crypto-secure feature is obvious, e.g. > cs_random_bytes() I'm less sure on this point. I think people will get confused "what's the difference between mt_rand and cs_random?" and then just use rand() anyway. I think the way we solve this is though documentation instead. Keep the name simple, and document it well... > - 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. Agree 100% > - 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. Well, there are cases such as UUID generation, contests, etc which need to pick numbers in a defined range. Also, if it's a drop-in replacement for mt_rand, so existing could could be migrated without having to be rewritten (a bonus for legacy users). Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
