Entropy and DSA key

[Tim McGarry]

Why don't we require less entropy on slower machines, who wants to break
into a SS1 or IPX anyway.

Tim
----- Original Message -----
From: "Ed Phillips" <ed at UDel.Edu>
To: <mouring at etoh.eviladmin.org>
Cc: "Dave Dykstra" <dwd at bell-labs.com>; <openssh-unix-dev at mindrot.org>
Sent: Tuesday, November 06, 2001 9:51 PM
Subject: Re: Entropy and DSA key


> 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
>
>