FAQ
I've been trying to catch up on the plans in PHP 7 for changes in security
features and APIs and I got confused. Questions on my mind at the moment
include:

1. Will there be a portable API for getting random bytes from the
platform's CSPRNG?

https://wiki.php.net/ideas/php6 lists as an addition: "Reliable,
userfriendly RNG APIs: Provide a userfriendly and reliable RNG APIs,
available by default, on all supported platforms and for all usages
(from weak to crypto safe)."


2. What's going to happen to mcrypt?

I see the vote to excise it did not pass. Does this mean that (i.e.
imply that) PHP's plan is to keep a security lib that hasn't been
maintained for 8 years for the next 5+ years?


3. Will the OpenSSL ext remain as it currently stands?

There have been a few discussions about this but I'm not clear if any
decisions have been made about changing it or providing a new API.


4. What does openssl_random_pseudo_bytes() really do in PHP?

Where does it get random bytes from in the various different platforms?
Is it going to change in PHP 7?


5. Is the weird Linux /dev/random[1] still supported? If so, is used
by default in any PHP API?


6. I noticed some work on constant-time functions. Is this for security
purposes, i.e. defeating remote timing attacks? Is there an RFC?



"Feature Freeze" for PHP 7 is coming soon. I, for one, would value a
summary of what's happening in PHP 7 with respect to security topics
like but not limited to these. Some kinda of document detailing the
plan, if there is one, would be real swell.

Tom


---
[1] http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/

Search Discussions

  • Yasuo Ohgaki at Feb 8, 2015 at 5:48 am
    Hi Tom,
    On Sun, Feb 8, 2015 at 4:24 AM, Tom Worster wrote:

    1. Will there be a portable API for getting random bytes from the
    platform's CSPRNG?

    https://wiki.php.net/ideas/php6 lists as an addition: "Reliable,
    userfriendly RNG APIs: Provide a userfriendly and reliable RNG APIs,
    available by default, on all supported platforms and for all usages
    (from weak to crypto safe)."
    Pierre,

    What the status?


    2. What's going to happen to mcrypt?

    I see the vote to excise it did not pass. Does this mean that (i.e.
    imply that) PHP's plan is to keep a security lib that hasn't been
    maintained for 8 years for the next 5+ years?
    Removed.
    Available as PECL module.
    Probably.


    3. Will the OpenSSL ext remain as it currently stands?

    There have been a few discussions about this but I'm not clear if any
    decisions have been made about changing it or providing a new API.
    Not sure on this


    4. What does openssl_random_pseudo_bytes() really do in PHP?

    Where does it get random bytes from in the various different platforms?
    Is it going to change in PHP 7?
    It's depend on openssl. What openssl does is what it does.


    5. Is the weird Linux /dev/random[1] still supported? If so, is used
    by default in any PHP API?
    Session module use it.
    /dev/urandom or /dev/arundom


    6. I noticed some work on constant-time functions. Is this for security
    purposes, i.e. defeating remote timing attacks? Is there an RFC?

    No, but there is patch.
    Status?

    Regards,


    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net
  • Pierre Joye at Feb 8, 2015 at 6:04 am

    On Feb 8, 2015 12:48 PM, "Yasuo Ohgaki" wrote:

    2. What's going to happen to mcrypt?

    I see the vote to excise it did not pass. Does this mean that (i.e.
    imply that) PHP's plan is to keep a security lib that hasn't been
    maintained for 8 years for the next 5+ years?

    Removed.
    Available as PECL module.
    Probably.
    Please check the RFC.

    It is not removed and unless some people changed their mind the horrible
    scenario described here will happen. And it will be longer than 5 years.
  • Yasuo Ohgaki at Feb 8, 2015 at 6:44 am
    Hi Pierre,
    On Sun, Feb 8, 2015 at 3:04 PM, Pierre Joye wrote:
    On Feb 8, 2015 12:48 PM, "Yasuo Ohgaki" wrote:

    2. What's going to happen to mcrypt?

    I see the vote to excise it did not pass. Does this mean that (i.e.
    imply that) PHP's plan is to keep a security lib that hasn't been
    maintained for 8 years for the next 5+ years?

    Removed.
    Available as PECL module.
    Probably.
    Please check the RFC.

    It is not removed and unless some people changed their mind the horrible
    scenario described here will happen. And it will be longer than 5 years.
    https://wiki.php.net/start#extmcrypt

    Voted +1

    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net
  • Pierre Joye at Feb 8, 2015 at 6:51 am

    On Sun, Feb 8, 2015 at 1:43 PM, Yasuo Ohgaki wrote:
    Hi Pierre,
    On Sun, Feb 8, 2015 at 3:04 PM, Pierre Joye wrote:
    On Feb 8, 2015 12:48 PM, "Yasuo Ohgaki" wrote:

    2. What's going to happen to mcrypt?

    I see the vote to excise it did not pass. Does this mean that (i.e.
    imply that) PHP's plan is to keep a security lib that hasn't been
    maintained for 8 years for the next 5+ years?

    Removed.
    Available as PECL module.
    Probably.
    Please check the RFC.

    It is not removed and unless some people changed their mind the horrible
    scenario described here will happen. And it will be longer than 5 years.

    https://wiki.php.net/start#extmcrypt

    Voted +1
    Not sure what this RFC is (did not dig the list as the link is wrong).
    However the latest on the topic is here and it is does not look
    remotely close to a approval:

    https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts
  • Yasuo Ohgaki at Feb 8, 2015 at 7:22 am
    Hi Pierre,
    On Sun, Feb 8, 2015 at 3:51 PM, Pierre Joye wrote:

    Not sure what this RFC is (did not dig the list as the link is wrong).
    However the latest on the topic is here and it is does not look
    remotely close to a approval:

    https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts
    Sorry my copy buffer had wrong URL...
    I voted +1 for mcrypt. It's 12 vs. 13 now.

    Regards,

    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net
  • Tom Worster at Feb 8, 2015 at 3:44 pm
    Hi Yasuo, Pierre,

    Thank you both for the updates.

    I expect the vote to remove mcrypt can be shifted towards "yes" if some
    campaigning effort is made. I made a start in another thread.

    Assuming that mcrypt goes, as it should, we are left with a problem. The
    PHP user doesn't have a platform-independent way to get pseudo-random
    bytes for crypto. OpenSSL's RNG is not to be trusted. If the user knows
    this (I wouldn't bet on it) then she has to resort to accessing the
    platform RNG directly.

    On Unix-like system's it is technically easy but much confusion is caused
    by the Linux man page with its myth that urandom is unsafe for crypto.

    On Windows I just have no idea how the user might proceed.

    So I really think the "Reliable, userfriendly RNG APIs" idea in the wiki
    is very important.

    Tom
  • Pierre Joye at Feb 8, 2015 at 5:03 pm

    On Feb 8, 2015 10:44 PM, "Tom Worster" wrote:
    Hi Yasuo, Pierre,

    Thank you both for the updates.

    I expect the vote to remove mcrypt can be shifted towards "yes" if some
    campaigning effort is made. I made a start in another thread.

    Assuming that mcrypt goes, as it should, we are left with a problem.
    I agree with Derick about wrapping ext/mcrypt around OpenSSL or other to
    keep it around for BC. I simply do not have the resources to make that
    happen so someone has to jump on it (Derick?)

    Cheers
    Pierre
  • Leigh at Feb 8, 2015 at 5:33 pm

    On 8 February 2015 at 17:03, Pierre Joye wrote:
    I agree with Derick about wrapping ext/mcrypt around OpenSSL or other to
    keep it around for BC. I simply do not have the resources to make that
    happen so someone has to jump on it (Derick?)
    Are we happy to accept that we'll lose access to some of mcrypts
    ciphers if we do this? I'd suspect most real world usage of php-mcrypt
    is to implement AES anyway, so most users would be covered.
  • Tom Worster at Feb 8, 2015 at 5:48 pm
    Hi Leigh,
    On 2/8/15, 12:33 PM, "Leigh" wrote:

    Are we happy to accept that we'll lose access to some of mcrypts
    ciphers if we do this? I'd suspect most real world usage of php-mcrypt
    is to implement AES anyway, so most users would be covered.
    I hope your suspicion is right.

    I'd be happy to lose all but AES and Blowfish cyphers and CBC and CTR
    modes.

    Tom
  • Daniel Lowrey at Feb 8, 2015 at 4:15 pm

    On Sun, Feb 8, 2015 at 4:24 AM, Tom Worster wrote:


    3. Will the OpenSSL ext remain as it currently stands?
    There has been talk of replacing it with a more generic implementation that
    can swap out the underlying components so we aren't dependent upon a single
    library. The crypto extension in pecl is working on such an approach, but
    AFAIK it's not yet stable. That said, ext/openssl already delegates to
    Windows API functions to provide equivalent functionality as needed, so
    this is already happening to some extent. Additionally, for better or worse
    ext/openssl is tightly integrated into the current streams implementation
    when crypto is required (i.e. the ssl stream wrapper). Any new solution
    would need to provide equivalent functionality.
    4. What does openssl_random_pseudo_bytes() really do in PHP?
    It's less about what it does in PHP and more about what it does in the
    openssl lib itself with the exception being Windows environments.

    ### In Windows

    This function delegates to CryptGenRandom() which uses the general
    system-wide RNG. It *is* possible for an application to add its own data to
    the further randomize the internal seed, however, the current
    openssl_random_pseudo_bytes() does not expose this capability to userland.

    ### Elsewhere

    Openssl transparently seeds its entropy pool. Once the pool has been seeded
    with enough data it will always have sufficient data to ensure an
    unpredictable byte sequence is returned. So it now becomes a matter of
    whether or not it has enough entropy at the time of your call to
    openssl_random_pseudo_bytes().

    Openssl actually exposes two separate APIs for this case, so let me explain
    what each does:

    - RAND_bytes()

    Always return an error if there is insufficient data in the pool to ensure
    unpredictability.

    - RAND_pseudo_bytes()

    Always return bytes, even if the entropy pool has not been sufficiently
    seeded.

    Currently PHP's openssl_random_pseudo_bytes() uses the latter function and
    allows users to pass a by-reference $crypto_strong out parameter to
    determine if the result is cryptographically strong. This is fine if you
    know all of the above and have read the manual for this function. However,
    it may be desirable to add a new openssl_rand_bytes() function that uses
    RAND_bytes() under the hood to make it less likely for someone to
    accidentally use insufficiently random output. I don't think there would be
    an analog to this functionality in Windows as the documentation for
    CryptGenRandom() makes no mention of when/if this API can return a sequence
    of bytes that is not cryptographically secure. So, a new
    openssl_random_bytes() might only amount to an alias of the existing
    openssl_random_pseudo_bytes() function in this environment. Please provide
    feedback if you think a new function should be added as this is a
    relatively straightforward thing to do.

    I would also like to propose a new optional $additionalSeed string
    parameter that could be passed from userland to include in the entropy pool
    since both the underlying Windows and Openssl APIs support this
    functionality.
    "Feature Freeze" for PHP 7 is coming soon. I, for one, would value a
    summary of what's happening in PHP 7 with respect to security topics
    like but not limited to these.
    FYI I still plan to add both client-side and server-side support for OCSP
    verification in encrypted streams. The other thing I plan to do is add
    support for the (relatively new) TLSALPN extension in encrypted
    client/server streams. This extension is required to establish encrypted
    connections using the forthcoming h2 (HTTP/2.0) protocol.
  • Damien Tournoud at Feb 8, 2015 at 5:04 pm

    On Sun, Feb 8, 2015 at 5:15 PM, Daniel Lowrey wrote:

    Currently PHP's openssl_random_pseudo_bytes() uses the latter function and
    allows users to pass a by-reference $crypto_strong out parameter to
    determine if the result is cryptographically strong. This is fine if you
    know all of the above and have read the manual for this function. However,
    it may be desirable to add a new openssl_rand_bytes() function that uses
    RAND_bytes() under the hood to make it less likely for someone to
    accidentally use insufficiently random output.

    Hi Daniel,

    Just to clarify: OpenSSL automatically seeds its random pool from
    crypto-safe system-specific sources (/dev/[u]random on Linux): it is just
    *impossible* on modern systems to end up in the case of not having enough
    entropy.

    Damien
  • Tom Worster at Feb 8, 2015 at 5:11 pm
    Thanks Damien and Daniel for the info.

    I am not concerned about running out of entropy. I am concerned about
    userspace RNGs such as OpenSSL
    http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/


    On 2/8/15, 12:04 PM, "Damien Tournoud" wrote:
    On Sun, Feb 8, 2015 at 5:15 PM, Daniel Lowrey wrote:

    Currently PHP's openssl_random_pseudo_bytes() uses the latter function
    and
    allows users to pass a by-reference $crypto_strong out parameter to
    determine if the result is cryptographically strong. This is fine if you
    know all of the above and have read the manual for this function.
    However,
    it may be desirable to add a new openssl_rand_bytes() function that uses
    RAND_bytes() under the hood to make it less likely for someone to
    accidentally use insufficiently random output.

    Hi Daniel,

    Just to clarify: OpenSSL automatically seeds its random pool from
    crypto-safe system-specific sources (/dev/[u]random on Linux): it is just
    *impossible* on modern systems to end up in the case of not having enough
    entropy.

    Damien
  • Daniel Lowrey at Feb 8, 2015 at 5:52 pm

    On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster wrote:
    Thanks Damien and Daniel for the info.

    I am not concerned about running out of entropy. I am concerned about
    userspace RNGs such as OpenSSL
    http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
    Just to be clear (as Damien also mentioned): openssl is not a userspace
    RNG. It uses the underlying system-specific resources. If your system's RNG
    is good enough (/dev/[u]random in nix-like systems) for you,
    openssl_random_pseudo_bytes() is good enough for you.
  • Tom Worster at Feb 8, 2015 at 7:18 pm

    On 2/8/15, 12:52 PM, "Daniel Lowrey" wrote:
    On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster wrote:

    Thanks Damien and Daniel for the info.

    I am not concerned about running out of entropy. I am concerned about
    userspace RNGs such as OpenSSL
    http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
    Just to be clear (as Damien also mentioned): openssl is not a userspace
    RNG.
    OpenSSL has an RNG that is not in the kernel memory space. Software that
    is
    in memory but not in the kernel space is in the user space.
  • Daniel Lowrey at Feb 8, 2015 at 8:42 pm

    On Sun, Feb 8, 2015 at 2:18 PM, Tom Worster wrote:
    On 2/8/15, 12:52 PM, "Daniel Lowrey" wrote:
    On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster wrote:

    Thanks Damien and Daniel for the info.

    I am not concerned about running out of entropy. I am concerned about
    userspace RNGs such as OpenSSL
    http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
    Just to be clear (as Damien also mentioned): openssl is not a userspace
    RNG.
    OpenSSL has an RNG that is not in the kernel memory space. Software that
    is
    in memory but not in the kernel space is in the user space.
    You're right, my mistake. I don't claim to be a crypto expert in any sense
    of the word -- I simply implement APIs that real crypto experts create. I
    don't believe it makes any sense for us to implement this in php-src
    directly.
    If you haven't compiled openssl with a different RNG engine it's going to
    default to use RAND_SSLeay(). The explanation here explains the logic
    involved:

    https://www.openssl.org/docs/crypto/rand.html#internals

    Dr. Henson is far smarter than I am; I'll take his word for it. The only
    outstanding issue noted in the linked discussion is "An initial source of
    random 'state'" which, as you can see by reading the subsequent RAND_add()
    documentation is transparently retrieved from /dev/urandom for us:
    On systems that provide /dev/urandom, the randomness device is used to
    seed the PRNG transparently. However, on all other systems, the
    application is responsible for seeding the PRNG by calling RAND_add()
    If you're in Windows this is handled by a different API. And if not, I tend
    to trust the openssl PRNG since it pulls its initial random state from
    /dev/urandom. I honestly don't see the problem here. I'm happy to be wrong
    if someone says, "no, we should come up with a different way to do this,"
    and can provide logic to back that up. Personally, I have no reason to
    believe the openssl implementation is inadequate. We could add the ability
    to pass in your own initialization data but the only good option there is
    pulling it from `fread()` on /dev/urandom anyway ... a somewhat pointless
    exercise as openssl already does this.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedFeb 7, '15 at 7:24p
activeFeb 8, '15 at 8:42p
posts16
users6
websitephp.net

People

Translate

site design / logo © 2019 Grokbase