Pierre, >> In fact I had planned for a future RFC where we allow >> session.entropy_file to use using random_bytes(). So the "best" source >> is chosen automatically. (If you think there are better sources not >> covered by this patch, please let me know, I would like it to be >> complete) > > I rather prefer to be able to choose. Maybe make it system instead of > INI_ALL if the users ability to choose wisely are questionable.
Why? Why should the user change their entropy location? What benefits (especially from only a system perspective) does that provide to users/sysadmins? Besides letting an admin decrease the security of a security API? >> There is an aspect of this that has been left for "future work", but >> if the list thinks it is important I can implement it for this RFC. >> The issue is that on Linux it still does not provide a way of getting >> random bytes without using a file descriptor. This is important for a >> couple of reasons, 1) It means chroot environments don't require >> /dev/*random 2) it prevents fd-exhaustion attacks that force lower >> quality randomness. LibreSSL-portable has a very good implementation >> of this using the Linux getrandom syscall (Kernel >= 3.17) that I can >> phpise and include if we think it is necessary. > > It is all the same setting. What is done on windows can be applied on any > other platforms. Either use a path or a method, it just works fine. > > There are many different RNG providers, daemons or other services. I have > seen customers using some of them (together) to generate enough data for > their needs (need a lot of entropy data). By enough data I mean to be 200% > sure that the entropy is good enough at any time no matter how much data is > being fetched. Yes, and they all can feed into /dev/arandom and /dev/urandom. In fact that's how those systems are designed to operate (taking in entropy from many sources). PERHAPS, it could be written in such a way that a PECL extension can alter the RNG to accommodate that usecase. But I'd be wary of that and core supporting userland RNGs. I think one of the mistakes that password_hash made was exposing the salt to the user. If you give users a choice with respect to security, they will on average make it worse (based on plenty of code snippets I've seen, that's the case with salt generation). I think the case you have to look at here is the target audience. Are you looking to be all things to all users? Or are you attempting to be an opinionated tool to help the 99%. Along with password_hash, I think this random library serves the 99%. It shouldn't try to be all things to everyone, because then it will confuse or complicate things for the 99%. The reality is we've been lacking a simple API for years. Seeing what users implement in the wild shows that. To quote a phrase I coined years ago: It should be easier to get right than to screw up. And that includes using existing APIs. So if random_int() is harder than mt_rand(), it's a non-starter. If random_bytes() is harder than uniqid(), it's a non-starter. > I am also unsure about random_get_int, why only integer? It is also > important that doing so the results is per se not crypto safe anymore. But > still handy for codes required random integers (or other types). If it is > kept, I would also prefer to name it random_get_<type> instead, for clarity. How is it not crypto safe? It uses a non-biased algorithm using a crypto-safe primitive. As far as why only integer, a float can always be added to. But strings are already supported, and what other types do you need? That's my stance at least. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
