OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Thor Lancelot Simon (tlsREK.TJLS.COM)
Date: Wed Feb 14 2001 - 19:41:04 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    On Thu, Feb 15, 2001 at 01:22:34AM +0100, Ulf Moeller wrote:
    > On Wed, Feb 14, 2001, tlsREK.TJLS.COM wrote:
    >
    > > * worst-case, it degenerates to the internal
    > > seeding of the OpenSSL PRNG, even if we fed it
    > > _nothing_ else at all. OpenSSL doesn't really
    > > suck about this.
    >
    > If you want to use OpenSSL's internal seeding, DO NOT use RAND_seed() with
    > bogus data. If you at least used RAND_add() with an entropy estimate of 0,
    > OpenSSL would still have the chance to stop you from using an essentially
    > unseeded PRNG.

    Ulf,

    At the time at which the code you're referring to was written, RAND_add()
    did not exist. In fact, you'll find all kinds of awful hacks in our code
    to deal with the appearance and disappearance and alteration of various
    interfaces that we've discovered *have* changed in various versions of
    SSLeay/OpenSSL since FreSSH development began; OpenSSL didn't even really
    exist when we started. Evidently we missed this important and useful
    change to the OpenSSL random-number-generator interface.

    Incidentally, I believe that interface to be broken at the moment. The
    behaviour of the generator should not differ on /dev/random systems and
    those without it -- the generator should *always*, *consistently* refuse
    to return "random" numbers unless seeded, even if there's a convenience
    function to seed it from /dev/random. This kind of inconsistency in the
    interface is really dangerous. Eliminating it wouldn't have avoided our
    mistake, but it certainly avoids many others.

    Actually, once again, even if the code we're talking about here is run,
    which, it has been pointed out to me, is essentially never, since there's
    no *BSD implementation with IPv6 but not /dev/random, and we currently
    require IPv6, and this code is *only* in the BSD system-dependent
    module, we do not run with an unseeded generator. We also seed
    the generator with several timings, and feed it other data over the
    course of the daemon's run. This is bad, but it is not so bad, thank
    goodness, as it might be.

    I should point out here that the "minimal" FreSSH, version 0.3, will
    in fact build on some systems that don't have a /dev/random, since it
    doesn't use or require IPv6; however, those systems consist solely of
    very old versions of NetBSD and FreeBSD. That is a problem, and we will
    rectify it, though we strongly urge users to use our newer code.

    Thor