[148067] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] randomness +- entropy

daemon@ATHENA.MIT.EDU (Hannes Frederic Sowa)
Thu Nov 7 00:32:11 2013

X-Original-To: cryptography@metzdowd.com
Date: Thu, 7 Nov 2013 03:36:54 +0100
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Theodore Ts'o <tytso@mit.edu>
In-Reply-To: <20131106124108.GI14235@thunk.org>
Cc: John Kelsey <crypto.jmk@gmail.com>, Watson Ladd <watsonbladd@gmail.com>,
	Cryptography <cryptography@metzdowd.com>,
	RNG mlist <rng@lists.bitrot.info>, John Denker <jsd@av8n.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

On Wed, Nov 06, 2013 at 07:41:08AM -0500, Theodore Ts'o wrote:
> On Wed, Nov 06, 2013 at 04:39:17AM +0100, Hannes Frederic Sowa wrote:
> > 
> > I am looking for other candidates which could be migrated (and are worth
> > it, given my limited time to work on this).  rc80211_minstrel_ht_init does
> > not look like a perfect fit, but I will have a fresh look tomorrow.
> 
> From my google searches on the minstrel algorithm (and I'm not enough
> of a networking expert to be authoratative), it appears that it just
> needs some random retry times for its learning algorithm.  It appears
> that it might be better if the random retry times chosen unique per
> host[1], but it didn't appear to have any security significance that I
> could see.

I agree, maybe one can prevent a nother wireless node to get a free slot to
send if the secrets are known. One could call that a DoS but it seems not that
important.

> [1] That's the one problem with prandom_init(); before it tries to
> reseed using get_random_bytes() as a late_initcall(), the initial
> state used for the prng doesn't appear to be very host-unique.

Hmm, couldn't we reseed as soon as the nonblocking buffer gets
initialized?

A check if entropy_store is the nonblocking_pool and call prandom_reseed()
just before or after we switch r->initialized to 1 in credit_entropy_bits
should do the trick. I currently cannot see any problems with that.

We could leave the late_initcall as-is as a fallback.

Greetings,

  Hannes

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

home help back first fref pref prev next nref lref last post