[lkml]   [2011]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] random: add blocking facility to urandom wrote:
> On Fri, 09 Sep 2011 10:21:13 +0800, Sandy Harris said:
>> Barring a complete failure of SHA-1, an enemy who wants to
>> infer the state from outputs needs astronomically large amounts
>> of both data and effort.
> So let me get this straight - the movie-plot attack we're defending against is
> somebody readin literally gigabytes to terabytes (though I suspect realistic
> attacks will require peta/exabytes) of data from /dev/urandom, then performing
> all the data reduction needed to infer the state of enough of the entropy pool
> to infer all 160 bits of SHA-1 when only 80 bits are output...
> *and* doing it all without taking *any* action that adds any entropy to the
> pool, and *also* ensuring that no other programs add any entropy via their
> actions before the reading and data reduction completes. (Hint - if the
> attacker can do this, you're already pwned and have bigger problems)
> /me thinks RedHat needs to start insisting on random drug testing for
> their security experts at BSI. EIther that, or force BSI to share the
> really good stuff they've been smoking, or they need to learn how huge
> a number 2^160 *really* is....

Well, previously, we were looking at simply improving random entropy
contributions, but quoting Matt Mackall from here:

'I recommend you do some Google searches for "ssl timing attack" and
"aes timing attack" to get a feel for the kind of seemingly impossible
things that can be done and thereby recalibrate your scale of the


Note: I'm not a crypto person. At all. I'm just the "lucky" guy who got
tagged to work on trying to implement various suggestions to satisfy
various government agencies.

Jarod Wilson

 \ /
  Last update: 2011-09-12 16:01    [from the cache]
©2003-2011 Jasper Spaans