> > > Anyway, unusable CSPRNG is very unlikely to happen. I may just use > > UNEXPECTED macro for the if branch. > > > > I changed my mind due to comment for uniqid() CSPRNG usage. > > IMO, there is no benefit for CSPRNG failure fallback. We shouldn't add > fackback for every CSPRNG usage.
Right, we absolutely should not. Most usages of a CSPRNG require a CSPRNG, while mt_rand and uniqid do not, so it's a different case here. > It's just does not make sense. Are we > going to add poor fallbacks for every CSPRNG usage? I strongly against it. > > CSPRNG failure is like BUS error, i.e. hardware error. CSPRNG shouldn't > fail with healthy hardware/OS. Therefore, we should not add poor fallback > code for it. A CSPRNG is not necessarily a hardware error. PHP might run on weird platforms, no? Anyway, the "issue" with mt_rand is not the seed being predictable but the internal state being recoverable from the output. But mt_rand is predictable by design, so why should we even seed it with a CSPRNG by default? Regards, Niklas
