OpenSSH (portable) and entropy gathering

[Dan Astoorian]

On Fri, 05 Oct 2001 04:09:18 EDT, Damien Miller writes:
> > Unfortunately, sshd generally needs its entropy when it starts up, which
> > is typically just after boot time, when not that much entropy is
> > available from _any_ local source.
> 
> That is why the portable OpenSSH entropy code stores a seed file 
> between invocations.

Good point.  So, if "fallback to internal entropy" were configured, then
the seed file should be written even when using other sources of entropy
when they're available.  Doing so would actually improve the entropy in
the seed file most of the time.

(If sshd is started only at boot time, and root never runs the ssh
client, how good is the entropy in /.ssh/prng_seed?  I know the seed
file gets rewritten every time a fork()'d sshd exits, but still....)

> > (Suppose your host has crashed, and there's filesystem damage.  You're in
> > single-user mode, and your root filesystem is read-only pending an fsck.
> > Your socket was /etc/entropy, so prngd can't unlink it to start up
> > again.  You're missing a file that you need for the recovery procedure,
> > but you can't scp it over to /tmp because the ssh client won't run while
> > /etc/entropy exists and the daemon isn't up.
> 
> I'd rather not risk compromising the security of the entire system
> because of pathological corner cases. If we put an option in to use
> insecure entropy sources, then people will just use it anyway.

Well, while I can't argue that a system that can't be booted isn't
technically more secure than one using SSH with poor entropy, I'd find
that of little comfort when my phone is ringing off the hook because the
mail server is down.

If the seed file is written even when the internal entropy is not in
use, I don't see how "use EGD when available, fall back to internal
entropy generation" is less secure than "always use the internal entropy
generation" on hosts that don't have it available.

Even if it were less secure, I think that requiring the sysadmin to
explicitly compile in the support to fall back to the builtin code,
_plus_ requiring the user to confirm that they want to connect despite
the poor source of entropy, is a sufficient barrier that admins won't
generally do it unless they've weighed the security considerations
against the availability requirements.

OpenSSH still has the ability to enable RhostsAuthentication, and you
don't even have to explicitly configure that option in at compile time,
if I'm not mistaken.  And for compatability reasons, I believe the
client still supports "cipher none" (though the server, rightly, does
not).  I can't imagine that allowing ssh to be forced to proceed with
poor entropy is a bigger risk than those.

[OpenSSL automagically seeds itself from /dev/urandom, has EGD support:]
> The difficulty lies in knowing whether OpenSSL has been compiled with
> such support and whether or not it is working.

With respect to those sources which OpenSSL uses automatically,
RAND_status() solves that problem.  Entropy.c should probably check
RAND_status() before opening RANDOM_POOL or connecting to EGD.  OpenSSL
uses /dev/urandom transparently, and when OpenSSL 0.9.7 comes out it
will (I'm told) try to connect to EGD, also transparently.  If OpenSSH
also collects entropy from those sources when it doesn't need to, it
will deplete the entropy pool faster than necessary.

(My apologies if I've misread entropy.c and the code already does this.)

I'm not clear enough on the distinction between init_rng() and
seed_rng() to know whether it would be reasonable to check RAND_status()
from init_rng(), so that the internal code wouldn't be called if OpenSSL
could find enough entropy on its own.

Also: currently, OpenSSH compiles in the internal code if it cannot find
another source of entropy.  You could probably make it possible to
configure OpenSSH with *no* sources of entropy, i.e., have OpenSSH rely
entirely on OpenSSL to collect it, if you wanted to.

(I realize you hope to deprecate the internal code entirely; I think we
can substitute "call an external program to collect entropy" for "call
the internal entropy collection code" throughout, and the design issues
don't change much.)

Let me know if there's anything I can do to contribute, code-wise.  I'd
be willing to work on reorganizing the internal entropy collection code
into an external program and rewriting entropy.c to use it, but I don't
want to interfere with existing efforts.

Speaking of interfering with existing efforts, I do hope I'm actually
raising relevant design issues, and not merely distracting and
irritating you with this discussion....

-- 
Dan Astoorian               People shouldn't think that it's better to have
Sysadmin, CSLab             loved and lost than never loved at all.  It's
djast at cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican