On Feb 24, 2015 12:04 PM, "Anthony Ferrara" <ircmax...@gmail.com> wrote: > > 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?
Increase is the point and it is one of the reasons why we made a setting for the session entropy. > >> 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). Not always. And not always desired. Also as pointed out in a another reply it could be an API (but that goes for a next step about this feature). > 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. Yes, driver based. That brings some risk but worth exploring this possibility. > 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? You actually reduce the data set, bytes level or higher, the randomness of the data is then restricted or limited and sequences may happen, worst case it could make it less hard (or easier) to predict. I have seen these cases in a couple of projects which rely heavily on entropy. > That's my stance at least. > > Anthony I
