I don't know why everyone says the internals list is so scary - you guys are great! :)
> I think the function name(s) should indicate that these functions are for getting crypto-secure randomness. I proposed cs_random_bytes() I'm cool with that idea but I also think it should be spelled out like ` random_crypto_*()` as Pierre suggests. I like `secure_random_bytes()` but that's because it's what Ruby names their CSPRNG. :) http://ruby-doc.org/stdlib-2.1.2/libdoc/securerandom/rdoc/SecureRandom.html But really a moot point. > CS random strings are often required but I haven't ever seen requirements for arbitrary alphabets, charsets and encodings. In Yii we provided a method that returns a string using the 64-character set [a-zA-Z0-9_-] which is nice because they are all transparent in URLs. There are many uses for such strings and it seems to meet the needs of most users, as they haven't requested more flexibility. I actually started down this RFC path out of frustration on this very point of needing secure random alphanumeric stings. The originally RFC & patch contained a `random_hex()` function that would convert bytes from the CSPRNG into hex. The use case that I have seen most needed in user-land is in fact for random alphanumeric strings so that they can generate CSRF tokens. Every CRUD app could be affected by this. So I'm still +1 for having a built-in function to get back arbitrary alphanumeric strings. But this can be done with `bin2hex(random_bytes(16))` or `base64_encode( random_bytes(16))` so I won't fight it too much. :) > I welcome the proposal for an easy-to-use PHP function for obtaining > crypto-secure randomness. > I love this addition and it is cruelly needed :) Yay! Lots of love for a CSPRNG! :) Thanks, Sammy Kaye Powers sammyk.me 230 S Clark St #194 Chicago, IL 60604
