Mailing List Archive

On Thu, 27 Jan 2000, Dave Dykstra wrote:


> The memory requirement isn't the worse problem for me: I currently
> distribute the ssh 1.2.27 client via a non-root user id *very* widely
> throughout my company (on 8 unix variants), and there isn't any reasonable
> way for me to start a shared long-running process on every machine that may
> run ssh. It's not a problem for the machines that are running sshd, since
> that has to run as root anyway, but it is a big problem on machines that
> run the ssh client only. I could start a shared processes on the servers
> that receive the distribution under my non-root user id, but that doesn't
> help for all the workstations that nfs-mount the package from servers.

I have received a patch to enable the EGD support in OpenSSH to
use a TCP socket for communications with EGD. This would allow
multiple users on a machine to share a single instance of
EGD. Though I wouldn't recommend it be used over a network.

> I need a mechanism like the one used in commercial ssh, where the random
> seed is saved in a file.

Sun do have a random driver which may be of use:

BH> You can install the SUNWski package. It comes with the sun webserver on the
BH> SEAS cd. It's still not a kernel random like linux though. It has a stand
BH> alone daemon like the perl package. I think it's a little lighter though.

BH> PKGINST: SUNWski
BH> NAME: SKI 1.0 Software (User Package)
BH> CATEGORY: application
BH> ARCH: sparc
BH> VERSION: 1.0,REV=1998.09.24.00.00
BH> BASEDIR: /
BH> VENDOR: Sun Microsystems
BH> DESC: SKI Software (User Package)
BH> PSTAMP: mcm-ultra1>Fri Dec 4 14:23:39 PST 1998
BH> INSTDATE: Jan 07 2000 16:32
BH> VSTOCK: 258-6422-05
BH> HOTLINE: Please contact your local service provider
BH> STATUS: completely installed
BH> FILES: 36 installed pathnames
BH> 10 shared pathnames
BH> 4 linked files
BH> 11 directories
BH> 16 executables
BH> 3173 blocks used (approx)

-d


--
| "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)

> Date: Fri, 28 Jan 2000 10:05:00 +1100 (EST)
> From: Damien Miller <djm@mindrot.org>
> To: Dave Dykstra <dwd@bell-labs.com>
> Cc: openssh-unix-dev@mindrot.org
> Subject: Re: EGD requirement a show stopper for me
> X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you
> MIME-Version: 1.0
>
> > The memory requirement isn't the worse problem for me: I currently
> > distribute the ssh 1.2.27 client via a non-root user id *very* widely
> > throughout my company (on 8 unix variants), and there isn't any reasonable
> > way for me to start a shared long-running process on every machine that may
> > run ssh. It's not a problem for the machines that are running sshd, since
> > that has to run as root anyway, but it is a big problem on machines that
> > run the ssh client only. I could start a shared processes on the servers
> > that receive the distribution under my non-root user id, but that doesn't
> > help for all the workstations that nfs-mount the package from servers.
>
> I have received a patch to enable the EGD support in OpenSSH to
> use a TCP socket for communications with EGD. This would allow
> multiple users on a machine to share a single instance of
> EGD. Though I wouldn't recommend it be used over a network.
>
> > I need a mechanism like the one used in commercial ssh, where the random
> > seed is saved in a file.
>
> Sun do have a random driver which may be of use:
>
> BH> You can install the SUNWski package. It comes with the sun webserver on the
> BH> SEAS cd. It's still not a kernel random like linux though. It has a stand
> BH> alone daemon like the perl package. I think it's a little lighter though.
>
> BH> PKGINST: SUNWski
> BH> NAME: SKI 1.0 Software (User Package)
> BH> CATEGORY: application
> BH> ARCH: sparc
> BH> VERSION: 1.0,REV=1998.09.24.00.00
> BH> BASEDIR: /
> BH> VENDOR: Sun Microsystems
> BH> DESC: SKI Software (User Package)
> BH> PSTAMP: mcm-ultra1>Fri Dec 4 14:23:39 PST 1998
> BH> INSTDATE: Jan 07 2000 16:32
> BH> VSTOCK: 258-6422-05
> BH> HOTLINE: Please contact your local service provider
> BH> STATUS: completely installed
> BH> FILES: 36 installed pathnames
> BH> 10 shared pathnames
> BH> 4 linked files
> BH> 11 directories
> BH> 16 executables
> BH> 3173 blocks used (approx)

I can personally verify that this works on SunOS 5.6 through to 5.8 beta
with OpenSSH. Also, if you have a sunsolve account, you can get it from
a Sun patch, just do a search for SUNWski on sunsolve and grab that
patch, the patch contains SUNWski and then install it.

Carl

Yo All!

I tried to find the SUNWski package as a standalone file. Anyone got
any hints where to find that, or another, /dev/random package?

RGDS
GARY

> You can install the SUNWski package. It comes with the sun webserver on the

---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676

Yo Carl!

Got a URL for this?? I am not up to date on SunOS and such...

RGDS
GARY

On Fri, 28 Jan 2000, Carl Brewer wrote:

> I can personally verify that this works on SunOS 5.6 through to 5.8 beta
> with OpenSSH. Also, if you have a sunsolve account, you can get it from
> a Sun patch, just do a search for SUNWski on sunsolve and grab that
> patch, the patch contains SUNWski and then install it.

---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676

On Thu, 27 Jan 2000, Gary E. Miller wrote:

> Yo All!
>
> I tried to find the SUNWski package as a standalone file. Anyone got
> any hints where to find that, or another, /dev/random package?
>

It's on the SEAS cd along with the sun web server.

Brian

Brian Harvell harvell@aol.net http://ToolBoy.com/
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

Yo Brian!

So how do I get the CD?

Can I install just the SUNWski?

RGDS
GARY

On Thu, 27 Jan 2000, Brian Harvell wrote:

> Date: Thu, 27 Jan 2000 18:53:17 -0500 (EST)
> From: Brian Harvell <harvell@aol.net>
> To: Gary E. Miller <gem@rellim.com>
> Cc: openssh-unix-dev@mindrot.org
> Subject: Re: EGD requirement a show stopper for me
>
> On Thu, 27 Jan 2000, Gary E. Miller wrote:
>
> > Yo All!
> >
> > I tried to find the SUNWski package as a standalone file. Anyone got
> > any hints where to find that, or another, /dev/random package?
> >
>
> It's on the SEAS cd along with the sun web server.
>
> Brian
>
> Brian Harvell harvell@aol.net http://ToolBoy.com/
> echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
>
>
>
>

---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676

Should be in the 11/99 solaris 7 server pack. And yes you can install just
that package.

Brian

On Thu, 27 Jan 2000, Gary E. Miller wrote:

> Yo Brian!
>
> So how do I get the CD?
>
> Can I install just the SUNWski?
>
> RGDS
> GARY
>
> On Thu, 27 Jan 2000, Brian Harvell wrote:
>
> > Date: Thu, 27 Jan 2000 18:53:17 -0500 (EST)
> > From: Brian Harvell <harvell@aol.net>
> > To: Gary E. Miller <gem@rellim.com>
> > Cc: openssh-unix-dev@mindrot.org
> > Subject: Re: EGD requirement a show stopper for me
> >
> > On Thu, 27 Jan 2000, Gary E. Miller wrote:
> >
> > > Yo All!
> > >
> > > I tried to find the SUNWski package as a standalone file. Anyone got
> > > any hints where to find that, or another, /dev/random package?
> > >
> >
> > It's on the SEAS cd along with the sun web server.
> >
> > Brian
> >
> > Brian Harvell harvell@aol.net http://ToolBoy.com/
> > echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
> >
> >
> >
> >
>
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
> gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
>


Brian Harvell harvell@aol.net http://ToolBoy.com/
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

I'm currently working on a random number generator. From rfc1750, I'm
trying to get a cypher feedback implementation. I was going to do
the Blum Blum Shub, but I think it would be to computationally intensive.

Matt

On Fri, Jan 28, 2000 at 10:05:00AM +1100, Damien Miller wrote:
> > The memory requirement isn't the worse problem for me: I currently
> > distribute the ssh 1.2.27 client via a non-root user id *very* widely
> > throughout my company (on 8 unix variants), and there isn't any reasonable
> > way for me to start a shared long-running process on every machine that may
> > run ssh. It's not a problem for the machines that are running sshd, since
> > that has to run as root anyway, but it is a big problem on machines that
> > run the ssh client only. I could start a shared processes on the servers
> > that receive the distribution under my non-root user id, but that doesn't
> > help for all the workstations that nfs-mount the package from servers.
>
> I have received a patch to enable the EGD support in OpenSSH to
> use a TCP socket for communications with EGD. This would allow
> multiple users on a machine to share a single instance of
> EGD. Though I wouldn't recommend it be used over a network.

Could that be used in such a way that the first person on a machine to use
openssh would start up EGD under their own user id (via a front-end script
to 'ssh' which I would write so they don't have to do anything special),
and subsequent users would share the same socket? Even if that's what's
intended, it sure doesn't sound like a good idea because a malicious user
could start up a hacked EGD and control what other users get.


> > I need a mechanism like the one used in commercial ssh, where the random
> > seed is saved in a file.
>
> Sun do have a random driver which may be of use:
>
> BH> You can install the SUNWski package.

This is not an option for me; I have no control over what packages are on
all the machines that get my distribution, so I can only rely on standard
stuff. I use the same binaries for a variety of OS releases as well, for
example on solaris it is 2.5.1 through 2.7.

- Dave Dykstra

I've not looked at the source for where random number generation is
needed, but where in the SSH process are they need.

I can see it needed on connection with a new machine to generate your
keys, and I could see another call on each connection afterwards.

Would it cost to much to use something like what Stronghold does
for it's key generation (entering a random amount of keystrokes) for
the primary key, then use a simpiler random number generator for
each connection afterwards?

Granted it would not be as strong as /dev/random or /dev/urandom, but
could be a ./configure option for platforms that don't support
them nor sites that can assure to have egd. (Sounds like someone
is working on this.)

On Fri, 28 Jan 2000, Dave Dykstra wrote:

> On Fri, Jan 28, 2000 at 10:05:00AM +1100, Damien Miller wrote:
> > > The memory requirement isn't the worse problem for me: I currently
> > > distribute the ssh 1.2.27 client via a non-root user id *very* widely
> > > throughout my company (on 8 unix variants), and there isn't any reasonable
> > > way for me to start a shared long-running process on every machine that may
> > > run ssh. It's not a problem for the machines that are running sshd, since
> > > that has to run as root anyway, but it is a big problem on machines that
> > > run the ssh client only. I could start a shared processes on the servers
> > > that receive the distribution under my non-root user id, but that doesn't
> > > help for all the workstations that nfs-mount the package from servers.
> >
> > I have received a patch to enable the EGD support in OpenSSH to
> > use a TCP socket for communications with EGD. This would allow
> > multiple users on a machine to share a single instance of
> > EGD. Though I wouldn't recommend it be used over a network.
>
> Could that be used in such a way that the first person on a machine to use
> openssh would start up EGD under their own user id (via a front-end script
> to 'ssh' which I would write so they don't have to do anything special),
> and subsequent users would share the same socket? Even if that's what's
> intended, it sure doesn't sound like a good idea because a malicious user
> could start up a hacked EGD and control what other users get.
>
>
> > > I need a mechanism like the one used in commercial ssh, where the random
> > > seed is saved in a file.
> >
> > Sun do have a random driver which may be of use:
> >
> > BH> You can install the SUNWski package.
>
> This is not an option for me; I have no control over what packages are on
> all the machines that get my distribution, so I can only rely on standard
> stuff. I use the same binaries for a variety of OS releases as well, for
> example on solaris it is 2.5.1 through 2.7.
>
> - Dave Dykstra
>

Oh 2nd thought.. on quick search of Freshmeat.net I found this:

http://www.freshmeat.net/appindex/1999/09/11/937100790.html

Crypto++
randombit - September 11th 1999, 21:46 EST
Crypto++ is a C++ cryptographic class library which includes block and
steam ciphers, hash functions, MACs, random number generators, public key
cryptography (including elliptic curves), compression, and an easy-to-use
filter interface. It aims towards IEEE 1363 compliance.

It may be a good thing.. Since I believe we are also missing ARC4
encoding in OpenSSH (and I notice some clients support it).

Yo Matt!

Let me know if you need any help porting. I have access to Slowlaris,
UnixWare and Linux hosts. Something like this is sorely needed.

It would be nice if it had an easy way to plug in randomness sources
without regard to OS. A lot of crypto guys do things like take
the LSB of the audio input noise, etc... Everyone it seems has
their own pet entropy source. This is an especially annoying
problem on a firewall that otherwise has little activity.

Be sure to talk to some crypto hardcores early on, they are real
fussy about true randomness.

RGDS
GARY

On Fri, 28 Jan 2000, Matt Richards wrote:

> I'm currently working on a random number generator. From rfc1750, I'm
> trying to get a cypher feedback implementation. I was going to do
> the Blum Blum Shub, but I think it would be to computationally intensive.

---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676

On Fri, 28 Jan 2000, Ben Lindstrom wrote:

> I've not looked at the source for where random number generation is
> needed, but where in the SSH process are they need.

Some randomness is needed for RSA key generation. The RSA key
generation routines in OpenSSL source from its own RAND_* routines.

OpenSSL with use /dev/random if it is present or will <looks at
OpenSSL sources> use some easily predictable (uid, pid, time) data to
seed its own hash pool.

Ouch. IMO this is woefully insufficient, and I will be explicitly
seeding the OpenSSL pool from our random number source.

OpenSSH also needs a reasonable amount on entropy to feed an ARC4
PRNG. The PRNG is periodically re-keyed with fresh entropy (256 bits
at a time IIRC).

The output of the PRNG is used for session keys, random pad bytes,
check digits, temp file names, rresvport port numbers and anything
else that needs remotely unpredictable numbers.

The problem is that there is no nice portable way to get high-quality
random numbers. EGD does the job, at the cost of running a large PERL
daemon. (currently one for each user).

I have a patch which will enable users to run only one EGD per machine
and have it serve entropy over a localhost TCP socket. This is still
less than optimal, and I don't think that EGD has been designed for
this. For instance, it may be possible for one user to drain EGD's
entropy pool so it either blocks (DoS) or produces degraded data.

There are several options to pursue here:

1. Revive the random code from ssh 1.2.16.
2. Port the Linux or BSD kernel random driver to userspace
3. Port Yarrow[1]
4. Fix EGD
5. Roll our own

I think that if we are going to change the random source, then we
should use something that has been subjected to review. This precludes
1, 5 and (to a lesser extent) 4. Porting Yarrow is to me the most
attractive option, as it has been the subject of a formal design but
this may take some time.

-d

[1] http://www.counterpane.com/yarrow.html

--
| "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)

Yo Damien!

I just checked out the Yarrow code again. It is very much WinXX code
and would be a PTA to port to any flavor of UNIX. After the port it
would not look anything like it does now...

RGDS
GARY

On Sat, 29 Jan 2000, Damien Miller wrote:

> I think that if we are going to change the random source, then we
> should use something that has been subjected to review. This precludes
> 1, 5 and (to a lesser extent) 4. Porting Yarrow is to me the most
> attractive option, as it has been the subject of a formal design but
> this may take some time.

---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676

You have to be a little careful, just implementing a good pseudo-random
number generator like Yarrow (or several others) does not guarantee you will
have strong random numbers. You also need a truly random seed, which is
hard to come by. You need to port the keyboard and mouse timing code (which
may or may not provide enough entropy on a particular platform) or find some
other source of entropy.

Typically you need to collect entropy from several sources that are
unavailable to the attacker (disk access times, key strokes, mouse
movements, special hardware) and remove any bias from them (this is what RFC
1750 mostly deals with). Collecting enough entropy to generate enough bits
of entropy be time consuming so it is typically done once at the start of a
session and then the seeded PRNG is used thereafter. Some implementations
save random material in a file to reduce subsequent startup times (this can
lead to a bunch of security vulnerabilites).

PRNGs are mostly platform independent, while generating a truly random seed
is usually fairly platform specific. Some implementations of /dev/random go
though the trouble of trying to get good random data from the OD and
hardware, but some do not.

Hope I haven't bored you,

Joe

>From: Damien Miller <djm@mindrot.org>
>To: Ben Lindstrom <mouring@pconline.com>
>CC: Dave Dykstra <dwd@bell-labs.com>, openssh-unix-dev@mindrot.org
>Subject: Re: EGD requirement a show stopper for me
>Date: Sat, 29 Jan 2000 10:56:02 +1100 (EST)
>
>On Fri, 28 Jan 2000, Ben Lindstrom wrote:
>
> > I've not looked at the source for where random number generation is
> > needed, but where in the SSH process are they need.
>
>Some randomness is needed for RSA key generation. The RSA key
>generation routines in OpenSSL source from its own RAND_* routines.
>
>OpenSSL with use /dev/random if it is present or will <looks at
>OpenSSL sources> use some easily predictable (uid, pid, time) data to
>seed its own hash pool.
>
>Ouch. IMO this is woefully insufficient, and I will be explicitly
>seeding the OpenSSL pool from our random number source.
>
>OpenSSH also needs a reasonable amount on entropy to feed an ARC4
>PRNG. The PRNG is periodically re-keyed with fresh entropy (256 bits
>at a time IIRC).
>
>The output of the PRNG is used for session keys, random pad bytes,
>check digits, temp file names, rresvport port numbers and anything
>else that needs remotely unpredictable numbers.
>
>The problem is that there is no nice portable way to get high-quality
>random numbers. EGD does the job, at the cost of running a large PERL
>daemon. (currently one for each user).
>
>I have a patch which will enable users to run only one EGD per machine
>and have it serve entropy over a localhost TCP socket. This is still
>less than optimal, and I don't think that EGD has been designed for
>this. For instance, it may be possible for one user to drain EGD's
>entropy pool so it either blocks (DoS) or produces degraded data.
>
>There are several options to pursue here:
>
>1. Revive the random code from ssh 1.2.16.
>2. Port the Linux or BSD kernel random driver to userspace
>3. Port Yarrow[1]
>4. Fix EGD
>5. Roll our own
>
>I think that if we are going to change the random source, then we
>should use something that has been subjected to review. This precludes
>1, 5 and (to a lesser extent) 4. Porting Yarrow is to me the most
>attractive option, as it has been the subject of a formal design but
>this may take some time.
>
>-d
>
>[1] http://www.counterpane.com/yarrow.html
>
>--
>| "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)
>
>
>
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Quoting Gary E. Miller <gem@rellim.com>:
>
> I just checked out the Yarrow code again. It is very much WinXX code
> and would be a PTA to port to any flavor of UNIX. After the port it
> would not look anything like it does now...

The author in their paper say that there is a UNIX port. But I
mailed them about it and they didn't get back to me.

I agree that the code is full of yuck but we wouldn't need the
front-end and the back-end could be pretty simple. So this leaves
us with the task of porting the bit in the middle! Sadly, I can't
understand the M$ makefile-alike distributed with it.

All the same, this still leaves us with the same problem, namely
that of needing to have a daemon around all the time.

Cheerio,

Andrew.

Andrew Stribblehill wrote:
>
> The author in their paper say that there is a UNIX port. But I
> mailed them about it and they didn't get back to me.

I did the same thing, I also didn't get a reply.

>
> I agree that the code is full of yuck but we wouldn't need the
> front-end and the back-end could be pretty simple. So this leaves
> us with the task of porting the bit in the middle! Sadly, I can't
> understand the M$ makefile-alike distributed with it.
>

It's a quite simple build. All dirs except testapp compile into separate
libraries (hence the DllMain() stuff) and the resulting libraries are
copied to %systemroot%\system32. Testapp links against the dll export
files.

> All the same, this still leaves us with the same problem, namely
> that of needing to have a daemon around all the time.

We already have a daemon around all the time, sshd. There's no reason
why the entropy hooks and the yarrow code should be outside that.

FWIW I'm not saying there's anything wrong with a standalone PRNG daemon
- I actually think that would be a good thing, and others could benefit
from it. We could stir in good /dev/random output as additional entropy,
but still be portable to systems that lack such devices.

Ta,
-Andre

Quoting Andre Lucas <andre.lucas@dial.pipex.com>:
>
> > All the same, this still leaves us with the same problem, namely
> > that of needing to have a daemon around all the time.
>
> We already have a daemon around all the time, sshd. There's no reason
> why the entropy hooks and the yarrow code should be outside that.
>
> FWIW I'm not saying there's anything wrong with a standalone PRNG daemon
> - I actually think that would be a good thing, and others could benefit
> from it. We could stir in good /dev/random output as additional entropy,
> but still be portable to systems that lack such devices.

If we assume that sshd is around all the time, there is no way for
local users to login to other machines whilst disallowing ssh
logins to localhost. (A sort of runlevel-2 state.) If it's
considered that this is of minority interest, perhaps PRNG stuff
/should/ be compiled in.

Thanks,

Andrew Stribblehill
Systems Programmer, IT Service, University of Durham

Andrew Stribblehill wrote:
8<
> If we assume that sshd is around all the time, there is no way for
> local users to login to other machines whilst disallowing ssh
> logins to localhost. (A sort of runlevel-2 state.) If it's
> considered that this is of minority interest, perhaps PRNG stuff
> /should/ be compiled in.
>
Good point. The prng code would need to be linked into ssh as well as
sshd - as it is in ssh-1.2.27 - and the state would be picked up from a
file. The biggest problem I see with that would be that the ssh
executable would have to be setuid <whatever> to access the seed and key
files if there was no other program running to manage this.

IMHO the best way is indeed to have a standalone daemon. Reading output
from a pipe, it's as close to a portable random device as we're likely
to get. EGD is good, but because it's written in Perl it's slow and big.
With a C prng as a separate program it should be easier to maintain, and
it would be easier to protect the statefiles that Yarrow wants. I can't
think of a reason why it would have to run as root, either.

Ta,
-André

On Mon, Jan 31, 2000 at 11:18:43AM +0000, Andre Lucas wrote:
> Andrew Stribblehill wrote:
> 8<
> > If we assume that sshd is around all the time, there is no way for
> > local users to login to other machines whilst disallowing ssh
> > logins to localhost. (A sort of runlevel-2 state.) If it's
> > considered that this is of minority interest, perhaps PRNG stuff
> > /should/ be compiled in.
> >
> Good point. The prng code would need to be linked into ssh as well as
> sshd - as it is in ssh-1.2.27 - and the state would be picked up from a
> file. The biggest problem I see with that would be that the ssh
> executable would have to be setuid <whatever> to access the seed and key
> files if there was no other program running to manage this.
>
> IMHO the best way is indeed to have a standalone daemon. Reading output
> from a pipe, it's as close to a portable random device as we're likely
> to get. EGD is good, but because it's written in Perl it's slow and big.
> With a C prng as a separate program it should be easier to maintain, and
> it would be easier to protect the statefiles that Yarrow wants. I can't
> think of a reason why it would have to run as root, either.

In my case, I have many users who run a non-setuid ssh (1.2.27) client on
machines that do not have sshd running.

I do not understand why people seem to dislike the idea of generating the
initial random number from an entropy source and from then on saving a seed
in a file. That's what ssh 1.2.27 and PGP do; have they been criticized
for that? Sure it's a problem if somebody is able to break into your
machine and read the seed file, but if somebody can do that then all bets
are off anyway. GnuPG also does not save anything in a seed file, so there
must be something to it. Perhaps people are worried about physical seizing
of hardware; I'm not worried about that, and besides I don't see how that
would be an issue for OpenSSH because it has nothing to protect once the power
has been turned off on a machine thus tearing down all SSH sessions. GnuPG
is different in that respect because if somebody seized the seed file they
may be able to guess what random key was used to encrypt data in a file.

- Dave Dykstra

Dave Dykstra wrote:
8<
> I do not understand why people seem to dislike the idea of generating the
> initial random number from an entropy source and from then on saving a seed
> in a file. That's what ssh 1.2.27 and PGP do; have they been criticized
> for that? Sure it's a problem if somebody is able to break into your

I don't have the slightest concern about saving the PRNG state. Sorry if
it came across that way.

I do think that there's no need for the randseed to be exposed if you
don't have to, as it's part of the PRNG's state and so Its Disclosure Is
Probably A Bad Thing. Even though it is immediately stirred into the
real-time entropy pool, if it wasn't an important component of the PRNG
state there would be no point in saving it. All the Counterpane PRNG lit
suggests that state compromise attacks are truly bad, and even if Yarrow
is resistant to them I don't see the need to risk it.

8<
> has been turned off on a machine thus tearing down all SSH sessions. GnuPG
> is different in that respect because if somebody seized the seed file they
> may be able to guess what random key was used to encrypt data in a file.

I'm no authority of any kind on PRNG implementations or the software
you've listed. So this is just a barely educated opinion. I think it's a
good thing to save the random seed, as if you have confidence in your
PRNG it's a good random value with which to initialise the generator.
Since my understanding is that good entropy is hard to find(tm), why
waste it?

Ta,
-Andre

>
> - Dave Dykstra

Yo All!

A archive of the discussions on /dev/random from the linux-ipsec
and coderpunks mailing lists is at:
http://www.openpgp.net/random/index.html

They have already covered this territory at length.

There is also the source to a linux kernel /dev/random on that
website and in it's doc the recommendation is made to save the entropy.

I think the end result was that it was best to save what entropy
that you had between sessions. Since this saved entropy should
just be stirred in with whatever new entropy you can find, then
you should never be worse off even if the old entropy is compromised.

RGDS
GARY

On Mon, 31 Jan 2000, Andre Lucas wrote:

> I'm no authority of any kind on PRNG implementations or the software
> you've listed. So this is just a barely educated opinion. I think it's a
> good thing to save the random seed, as if you have confidence in your
> PRNG it's a good random value with which to initialise the generator.
> Since my understanding is that good entropy is hard to find(tm), why
> waste it?

---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676

On Tue, Feb 01, 2000 at 01:08:06PM -0800, Gary E. Miller wrote:
> Yo All!
>
> A archive of the discussions on /dev/random from the linux-ipsec
> and coderpunks mailing lists is at:
> http://www.openpgp.net/random/index.html
>
> They have already covered this territory at length.

The access to the archive is kind of slow so I haven't seen it all, but I
haven't spotted where they're talking about avoiding the use of
/dev/random. Ipsec is a different situation because by its nature it will
not be portable and, unlike ssh, they can make operating system changes.

> There is also the source to a linux kernel /dev/random on that
> website and in it's doc the recommendation is made to save the entropy.
>
> I think the end result was that it was best to save what entropy
> that you had between sessions. Since this saved entropy should
> just be stirred in with whatever new entropy you can find, then
> you should never be worse off even if the old entropy is compromised.
>
> RGDS
> GARY
>
> On Mon, 31 Jan 2000, Andre Lucas wrote:
>
> > I'm no authority of any kind on PRNG implementations or the software
> > you've listed. So this is just a barely educated opinion. I think it's a
> > good thing to save the random seed, as if you have confidence in your
> > PRNG it's a good random value with which to initialise the generator.
> > Since my understanding is that good entropy is hard to find(tm), why
> > waste it?


Ok, maybe I'm missing something. If you have a good initial seed to your
PRNG and you save it in a protected file the way ssh 1.2.27 does, is there
any problem with not using the EGD (or /dev/random because it's not
available)? We could take some of the code from the EGD (ported to C) or
from some other open source package to get the initial seed, when we don't
mind spending a little extra time, and from then on do things more quickly
without the aid of an external program or driver. Right?

- Dave Dykstra

Yo Dave!

The whole point of /dev/random is to add entropy to PNRG. The problem
with a PNRG is that once you figure out the internal state of the PNRG
you can recover past states and predict future states. Once you can
predict states, even if the prediction is slightly off, then you have
seriously reduced the strength of the encryption.

This is the basis of the cracks for S/Key and some other crypto.

The solution to this problem is to add entropy to your PNRG to make
it more truly random. That is why openssh wants to use /dev/random
or EGD at regular intervals. EGD is to much of a pig and /dev/random
requires kernel patching. So I agree with you that porting something
like EGD to C is the way to go.

FreeS/WAN struggled with this issue for a while and then decided
to just go with /dev/random. open-ssh does not have that option.

RGDS
GARY

On Tue, 1 Feb 2000, Dave Dykstra wrote:

> Date: Tue, 1 Feb 2000 15:55:40 -0600
> From: Dave Dykstra <dwd@bell-labs.com>
> To: Gary E. Miller <gem@rellim.com>
> Cc: openssh-unix-dev@mindrot.org
> Subject: Re: EGD requirement a show stopper for me
>
> On Tue, Feb 01, 2000 at 01:08:06PM -0800, Gary E. Miller wrote:
> > Yo All!
> >
> > A archive of the discussions on /dev/random from the linux-ipsec
> > and coderpunks mailing lists is at:
> > http://www.openpgp.net/random/index.html
> >
> > They have already covered this territory at length.
>
> The access to the archive is kind of slow so I haven't seen it all, but I
> haven't spotted where they're talking about avoiding the use of
> /dev/random. Ipsec is a different situation because by its nature it will
> not be portable and, unlike ssh, they can make operating system changes.
>
> > There is also the source to a linux kernel /dev/random on that
> > website and in it's doc the recommendation is made to save the entropy.
> >
> > I think the end result was that it was best to save what entropy
> > that you had between sessions. Since this saved entropy should
> > just be stirred in with whatever new entropy you can find, then
> > you should never be worse off even if the old entropy is compromised.
> >
> > RGDS
> > GARY
> >
> > On Mon, 31 Jan 2000, Andre Lucas wrote:
> >
> > > I'm no authority of any kind on PRNG implementations or the software
> > > you've listed. So this is just a barely educated opinion. I think it's a
> > > good thing to save the random seed, as if you have confidence in your
> > > PRNG it's a good random value with which to initialise the generator.
> > > Since my understanding is that good entropy is hard to find(tm), why
> > > waste it?
>
>
> Ok, maybe I'm missing something. If you have a good initial seed to your
> PRNG and you save it in a protected file the way ssh 1.2.27 does, is there
> any problem with not using the EGD (or /dev/random because it's not
> available)? We could take some of the code from the EGD (ported to C) or
> from some other open source package to get the initial seed, when we don't
> mind spending a little extra time, and from then on do things more quickly
> without the aid of an external program or driver. Right?
>
> - Dave Dykstra
>

---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676