[linux-elitists] ssh hygiene

Aaron Lehmann aaronl@vitelus.com
Tue Apr 30 11:34:14 PDT 2002

On Mon, Apr 29, 2002 at 10:51:29PM -0700, Don Marti wrote:
> When generating keys for SSH version 2 should you pick RSA or DSA?

DSA, definately. There's a lot of new cryptanalysis I've heard about
with RSA. For example, a huge percentage of the possible keys are
"weak". I wish people published these accademic papers on the

DSA is thought to be slightly stronger at similar key sizes. See

> Any compelling reason to use Blowfish instead of triple-DES?

It's a difficult descision. Triple DES has a key that's about as
secure as a 112 bit key to a normal cipher. Blowfish is probably used
with a 128 bit key by SSH. DES was designed in part by the NSA, but
it's undergone the most cryptanalysis of any algorithm and is thought
to be secure. I prefer Blowfish becuase it's a much similar algorithm
and I can know it by heart. Even the Blowfish creator admits that the
ultraconservative should opt for triple-DES, though.

A more practical matter is that blowfish is much, much faster than
3DES in software. This is very noticable when transfering files using
scp, forwarding x11, etc.

> If you're going to go somewhere, set up a new account, and log in
> from there to your account back home, it makes sense to have the
> key fingerprints for your known_hosts on a piece of paper in your
> wallet -- right?


One major issue about ssh's security that I've been meaning to bring
up is its abuse of semi-secure random number. Rather than using
Linux's urandom device directly, or, perhaps better, using the random
device and blocking until bits are available, it seeds its own RNG
with a few bytes from urandom. This really sucks. First of all,
urandom is just a random number generator seeded by the random device,
which is thought to have a good amount of entropy. Even urandom itself
should not be used for generating keys. But ssh (at least openssh)
commits a worse offense: it uses urandom, a prng seeded by
/dev/random, to seed its own prng, and then uses that to generate
keys. More layers == bad. It really should read key bits directly from
/dev/random and wait for entropy to become available rather than
passing the bits through two PRNGs. If blocking is a major problem, I
can't see why they couldn't take the middle ground and read random
bits directly from /dev/urandom. You aren't going to add any security
by using this as a seed instead of a random source (the kernel's prng
looks better than openssl's, and it has the advantage of being
continuously reseeded by hardware interrupts; plus it's faster to
avoid running multiple random number generators in series). By nature,
this kind of flaw is very difficult to exploit or even analyze, but I
still think they should be concerned about it. After all, the SSL in
early versions of netscape was broken through a crappy PRNG.

More information about the linux-elitists mailing list