Tom, > I think it nicely demonstrates a degree of sophistication that should > not be expected from typical PHP usrs.
Which is why it should be available in a library of some form. Could it be in core? Absolutely. Does it need to be? Nope... > [I don't think mixing mt_rand() + rand() + uniqid() + microtime() is > really much better than mixing only mt_rand() + microtime().] The key is not the sources, but how they are mixed. The RFC quoted shows how to mix in a way that as long as you have one non-compromised source, the final output is always at least as random as the strongest non-compromised source. In practice it will be significantly stronger since most compromises of sources are not total. > 1. PHP users cannot be trusted with access to the system's entropy> pool lest > they dangerously deplete it. Honestly, if you need to access the system's entropy pool, then go for it. But creating a new _rand() function will give easy access without any warning or frankly need. I'll explain later... > 2. Keeping things as they are protects the entropy pool from overuse. No, it makes it so that it's hard to *accidentally* use the entropy pool just because you saw the function somewhere. If you need it, it's there... With respect to the cs_rand() proposal, there is another argument against it. In PHP, there's *very* little use for a Cryptographically Secure random integers. There are significant uses for random strings, but not numbers. Sure, you can convert an integer to a string fairly easily. But it's actually pretty hard to do so in a manner that maintains the cryptographic security of the values... So why add a function that has little direct use, but can be significantly abused? Especially when using them for generating random strings can be difficult to the point where it's easy to generate non-secure strings from a secure source. If you want to add a cryptographically secure PRNG to PHP, add it so that it returns a string of the specified length. But again, I'm concerned about adding it since it will be abused. Even your original point about salts would abuse such a function. CSPRNs do have important uses. But they should NOT be used for cases where you don't truly need cryptographic security (as each use reduces the available entropy in the system, and can under certain circumstances make other secure applications less secure). 2011/12/21 Tom Worster <f...@thefsb.org>: > Hi Anthony, > > Thank your for your reply. I inserted some comments below. > > On 12/21/11 11:19 AM, "Anthony Ferrara" <ircmax...@gmail.com> wrote: > >>2. I was unable to do it. >> >>I did it fine. >> >>https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random > > I think it nicely demonstrates a degree of sophistication that should > not be expected from typical PHP usrs. > > >>It's an RFC4086 compliant CSPRNG >>(http://tools.ietf.org/html/rfc4086#section-5.2). It uses multiple >>sources to generate the final number, and mixes them together using >>cryptographically secure methods. Sure, in a perfect storm situation >>(Linux, Safe Mode, without OpenSSL, without MCrypt, etc) it would only >>use mt_rand() + rand() + uniqid() + microtime(), which is still pretty >>secure (in the sense that both bias and predictability are both >>virtually non-existent due to the mixing step). > > Right here you explain how your lib fails in exactly the same way that > my attempt did. I was surprised how common it is that PHP has safe mode, > and no mcrypt or openssl. The very first user of my function (other than > myself) reported this situation on two different platforms! So I don't > think it's right to call it a "perfect storm" because that implies that > it is very uncommon. > > [I don't think mixing mt_rand() + rand() + uniqid() + microtime() is > really much better than mixing only mt_rand() + microtime().] > > >>3. My proposal is to put a new function into basic_functions along >>side mt_rand(). I suggest naming it cs_rand() >> >>I would be against this proposal. CS random numbers are something >>that shouldn't be over used. Otherwise you can wind up either running >>out of entropy on the system (causing blocking while more is >>"gathered") or reducing the quality of the random numbers. I don't >>think normal developers understand the difference and when each is >>required. > > This argument is based on two premises that I don't accept > > 1. PHP users cannot be trusted with access to the system's entropy > pool lest they dangerously deplete it. > > 2. Keeping things as they are protects the entropy pool from overuse. > > The first is too presumptuous. Moreover, I don't think inhibiting > access through the PHP API design is the right way to mitigate against > such problems, it is too blunt a tool. > > The second is simply false in the case that one of PHP's 4 existing > APIs to the system CSPRNG is available. > > >>I would be for a proposal to add a salt generation function though >>(similar to BCrypt.gensalt()). > > This is a good proposal. But it's not an alternative, in my view. > > > >> >>Thanks, >> >>Anthony >> >>On Wed, Dec 21, 2011 at 10:31 AM, Tom Worster <f...@thefsb.org> wrote: >>> Hi, I'm new to this list so please tolerate my unfamiliarity with >>> protocol. >>> >>> PHP does not in general allow access to the underlying system¹s >>> entropy source. I think it would be a good idea if it did. >>> >>> It is routine for web developers to write code in PHP that stores >>> passwords in database tables or other persistent stores. In these >>> cases a one-way hash is generally used (and PHP¹s crypt() is very >>> good here). In such schemes, the password must be salted to >>> protect against known hash lookups. But the salt must be a >>> **cryptographically secure** random value. (This is just one >>> example of when a CS random value is needed, but a very common >>> one.) >>> >>> I recently attempted to write a function in PHP that would return >>> CS random bytes from the system¹s entropy source. I was unable to >>> do it. >>> >>> 1. /dev/random and /dev/urandom are unavailable on Windows and >>> cannot be fopen()¹ed in safe mode on *nix/nux >>> >>> 2. openssl_random_pseudo_bytes() requires openssl extension >>> installed and enabled. Most of the popular AMP packages for >>> Windows fail on this count. Many shared web hosts don¹t have it >>> either. >>> >>> 3. mcrypt_create_iv() depends on mcrypt extension and so suffers >>> similar problems as openssl >>> >>> 4. Another method is to set runtime config param >>> session.entropy_length followed by @session_start(); >>> session_regenerate_id(); after which session_id() will return a >>> CS random string, but this is also foiled by safe mode. >>> >>> 5. On Windows you could try COM('CAPICOM.Utilities.1')->GetRandom >>> but that API is obsolescent and not in many default Windows >>> installs. >>> >>> 6. Last chance is new DOTNET('mscorlib', >>> 'System.Security.Cryptography.RNGCryptoServiceProvider') etc >>> requires a working and compatible .NET framework. >>> >>> At this point the best bet is probably to hash some bytes from >>> mt_rand() with microtime() and return that but trigger a warning >>> about security. This is a very poor substitute. >>> >>> And given the routine need for CS random numbers in PHP >>> applications, it is, in my view, not satisfactory. >>> >>> My proposal is to put a new function into basic_functions along >>> side mt_rand(). I suggest naming it cs_rand(), cs being mnemonic >>> for crypto secure. It should appear in the same sections of the >>> manual as mt_rand() and rand() and both of those manual entries >>> should call out the fact that they are not crypto secure and refer >>> to cs_rand(). >>> >>> I propose an implementation broadly similar to mcrypt_create_iv(), >>> see php-5.3.8/ext/mcrypt/mcrypt.c lines 1373 thru 1434. (Even >>> though I haven¹t programmed in C since the 1980s, this doesn¹t >>> look hard.) >>> >>> But I suggest a different signature. openssl_random_pseudo_bytes() >>> is a better model. mcrypt_create_iv()¹s $source argument should be >>> avoided, it just confuses the user. >>> openssl_random_pseudo_bytes()¹s &$crypto_strong response is >>> valuable. I would also consider triggering a PHP warning when a >>> non-crypto strong value is returned. >>> >>> I would be happy to help with the work. I¹m not sure I¹d do a good >>> job with the implementation because I haven¹t programmed inside >>> PHP before while an experienced internist could do it very >>> quickly. But I may be able to help with test cases and >>> documentation. >>> >>> Warm regards >>> Tom >>> >>> >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: http://www.php.net/unsub.php >> > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
