Bug 32675

Summary: openssl dhparam hangs when using /dev/random as entropy source
Product: Base System Reporter: clemens fischer <ino-waiting>
Component: binAssignee: Kris Kennaway <kris>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.3-RELEASE   
Hardware: Any   
OS: Any   

Description clemens fischer 2001-12-10 17:30:00 UTC 
i wanted to create a set of diffie-helman paramters for later key
generation using the following commands, and i wanted to seed
openssl-0.9.6b's PRNG using /dev/[u]random:

#openssl dhparam -outform PEM -out /l/ssl/pem/dh1024.pem -5 \
		-rand /dev/random:/dev/urandom 1024
^C

#openssl dhparam -outform PEM -in /dev/null -out /l/ssl/pem/dh512.pem -2 \
		-rand /dev/urandom
Killed

Fix: 

there is a simple workaround:  *not* using the "-rand /dev/random" option,
eg:

#openssl dhparam -outform PEM -in /dev/null -out /l/ssl/pem/dh512.pem -2
warning, not much extra random data, consider using the -rand option
Generating DH parameters, 512 bit long safe prime, generator 2
This is going to take a long time
..........+.........................++*++*++*++*++*++*

then it always *works*!

clemens fischer
How-To-Repeat: 
using /dev/random to seed openssl in this particuliar application will
always make openssl chew up CPU upto 99%, and it will run producing no
output until interrupted forcibly.
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 2001-12-30 12:25:34 UTC 
Responsible Changed
From-To: freebsd-bugs->kris

Over to the openssl maintainer.
Comment 2 Kris Kennaway 2002-01-05 04:59:12 UTC 
On Mon, Dec 10, 2001 at 06:23:32PM +0100, clemensF wrote:

> using /dev/random to seed openssl in this particuliar application will
> always make openssl chew up CPU upto 99%, and it will run producing no
> output until interrupted forcibly.

/dev/random is a very low-output device which only produces output
when there is entropy available to the kernel.  It's entirely expected
that openssl dhparam would take an extremely long time to run if
you're using this device; that's why /dev/urandom is the default
entropy source.  I expect if you left it run long enough it would
actually finish, it just might take quite a while, especially if you
don't have many entropy sources defined via rndcontrol.

Kris
Comment 3 Kris Kennaway freebsd_committer freebsd_triage 2002-01-05 05:00:42 UTC 
State Changed
From-To: open->analyzed

I believe this is expected behaviour due to the low output 
rate of the /dev/random device in 4.x
Comment 4 ino-E24f64e8 2002-01-05 13:48:15 UTC 
> Kris Kennaway:

> /dev/random is a very low-output device which only produces output
> when there is entropy available to the kernel.  It's entirely expected
> that openssl dhparam would take an extremely long time to run if

yes, that makes sense.  i'm wondering though, why openssl doesn't just sit
and wait until more entropy becomes available.  isn't it funny that it
idles taking so much CPU?

> you're using this device; that's why /dev/urandom is the default
> entropy source.  I expect if you left it run long enough it would
> actually finish, it just might take quite a while, especially if you
> don't have many entropy sources defined via rndcontrol.

which interrupts can be used safely forgathering entropy?  i had massive
problems when experimenting with the entropy sources culminating in an
unusable system.

clemens fischer
Comment 5 Kris Kennaway 2002-01-05 19:04:57 UTC 
On Sat, Jan 05, 2002 at 02:48:15PM +0100, clemensF wrote:
> > Kris Kennaway:
> 
> > /dev/random is a very low-output device which only produces output
> > when there is entropy available to the kernel.  It's entirely expected
> > that openssl dhparam would take an extremely long time to run if
> 
> yes, that makes sense.  i'm wondering though, why openssl doesn't just sit
> and wait until more entropy becomes available.  isn't it funny that it
> idles taking so much CPU?


Yes, I suppose it is - that's something you should take up with the
OpenSSL developers.

> > you're using this device; that's why /dev/urandom is the default
> > entropy source.  I expect if you left it run long enough it would
> > actually finish, it just might take quite a while, especially if you
> > don't have many entropy sources defined via rndcontrol.
> 
> which interrupts can be used safely forgathering entropy?  i had massive
> problems when experimenting with the entropy sources culminating in an
> unusable system.


Well, just don't use things like rtc or clk which have really high
rates and you should be fine...

Kris
Comment 6 Kris Kennaway freebsd_committer freebsd_triage 2002-08-24 04:48:37 UTC 
State Changed
From-To: analyzed->closed

Issue was determined to be the expected behaviour, although 
the performance of OpenSSL could possibly be improved in this 
case.