Make ssleay_rand_bytes more deterministic - Openssl

This is a discussion on Make ssleay_rand_bytes more deterministic - Openssl ; Richard Stoughton wrote: > On Tue, May 20, 2008 at 12:09 AM, Bodo Moeller wrote: > > As far as I can understand the code, the suggested usage pattern for > the RNG would be > > ssleay_rand_bytes(ssleay_rand_add ^ n) ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Make ssleay_rand_bytes more deterministic

  1. Re: Make ssleay_rand_bytes more deterministic

    Richard Stoughton wrote:

    > On Tue, May 20, 2008 at 12:09 AM, Bodo Moeller wrote:
    >
    > As far as I can understand the code, the suggested usage pattern for
    > the RNG would be
    >
    > ssleay_rand_bytes(ssleay_rand_add ^ n) with n > 0.
    >
    > If consecutive calls to ssleay_rand_bytes without intermediate calls
    > to ssleay_rand_add are allowed, your objection is obviously more than
    > justified.


    Many applications call ssleay_rand_add (or one of the wrapper functions)
    only once at application startup with data for example from /dev/random.
    People wearing both belt and suspenders may want to call
    ssleay_rand_add periodically during application runtime, but that's not
    necessary in the strict sense.

    >>> - do not mix bits of the given output buffer into the internal entropy pool.

    >>
    >>>Note that the second improvement may totally break already broken
    >>>client software.

    >>
    >>Why would it?

    >
    >
    > Clients that do not call ssleay_rand_add at all would probably get a
    > random series with even less variance than the debianized one has.


    Clients not calling ssleay_rand_add at all get *no* random series, but
    an error code when calling ssleay_rand_bytes (and an error message
    requesting to read the OpenSSL FAQ,
    http://www.openssl.org/support/faq.html).

    Ciao,
    Richard
    --
    Dr. Richard W. Könning
    Fujitsu Siemens Computers GmbH

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  2. Make ssleay_rand_bytes more deterministic

    Hi,

    This is not a joke. Please clean up ssleay_rand_bytes:

    - do not mix the PID into the internal entropy pool, and
    - do not mix bits of the given output buffer into the internal entropy pool.

    This will help detecting weaknesses in the rng itself as well as in
    software that depends on this rng.

    It will further help writing test cases to improve the quality of
    client software.


    Note that the second improvement may totally break already broken
    client software. So please do note this in the changelog.

    Regards R.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  3. Re: Make ssleay_rand_bytes more deterministic

    On Mon, May 19, 2008 at 11:57 PM, Richard Stoughton wrote:

    > - do not mix the PID into the internal entropy pool, and


    The OpenSSL PRNG uses the PID twice:

    Once it is used as part of the intitial seeding on Unix machines, to
    get some data that might provide a little actual entropy. This part
    wasn't functional in the Debian version, because the content of each
    and every seed byte was ignored.

    But then the PRNG also mixes the PID into the output (via a hash).
    This is why the PID did influence the output bytes on Debian. The
    point in using the PID here is *not* to collect entropy. Rather, it
    is to ensure that after a fork() both processes will see different
    random numbers. Without this feature, many typical Unix-style server
    programs would be utterly broken.


    > - do not mix bits of the given output buffer into the internal entropy pool.


    > Note that the second improvement may totally break already broken
    > client software.


    Why would it?
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  4. Re: Make ssleay_rand_bytes more deterministic

    On Tue, May 20, 2008 at 12:09 AM, Bodo Moeller wrote:
    > On Mon, May 19, 2008 at 11:57 PM, Richard Stoughton wrote:
    >
    >> - do not mix the PID into the internal entropy pool, and

    >
    > The OpenSSL PRNG uses the PID twice:
    >
    > Once it is used as part of the intitial seeding on Unix machines, to
    > get some data that might provide a little actual entropy. This part
    > wasn't functional in the Debian version, because the content of each
    > and every seed byte was ignored.
    >
    > But then the PRNG also mixes the PID into the output (via a hash).
    > This is why the PID did influence the output bytes on Debian. The
    > point in using the PID here is *not* to collect entropy. Rather, it
    > is to ensure that after a fork() both processes will see different
    > random numbers. Without this feature, many typical Unix-style server
    > programs would be utterly broken.


    I see.

    As far as I can understand the code, the suggested usage pattern for
    the RNG would be

    ssleay_rand_bytes(ssleay_rand_add ^ n) with n > 0.

    If consecutive calls to ssleay_rand_bytes without intermediate calls
    to ssleay_rand_add are allowed, your objection is obviously more than
    justified.

    >> - do not mix bits of the given output buffer into the internal entropy pool.

    >
    >> Note that the second improvement may totally break already broken
    >> client software.

    >
    > Why would it?


    Clients that do not call ssleay_rand_add at all would probably get a
    random series with even less variance than the debianized one has.

    However, I cannot see that the second point would make the correctly
    used RNG weaker. Would it?
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  5. Re: Make ssleay_rand_bytes more deterministic

    On Wed, May 21, 2008 at 3:43 PM, Richard Koenning
    wrote:
    > Richard Stoughton wrote:
    >
    >> On Tue, May 20, 2008 at 12:09 AM, Bodo Moeller wrote:
    >>
    >> As far as I can understand the code, the suggested usage pattern for
    >> the RNG would be
    >>
    >> ssleay_rand_bytes(ssleay_rand_add ^ n) with n > 0.
    >>
    >> If consecutive calls to ssleay_rand_bytes without intermediate calls
    >> to ssleay_rand_add are allowed, your objection is obviously more than
    >> justified.

    >
    > Many applications call ssleay_rand_add (or one of the wrapper functions)
    > only once at application startup with data for example from /dev/random.
    > People wearing both belt and suspenders may want to call ssleay_rand_add
    > periodically during application runtime, but that's not necessary in the
    > strict sense.


    In this case the RNG degenerates to a simple *pseudo* RNG with random
    seed. This is not a best effort strategy and hence, in my opinion, not
    a good idea for applications that try to implement security.

    >>>> - do not mix bits of the given output buffer into the internal entropy
    >>>> pool.


    Hm, the recent Debian case seems to prevent discussions about this point

    >>>> Note that the second improvement may totally break already broken
    >>>> client software.
    >>>
    >>> Why would it?

    >>
    >>
    >> Clients that do not call ssleay_rand_add at all would probably get a
    >> random series with even less variance than the debianized one has.

    >
    > Clients not calling ssleay_rand_add at all get *no* random series, but an
    > error code when calling ssleay_rand_bytes (and an error message requesting
    > to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html).


    Thank you for pointing this out.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


+ Reply to Thread