Entropy and DSA key

[mouring at etoh.eviladmin.org]

On Tue, 6 Nov 2001, Ed Phillips wrote:
[..]
>
> 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?
>
Respectly, Ed.. Don't put words in my mouth.  I have not, nor have I
ever since I started this thread talked about the current entropy system
and about how we are 'not going to fix it'.  My focus has been on finding
a better place for it.  Hopefully external from OpenSSH proper.

Be it in the form of OpenSSL modification.
Be it in the form of a 3rd party library.
Be it in the form of a little black monkey that runs around shoving
bananas up people rear-ends and collecting the sound to create entropy
which it magicly shove it into OpenSSH.

I really dislike when people do that.

> 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?
>
RAND_add() allows you to add entropy to the OpenSSL internal pool, and
as far as I'm aware of arc4random or OpenSSL pools are used only.


I'm only looking to see if people can agree that we can deal with entropy
via OpenSSL or some other way and still have to be 'acceptable' to
99% of the world!  I'm not looking for a 45 day discussion argument as to
what is wrong with our current system.  If I can get a tolerable feed back
I can look at it in December when I regain my home network from the four
corners of the earth.

- Ben