Entropy and DSA key

[mouring at etoh.eviladmin.org]

On Tue, 6 Nov 2001, Dan Astoorian wrote:

[..]
> In summary, the way I'd like to see things is:
>     - OpenSSH: doesn't need to do *anything* explicit to seed OpenSSL's
>       PRNG
>     - OpenSSL: tries, in order:
> 	a) /dev/[u]random
> 	b) connecting to PRNGD

The following two things could be done today minus support for PRNGD
sockets.  Until that feature is supported it will not simplify the code
very much (from what I can see).

> 	c) running an entropy-gathering program--let's call it
> 	"entropy-client"
>     - PRNGD: operates much as it does now (but rewrites its seed file
>       more often)
>     - entropy-client: if PRNGD isn't running, runs the same programs
>       PRNGD would to get its entropy (albeit less efficiently), mixes in
>       and perturbs the same seed file.
>

In general the idea is fine.. Assuming..

a) You get people to upgrade OpenSSL to the 'lastest'.  Which is a hard
sell in some cases.  (RAND_egd() has existed since 0.9.5)

b) For older installs you still need some 'fall back'.  Or pretty much
your saying 'upgrade or leave'.

c) How does this support OpenSSL staticly compiled into OpenSSH (something
I would not support, but others may be required for multiple location
support).

d) a 'One shot' PRNGd may be another way to look at it, but it is no
better/worse than linking to a libprngd.a  or libegd.a  or what-not.

I would perfer OpenSSL handle all the entropy behind the scenes.  It would
make our life easier in the portable group.  However it only removes
around 1000 lines of code in a 55,000 line project (I'm refering to
portable.  OpenBSD's ssh tree is 45,000 lines.).

No matter the way you cut it.  Not everyone will be happy until
/dev/{u}random suddenly appears on every box in the world.

I do have servers that lack /dev/{u}random so I am also affecting myself.
As I told someone from IBM, I'm looking at a 2 - 3 year phase over.  Not
something that will happen in 3.1 in 6 months or so.  Yanking out
functionality that people know and depend on is always a *BAD* thing
without phasing in a new feature to replace it.

- Ben