Hey Tom, On 25 February 2015 at 19:39, Tom Worster <f...@thefsb.org> wrote: > 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.]
That's true, but you're going to have to be really unlucky for it to have any significant impact. The worst case for a re-roll comes with a probability of 0.5, and best case is 0.0. I did actually notice that I've made the implementation worst-case by default when catering for a negative lower bound. It's on my list to see how I can improve it. > 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. On modern OpenBSD/FreeBSD/OSX /dev/random and /dev/urandom are both aliases of /dev/arandom, which is quite literally an inexhaustible supply of CS random backed by arc4random. On Linux I think you'll be hard pressed to exhaust /dev/urandom from a minute or two after boot. We're still discussing whether a userland (non-kernel userland) implementation of arc4random is wise. We need to put some feelers out and consult some experts on this, but if we do implement it, the same is true. Inexhaustible CS random. Otherwise as mentioned, /dev/urandom is going to be good enough. > 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. At present I think we've picked the most appropriate sources and precedence for these sources, without getting into the realm of a portability nightmare. > 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. We certainly do not want to expose this, or allow the user to choose. > 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() We thought the current naming was enough to distinguish between the well known (to be bad) rand(), and true random. As Anthony says, we don't want to use a prefix that's meaningless to the majority. I'd be open to renaming with a "crypto_" prefix if it is deemed necessary. > - 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. Absolutely. We pick the best available so that the user does not have to. If there is no source of CS random available, the function issues a warning and returns false. > - A function to get a random text string drawn from the 64-byte > alphabet of URL-transparent chars is very useful. We've tossed this idea around a bit OTR, a potential function called random_token(). We need to somehow make it clear that this is not to be used for keys or IVs, but it's a good fit for things like session IDs or CSRF tokens. > - Don't offer a crypto-secure random integer getter unless the > requirement for such a thing is clear. The random_int function will always provide an unbiased result. An example use-case brought up recently was in the case of online games, where a bias could give players an upper hand if they knew the subtleties of the underlying RNG. Thank you for your feedback! Leigh. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
