mainGnuTLS - Support: sr #106112, Uses way too much entropy

 
 

sr #106112: Uses way too much entropy

Submitter:  None
Submitted:  Wed 05 Dec 2007 12:40:04 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  In Progress
Privacy:  Public Assigned to:  nmav
Originator Email:  -email is unavailable- Open/Closed:  Closed
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 03 Jul 2010 10:43:06 AM UTC, comment #5: 

In 2.11.x branch we are doing a move from libgcrypt to libnettle and among other advantages, it solves this issue as well.

Nikos Mavrogiannopoulos <nmav>
Group administrator
Thu 04 Jun 2009 09:22:54 AM UTC, comment #4: 

Have anyone seen problems with entropy starvation with modern libgcrypt/gnutls?

Libgcrypt still reads more bytes from /dev/urandom compared to OpenSSL does, but that is intentional as Libgcrypt is more conservative about the quality of /dev/urandom.

Fortunately, libgcrypt today reads considerable less data than before, though, because of a libgcrypt bug that has been fixed. 

So, the important question should probably be whether current approach causes problems for anyone.  Does it?  Recipies for reproducing it with modern libgcrypt/gnutls would be appreciated.

I'm marking this as Need Info.

Simon Josefsson <jas>
Group administrator
Tue 05 Feb 2008 08:20:00 AM UTC, comment #3: 

Given that GnuTLS uses libgcrypt right now, this is really a libgcrypt issue.  There are some similar bugs opened (thanks) regarding that, for example:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448825

There have been good progress on fixing that.  It may require changes in gnutls, but so far that isn't clear.  It seems it either can be solved within libgcrypt fully, or it requires help from application to save and restore a random seed.

The alternative is to consider other options than libgcrypt, and there is code for this in GnuTLS right now, but let's try to get the libgcrypt approach working first.  If people want to experiment, see the --with-builtin-crypto configure parameter and lgl/gc-gnulib.c.

Simon Josefsson <jas>
Group administrator
Thu 06 Dec 2007 04:03:38 PM UTC, comment #2: 

I have to disagree with this being a kernel bug. man 4 random on Linux documents how /dev/urandom behaves, and is supposed to behave.

"Some bytes" looks more like "a few hundred bytes", and Exim does not exhaust /dev/urandom as badly when OpenSSL is used. If GnuTLS wants to be a free (speech) alternative to OpenSSL, it does not need more issues that OpenSSL, it needs to do things actually better.

Marc Haber <zugschlus>
Thu 06 Dec 2007 09:11:27 AM UTC, comment #1: 

This looks more like a bug of the implementation of /dev/random and /dev/urandom rather than a gnutls bug. GnuTLS (libgcrypt) reads some bytes per process from /dev/urandom in order to be able to initialize it's PRNG. Since exim uses lots of processes the /dev/urandom pool could be exhausted. Since /dev/urandom is public the security of the system shouldn't depend on someone reading bytes from it.

Anonymous
Wed 05 Dec 2007 12:40:04 PM UTC, original submission:  

Hi,

When using

swaks --to mh@<hostname> --tls --server <servername>

with <servername> being a Debian sid box running exim4 linked against GnuTLS, this drops the server's entropy pool from from 3585 to 149 (or similar numbers, or course). This is way too much entropy usage. Please consider being a little less wasteful on resources.

man 4 random on Linux says that reading from /dev/urandom will first empty the system's entropy pool and only after depleting the local entropy pool will resort to a PRNG. That way, using GnuTLS-linked exim4 on a reasonably busy server will always keep the entropy pool near its minimum. Since the part of GnuTLS used by exim4 thankfully reads from /dev/urandom, exim itself will not block, but applications that need real entropy and trying to read from /dev/random will nearly always starve, leading to DoS in different parts of the system.

Exim4 linked against OpenSSL does not deplete the entropy pool nearly as badly as gnutls does. This difference between GnuTLS and OpenSSL can also nicely be seen with gnutls-serv compared to openssl s_server.

Please consider strongly to change to a scheme that only uses a few bytes from /dev/(u)random to seed a local PRNG.

Greetings
Marc

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nmav (Posted a comment)
  • -email is unavailable- added by jas (Posted a comment)
  • -email is unavailable- added by zugschlus (Posted a comment)
  • -email is unavailable- added by zugschlus
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-10-07 nmav Open/ClosedOpen Closed
    2010-07-03 nmav Assigned toNone nmav
        StatusNeed Info In Progress
    2009-06-04 jas StatusIn Progress Need Info
    2008-08-13 jas StatusNone In Progress
    2007-12-05 zugschlus Carbon-Copy- Added zugschlus

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code