Entropy and DSA key

[Ed Phillips]

On Tue, 6 Nov 2001 mouring at etoh.eviladmin.org wrote:

> Date: Tue, 6 Nov 2001 13:44:55 -0600 (CST)
> From: mouring at etoh.eviladmin.org
> To: Dave Dykstra <dwd at bell-labs.com>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Entropy and DSA key
>
>
>
> On Tue, 6 Nov 2001, Dave Dykstra wrote:
>
> > > Before someone jumps up and starts screaming.  I'm not proposing we
> > > suddenly drop it.  The proposal is this (not set in stone mind you):
> > >
> > > 3.1 - Make internal entropy --with-* option and not enabled by default.
> > > Provide warnings at that screen and provide locations to PRNGd.  Warn
> > > about how it will be removed in a future release.
> >
> > I don't mind a configure option.
> >
>
> So can we at least agree that Internal Entropy should *NOT* be enabled
> unless someone enables it via a ./configure option?  At least starting in
> 3.1 and later?
>
> > > 3.5 - ? Provide ability to link with a libprngd.a instead of compiling w/
> > > our internal entropy.
> >
> > No problem.  I assume libprngd.a would be part of the prngd package then,
> > not the OpenSSH package, and since you wouldn't have to maintain it, it
> > would make your life easier.
> >
> That was my initial idea yes.
>
> > > 4.0 - ? Remove internal entropy code.
> >
> > Are you saying you would continue support of libprngd.a?  If so, why not
> > take out the internal entropy code at the same time you switch to libprngd.a
> > in 3.5?
> >
> No.  In my world view there needs to be an overlap.  A few releases of
> 'warning' that the internal entropy code is being removed before it
> actually occurs.  This should be reserved for major release numbers.

If the internal entropy collection is not going to be "fixed up" then I
say just nix it right now with 3.0.  If the code needs to hang around
until version 4.0 anyway, then why not fix it up to be the best it can be?
What amazing new features are going to require so much development time
that there just no time to fix it up over the next year or however long it
takes to get to another major release?

Also, someone mentioned that we should ditch it because OpenSSL should be
the one to worry about getting good random bits. Does the OpenSSL API
require an application to supply the random bits as arguments to the API
routines, or does the API need a callback set by the app to get random
bits, or something else?  The SSH v1/v2 protocol doesn't require any
random bits itself?

Maybe we should all go out and get a random number device that we can plug
into the serial port on our SS1s and IPCs and LXs and enhance OpenSSH to
just read random numbers from the serial port at 2400 bps... ;-P

Heck, how many random bits do you actually need for sshd to receive a
single client connection?  I could bang in more bits faster on the
keyboard than my SS1+ can get from running all the ssh_prng_cmds...

I know... "Put a sock in it Ed!"

	Ed

Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l ed at polycut.nss.udel.edu for PGP public key