Re: [Security] [PATCH] proc: avoid information leaks to non-privileged processes

[Florian Weimer]

* Matt Mackall:

> On Wed, May 06, 2009 at 09:48:20AM -0700, Linus Torvalds wrote:
>> 
>> Matt, are you willing to ack my suggested patch which adds history to the 
>> mix? Did somebody test that? I have this memory of there being an 
>> "exploit" program to show the non-randomness of the values, but I can't 
>> recall details, and would really want to get a second opinion from 
>> somebody who cares about PRNG's.
>
> I still don't like it. I bounced it off some folks on the adversarial
> side of things and they didn't think it looked strong enough either.
> Full MD5 collisions can be generated about as fast as they can be
> checked, which makes _reduced strength_ MD4 not much better than an
> LFSR in terms of attack potential.

Well, with periodic reseeding, even that shouldn't be a problem.  You
don't need collision resistance at all, so those MD5 attacks don't
tell you anything about the difficulty of state recovery/prediction
attacks on your variant.  (The trouble with hash functions is that
they haven't got any secrets to work from.  With seeded PRNGs, this is
obviously different.)

On the other hand, most people who need a quick, unpredictable source
of randomness seem to use RC4 with a random key initialized from a
more costly source.  (If you're paranoid, you should discard the first
few hundred bytes.)  The nice thing is that you can use a well-tested
primitive, unchanged, so it's easier to avoid nasty suprises.

Oh, and you should really, really ditch that Tausworthe generator (in
lib/random32.c).

-- 
Florian Weimer                <fweimer@xxxxxx>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/