mainGnuTLS - Support: sr #106113, Be nice and feed entropy back to...

 
 

sr #106113: Be nice and feed entropy back to /dev/random

Submitter:  Marc Haber <zugschlus>
Submitted:  Wed 05 Dec 2007 03:09:59 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  1 - Wish Status:  Wont Do
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 09 Jan 2008 12:04:42 PM UTC, comment #4: 

Closing the bug, pending more concrete suggestions/patches to review.

/Simon

Simon Josefsson <jas>
Group administrator
Fri 04 Jan 2008 03:20:35 PM UTC, comment #3: 

I have several objections to this idea.

First, gnutls have no idea whether some data to be encrypted is available to the adversary or not.   So the idea is not even possible to implement as far as I see.  Most of the data is sent over TLS is easily available to adversaries.  It is standard HTTP or IMAP protocol contents.

Second, this isn't portable, and will clutter the gnutls code with linux-specific hacks.  This behaviour of /dev/*random isn't even POSIX standardized as far as I know.  Working arounds others' problems is something we try hard to avoid cluttering our code for.

I am also generally uncomfortable with sending unencrypted, security-sensitive stuff into a file.  It can leads to back doors all too easily.

I'm changing the status to 'Wont Do'.   I'm not ruling out that we do something here, but right now exactly what is not at all clear to me, and generally seems much more appropriate for either libgcrypt or the kernel folks to handle.

/Simon

Simon Josefsson <jas>
Group administrator
Fri 04 Jan 2008 02:57:11 PM UTC, comment #2: 

It wouldn't solve the issue, but gernerally improve the quality of the kernel's entropy pool. At least that's what i understood from Ted's message.

Marc Haber <zugschlus>
Fri 04 Jan 2008 12:26:22 PM UTC, comment #1: 

As far as I understand Ted Tso's comment, this wouldn't increase the random entropy counter, so doing this wouldn't really solve the depletion-of-randomness problem, would it?

/Simon

Simon Josefsson <jas>
Group administrator
Wed 05 Dec 2007 03:09:59 PM UTC, original submission:  

Hi,

Ted Tso suggested the following on the LKML:

> BTW, note that it would be a polite thing for GnuTLS when it is
> encrpyting data, which represents information which might not be
> available to an adversary, and SHA1 hash it (out of paranoia) and feed
> it to /dev/random.


> This won't give any "credits" to the random entropy counter, but to
> the extent that is information that isn't available to the adversary,
> it adds additional uncertainty to the random pool.


Please consider doing this in a future release.

Greetings
Marc

Marc Haber <zugschlus>

 

(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 jas (Posted a comment)
  • -email is unavailable- added by zugschlus (Submitted the item)
  •  

    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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-01-09 jas Open/ClosedOpen Closed
    2008-01-04 jas StatusNone Wont Do

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code