Mailing List Archive

Chris Ihlenfeld <info@digital-concepts.net> writes:

> I am trying to run the configure for 1.2.2 on an intel solaris 2.7
> box and I get an error for urandom not found. I cant find anything
> related to rand, urand, random, rng, or urandom on my box. How can
> I get around this, or where can I get urandom?

Here's a patch I've written which makes the code fall back on srand()
and rand() if neither /dev/urandom nor the EGD is available.

Note that this has implications for the security of your ssh/sshd
installation, and if I've understood the discussion from last week
correctly, something like this will never actually make it into the
distribution -- not even only as a last resort fallback.

But I don't know much about the issues involved, and I might be
wrong. If so, please feel free (any OpenSSH-port maintainer) to apply
my patch to the standard distribution.

I noticed a patch with more-or-less the same functionality was part of
a patch-set for porting OpenSSH to AIX a few weeks back, but I believe
the code below is a little bit better, as it uses the ANSI C standard
functions srand() and rand() instead of srandom() and random(), it
includes a warning for the user during configure about the use of
srand() and rand() in the absent of /dev/urandom or EGD, and it will
only use the less secure code as a last resort fallback.

Regards,
Morten Eriksen

On 15 Feb 2000, Morten Eriksen wrote:

> Here's a patch I've written which makes the code fall back on srand()
> and rand() if neither /dev/urandom nor the EGD is available.
>
> Note that this has implications for the security of your ssh/sshd
> installation, and if I've understood the discussion from last week
> correctly, something like this will never actually make it into the
> distribution -- not even only as a last resort fallback.

Please don't use such patches, they completely ruin OpenSSH's
cryptographic security.

The crypto in OpenSSH needs good, hard to predict random numbers. We
prefer that such random numbers come from a range of difficult to
guess sources such as interrupt timings, keystroke and mouse event
times, etc. The free Unices kernel random number pools do a great job
of collecting and aggregating these sources.

EGD is patterned after these designs, but it doesn't have access to
the wide variety of entropy sources that the kernel does. Still, it
uses good algorithms to aggregate the entropy it does collect and
maintains a fairly large pool.

On the other hand, libc's rand functions use a linear congruential
generator to generate their "random" numbers. Such functions are very
simple [r=(a+b)%p;a=r; IIRC] and vary easy to reverse. You probably
wouldn't need to reverse it anyway - most rand() functions only have
32 bits of state and they are usually seeded with the current system
time and/or pid, both of which are available to an attacker.

Work is underway to port Schneier and Kelsey's Yarrow PRNG code from
Windows to a Unix library. When this is done and audited, it will
probably replace EGD in OpenSSH.

Regards,
Damien Miller

--
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.mindrot.org/
| Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)

I managed to get the egd working...pretty poor documentation on how to get
it working with ssh.

Is there a way to secure ftp? So that people from the outside using
cuteftp, or some other windows type ftp are secured also?

Chris

Damien Miller wrote:

> On 15 Feb 2000, Morten Eriksen wrote:
>
> > Here's a patch I've written which makes the code fall back on srand()
> > and rand() if neither /dev/urandom nor the EGD is available.
> >
> > Note that this has implications for the security of your ssh/sshd
> > installation, and if I've understood the discussion from last week
> > correctly, something like this will never actually make it into the
> > distribution -- not even only as a last resort fallback.
>
> Please don't use such patches, they completely ruin OpenSSH's
> cryptographic security.
>
> The crypto in OpenSSH needs good, hard to predict random numbers. We
> prefer that such random numbers come from a range of difficult to
> guess sources such as interrupt timings, keystroke and mouse event
> times, etc. The free Unices kernel random number pools do a great job
> of collecting and aggregating these sources.
>
> EGD is patterned after these designs, but it doesn't have access to
> the wide variety of entropy sources that the kernel does. Still, it
> uses good algorithms to aggregate the entropy it does collect and
> maintains a fairly large pool.
>
> On the other hand, libc's rand functions use a linear congruential
> generator to generate their "random" numbers. Such functions are very
> simple [r=(a+b)%p;a=r; IIRC] and vary easy to reverse. You probably
> wouldn't need to reverse it anyway - most rand() functions only have
> 32 bits of state and they are usually seeded with the current system
> time and/or pid, both of which are available to an attacker.
>
> Work is underway to port Schneier and Kelsey's Yarrow PRNG code from
> Windows to a Unix library. When this is done and audited, it will
> probably replace EGD in OpenSSH.
>
> Regards,
> Damien Miller
>
> --
> | "Bombay is 250ms from New York in the new world order" - Alan Cox
> | Damien Miller - http://www.mindrot.org/
> | Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)

In message <51k8k6secr.fsf@trh.sim.no>, Morten Eriksen writes:
>Here's a patch I've written which makes the code fall back on srand()
>and rand() if neither /dev/urandom nor the EGD is available.
>
>Note that this has implications for the security of your ssh/sshd
>installation, and if I've understood the discussion from last week
>correctly, something like this will never actually make it into the
>distribution -- not even only as a last resort fallback.
I am sorry. It seems to me that you understand why using such
a patch is completely wrong. So, why do you post it here? If there
is no way to get good randomness than openssh should terminate.

Your operating system should provide application programs with a source
of randomness. If it doesnt, than it needs to be fixed.

You might want to look into a user provided one-time randomness file.
While not perfect, it is certainly better than using rand().

Niels.

* Damien Miller
> The crypto in OpenSSH needs good, hard to predict random numbers. We
> prefer that such random numbers come from a range of difficult to
> guess sources such as interrupt timings, keystroke and mouse event
> times, etc.
>
> On the other hand, libc's rand functions [...] are usually seeded
> with the current system time and/or pid, both of which are available
> to an attacker.

The microseconds part of the struct timeval filled in by the
gettimeofday() call seems like it could be a decent source of entropy
in itself to me. Would you care to explain why this is not correct? Is
it because the granularity of system clocks are not good enough, or is
there a pattern to how the value of the microseconds part will be set?

> Work is underway to port Schneier and Kelsey's Yarrow PRNG code from
> Windows to a Unix library. When this is done and audited, it will
> probably replace EGD in OpenSSH.

Ok, great. Does the functionality of this code include both a PRNG and
an entropy source for the seed?

Regards,
Morten Eriksen

* Niels Provos
> I am sorry. It seems to me that you understand why using such a
> patch is completely wrong. So, why do you post it here?

First you snip away the text where I explain why I posted it ("if I've
understood the discussion from last week correctly, something like
this will never actually make it into the distribution [...] But I
don't know much about the issues involved, and I might be wrong."),
then you ask why I posted it?

Come on, give me a break.

> You might want to look into a user provided one-time randomness
> file. While not perfect, it is certainly better than using rand().

Sounds like a good idea, and I guess this is what the original ssh
does when it asks the user to move the mouse around or bang the
keyboard, right?

Would there be any point in submitting a patch which implements the
same "file of randomness" generation as ssh? Or would that just be
"super-seeded" (*ough* what a terrible pun) by the effort to port
Yarrow?

Regards,
Morten Eriksen