bugtraq - Re: ssh host key generation in Red Hat Linux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20030725164912.M29161@borg.org>
Date: Fri, 25 Jul 2003 16:49:12 -0400
From: Kent Borg <kentborg@...g.org>
To: Ari Gordon-Schlosberg <regs@...corp.com>,
	Crispin Cowan <crispin@...unix.com>, bugtraq@...urityfocus.com
Subject: Re: ssh host key generation in Red Hat Linux

It has been pointed out that the Linux random driver will block if it
computes there is no entropy available, and this is correct.

However, last August there were bugs discovered in entropy accounting
that caused it to overestimate current entropy, and the Red Hat
2.4.20-19.9 kernel still doesn't seem to have the fix.  If one has a
lot of faith in md5, this isn't a problem on an up-and-running machine
with ~some~ source of entropy, but at very early points in the entropy
pool's life, the amount does matter when something very important is
being generating early on, such as ssh keys.  (Ironically, would
adopting the random fix, lock up a Red Hat first boot?)

Also, not everyone is comfortable with disk or network timings as
entropy sources.  Again, on a running machine, having too many entropy
sources, some of which might not actually have much entropy in them,
isn't a problem, but a fresh entropy pool is different.

Solution?  One approach is to delay creation of ssh keys.  (Or, as I
did, manually create new keys after one is certain there is enough
entropy available.)  Even if disk jitter is the only available entropy
source, waiting for more of it to accumulate would help.

And don't forget embedded Linux cases, such as routers, wireless
access points, etc., where there might not be a mechanical disk.  It
is not hard to imagine really getting hard up for entropy in a
factory-fresh box.  One idea I had recently is to hash the power up
state of a reasonable portion of RAM.  By no means are the initial
contents of RAM completely random, but RAM *is* volatile, I am pretty
sure it has some entropy in it.  Even if there is little entropy from
one power up to another power up of a given DRAM chip, there must be
some entropy between different physical chips.  A warm boot might have
extremely little to no entropy in RAM contents, but by that point some
entropy could have been stored from previously.  It is the really,
really cold boot that is the problem.

-kb, the Kent who wiggles the mouse on his basement server whenever he
walks by, a bit like a stroking rabbit's foot.

P.S.  A few months ago I wrote a RAM entropy grabber for embedded PPC,
but it is too groady in how it passes it to the kernel.