Thanks for your input Pierre,
On 12/21/11 2:25 PM, "Pierre Joye" <pierre....@gmail.com> wrote:
>hi,
>
>Some short comments:
>
>On Wed, Dec 21, 2011 at 4:31 PM, Tom Worster <f...@thefsb.org> wrote:
>
>> 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 does on unix using the almost generally available random and
>urandom. On Windows you can use the openssl_random_pseudo_bytes
>function which does not rely on the OpenSSL API but the Windows native
>Crypto APIs.
Often -- yes. But generally? Not in the sense that you have described a
_general_ approach to a solution.
I have found that users have complained that they are in these situations.
One user said that in one production environment he had Windows without
crypt or openssl and in the second he had linux with safe mode and cannot
use session_id(). This was within a few days of sharing my code with a few
users to try it out.
I then did some experiments and found the issues with default configs in
the three wamp-type packages I tried.
These difficult situations arise often enough to be a problem.
>
>> 1. /dev/random and /dev/urandom are unavailable on Windows and
>> cannot be fopen()¹ed in safe mode on *nix/nux
>
>Well, bad admins forgot to allow access to these files. Maybe we
>should add that to the documentations.
That would not hurt.
Bad admins are not extremely unusual. A lot of design decisions in PHP
have been driven by the practicalities of real life situations.
>
>> 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.
>
>See my previous comment about windows.
>
>For shared hosts not providing openssl, I would suggest (strongly) to
>look for better hosting solutions.
I would too. But it is not always an option for the software developer.
>> 3. mcrypt_create_iv() depends on mcrypt extension and so suffers
>> similar problems as openssl
>
>How so? The entropy source on windows is the same than the one in
>openssl and uses the windows crypto API.
I mean that use of mcrypt_create_iv() depends on availability of mcrypt
extension as use of openssl_random_pseudo_bytes() depends on the
availability of openssl extension. Perhaps I should have said "analogous
problems" instead of "similar".
>
>> 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.
>
>Btw, entropy src on windows benefits from the same implementation than
>mcrypt and openssl.
Yes indeed. These are three different PHP APIs that access the same thing,
CryptGenRandom, which is the only thing on Windows one can call CS random.
Unfortunately there are situations in which none of these three work.
>> 5. On Windows you could try COM('CAPICOM.Utilities.1')->GetRandom
>> but that API is obsolescent and not in many default Windows
>> installs.
>
>That's what the random bytes function uses. Or to be more exact,
>CAPICOM uses the same same underlying API.
Yes. It's all about getting to CryptGenRandom.
>> 6. Last chance is new DOTNET('mscorlib',
>> 'System.Security.Cryptography.RNGCryptoServiceProvider') etc
>> requires a working and compatible .NET framework.
>
>Same comment as in pt. 5
Yes.
>> 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.
>
>They are by no way crypto safe. Openssl's random function on unix can
>fail to be crypto safe as well. On windows, it is always crypto safe.
I believe CryptGenRandom like /dev/random can report that the entropy pool
is depleted or inadequate. Situations when you really need so many bytes
of entropy that the system's source cannot provide them are unlikely, but
well designed software would allow for the possibility.
Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
