On Thu, Jan 13, 2000 at 17:34:10, Andre Lucas wrote:> Subject: /dev/urandom > On Thu, Jan 13, 2000 at 09:24:01AM -0700, SysProg - Nathan Paul Simons wrote: > > On Thu, 13 Jan 2000, Ben Taylor wrote: > > > > > On Thu, 13 Jan 2000, Max Shaposhnikov wrote: > > > > why ssh1.27 doesn't requre /dev/urandom on solaris? > > > > i think the commercial ssh uses a one time generated random > > seed file. If i remember, it asks you to bang on the keyboard until it > > gets enough entropy, like PGP. It also might have its own internal code > > that does the same thing egd or /dev/urandom on linux does. > > It works like EGD. In SSH 1.2.27, It hashes the output of various system > state commands (e.g. ps, ls -alni /tmp, w, netstat) . Check out > randoms.c . > > In SSH 2.0.9, it doesn't run commands (all those fork()s can't have been > too good for the program's efficiency...) but instead pulls in entropy > from sources like /dev/random, system clock, getrusage(), etc. > > To be honest, the entropy pool doesn't look to be that large, even in > v2. If your system doesn't have getrusage then (at first glance, ok?) > looks like they're using the system clock and the saved state as IVs, > which doesn't seem very random at all. They're getting a less thorough > stir than with EGD, too.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 need a mechanism like the one used in commercial ssh, where the random seed is saved in a file. - Dave Dykstra
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 at mindrot.org (home) -or- djm at ibs.com.au (work)
> Date: Fri, 28 Jan 2000 10:05:00 +1100 (EST) > From: Damien Miller <djm at mindrot.org> > To: Dave Dykstra <dwd at bell-labs.com> > Cc: openssh-unix-dev at 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 at 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 at 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 at mindrot.org> >To: Ben Lindstrom <mouring at pconline.com> >CC: Dave Dykstra <dwd at bell-labs.com>, openssh-unix-dev at 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 at mindrot.org (home) -or- djm at ibs.com.au (work) > > > >______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
Yo Niels! I think we basically agree, except you missed one point. SCO has no /dev/random, so open-ssh has no way of reseeding except with EGD. The problem is to find a portable way to reseed the PNRG on all UNIX hosts, even those with no /dev/random and without the problems of EGD. RGDS GARY On Wed, 2 Feb 2000, Niels Provos wrote:> Date: Wed, 02 Feb 2000 09:16:38 -0500 > From: Niels Provos <provos at citi.umich.edu> > To: gary miller <gem at rellim.com> > Cc: Dave Dykstra <dwd at bell-labs.com>, openssh-unix-dev at mindrot.org > Subject: Re: EGD requirement a show stopper for me > > In message <Pine.LNX.4.21.0002011450370.22282-100000 at ns1.aplatform.com>, "Gary > E. Miller" writes: > >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. > OpenSSH uses the alleged RC4 stream cipher to stretch the randomness > provided by /dev/random into a longer interval. This is a sane > approach and as far as I can see is practially as secure as the > mathematical requirements for pseudo-random generators. Furthermore, > RC4's internal state is reseeded fairly often from /dev/random. > Looking at purely statistical tests, using RC4 is far better than the > raw output from /dev/random - at least the last time that I checked on > it. > > Niels. >--------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676