On Wed, Feb 25, 2015 at 2:40 PM, Leigh <lei...@gmail.com> wrote: > 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.
Do you mean to maintain our own CSRNG based on arc4random (algorithm)? I seriously hope it is not the case. >> 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. Minus the entropy setting, which should be system or create one a sysadmin can actually change according to its need. The use cases I mentioned before are not only about some labs R&D or other edge cases, there are actually quite a large amount of users that would benefit from that. Mass hosting is one and the trend of the densification of app servers using containers only increase that need, drastically. Providing such setting (system, not INI_ALL) won't affect the exposed APIs in any way nor make the API itself less "secure". >> 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. It is a system decision, not a developer (which are most likely no idea about it). Systems usually do. >> 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. I hope as well you are not going to deprecate (or whatever else close) these functions. Move the note about them not being cryptosafe as a big red warning down the function signature (in the manual) should be enough. > 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. I'd to go with that, or actually random_crypto_*. While the only one actually accurately CS will be 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. > > 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. it should not even build. As far as I remember it is what happens with session.entropy* >> - 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. <hint>session.entropysource...</hint> :) We should duplicate features, settings. I said that back then while asking for a general entropy source settings we should use in PHP, users can rely on (fopen back then) and upcoming new random functions can use. That point did not change, we should still not duplicate a feature and confuse users. This is the same thing. >> - 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. Which can be possible in some cases. I had this situation in this exact case, for games. I actually have it in offline games as well where one was able to manage to get sequences out of many printed random numbers and figure out the actual randomness (or lack of) of some sequences due to the reduction of the entropy quality introduced by integer ranges only. just for the story. He earned some money with that, until the trick was discovered ;) Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
