* snip* >> Stas has the right approach, not only should the methods be simplified and >> platform/algorithm agnostic but have a proper salt built in (there are a >> few CSPRNG implementations around), I've seen salts used from numbers to >> md5's to just being skipped altogether. > > Well, just to be clear, a salt does not need a CSPRNG. All it needs to > be is reasonably unique. In fact, I wouldn't make it CS, as that would > deplete the available entropy in the system for CSPRNG generation.
Whether or not a CSPRNG is needed depends on what you're doing, your needed level of security. Perhaps add a parameter to control this, so it would be possible to make use of this function even if you need the maximum level of security? If it's not available, the function should fail in some suitable fashion. *snip* > Or, we could implement a system like I did in > https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random > that follows RFC4086: http://tools.ietf.org/html/rfc4086#section-5.2 > Where it mixes together several sources of weak and moderate strength > PRNG... Will the entropy multiply by mixing sources? I.e. will the result be "more random"? Won't it just be as random as the most random source? Other than that, the SPL version seems like a nice idea. Regards Peter -- <hype> WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 </hype> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
