Entropy collection in sshd (was Re: Entropy and DSA key)

Nicolas Williams Nicolas.Williams at ubsw.com
Wed Nov 7 05:33:40 EST 2001


On Tue, Nov 06, 2001 at 09:50:37AM -0800, Darren J Moffat wrote:
> Lutz Jaenicke wrote:
> > The problem is not sshd. sshd startup only happens once and it does not
> > matter whether it takes 0.5 seconds or 5 seconds; the server will be up
> > for hours/days/weeks anyway. (Re-seeding should happen over time.)
> 
> Startup time is important, both for the master listening daemon and
> for the children it forks to handle connections.
> 
> It might not matter to you but on servers that have uptime guarantees
> specified in the fractions of a percent very little second on a reboot
> counts.
> 
> 5 seconds on a test machine could translate into 30 on a production
> machine or older hardware.

Agreed. For example, the Sun cryptorand daemon takes longer to start up
on machines with lots of RAM, and you may have to wait minutes before
you can login to a rebooted server, even though it's up already.

> I'm infavour of removing all entropy gathering code from OpenSSH,
> including the use of arc4random and the private pool it keeps. I would
> much rather see /dev/urandom used directly each time. I have
> profiled this on Solaris and there wasn't a noticable difference in
> performance for time spent reading /dev/urandom verses using arc4random.
> What I did was open /dev/urandom the first time it was needed and leave
> it open for the duration but just read the requested number of bytes
> from it each time.  Doing this has the side effect that rc4 can be
> removed from the list of required crypto algorithms.

Darren,

Does this mean that Sun will put out a /dev/urandom? For any OS version
earlier than Solaris 9?

My current thoughts on handling /dev/[u]random on Solaris 26, 7 and 8 in
the absence of something concret from Sun are:

 - use ANDIrand for /dev/urandom -- it's non-blocking
 - use Sun's cryptorand for /dev/random -- it's blocking
 - at boot time seed /dev/urandom with a root-read-only seed file
 - periodically re-seed /dev/urandom with data from /dev/random
 - periodically re-create the boot-time seed file from output of /dev/random

Ideally there'd be a /dev/urandom non-blocking driver that knows how to
gather entropy; ANDIrand is very weak in that area.

> --
> Darren J Moffat


Cheers,

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.




More information about the openssh-unix-dev mailing list