|| ||Linus Torvalds <torvalds-AT-linux-foundation.org> |
|| ||Willy Tarreau <w-AT-1wt.eu> |
|| ||Re: [Security] [patch] random: make get_random_int() more random |
|| ||Sat, 16 May 2009 08:23:11 -0700 (PDT)|
|| ||Ingo Molnar <mingo-AT-elte.hu>, security-AT-kernel.org,
Cox <alan-AT-lxorguk.ukuu.org.uk>, Arjan-AT-hera.kernel.org,
List <linux-kernel-AT-vger.kernel.org>, Alan-AT-hera.kernel.org,
Eric Paris <eparis-AT-redhat.com>, Jake Edge <jake-AT-lwn.net>,
"Eric W. Biederman" <ebiederm-AT-xmission.com>,
Matt Mackall <mpm-AT-selenic.com>, Dave Jones <davej-AT-redhat.com>,
James Morris <jmorris-AT-namei.org>,
Andrew Morton <akpm-AT-linux-foundation.org>,
Roland McGrath <roland-AT-redhat.com>,
de Ven <arjan-AT-infradead.org>|
|| ||Article, Thread
On Sat, 16 May 2009, Willy Tarreau wrote:
> I don't agree with your point. It is good when the user must choose
> between performance and security.
Well, quite frankly, historically "get_random_int()" has been exactly
It's based very much on top of the random number generator for networking,
where performance was a primary goal. It's why the code has that
re-seeding with "real" randomness that happens once a minute (or
whatever): exactly because "real" randomness was too expensive (and would
deplete the entropy pool).
So "get_random_int()" has _always_ been about a choice between performance
and security. Ok, it's not been a "user" choice, but the thing is, most
users really aren't capable of that choice - they may not think they care,
until they get hacked (and not even necessarily then - the _bulk_ of
hacked computers probably end up being used for DDoS kind of things, so
the user itself is not even the primary target).
So I don't think that there are "insecure" and "secure" users - yes,
there are people who care more, and people who care less, but we need to
protect the people who care less even just to protect the people who care
But there very much _are_ performance vs "strength of hash" issues. And
historically, "get_random_int()" has leaned towards the performance thing.
It's just that it had a really outrageously stupid weakness that wasn't
even really helping performance.
I think we've fixed the "outrageously stupid" part. It would certainly be
good to make it even better.
And yes, giving out more of our pool (by remembering which part we've
already given out) would make it possible to use a more expensive hash.
But at the same time, I personally suspect that it would be _much_ easier
to attack the hash if we actually gave out the whole 16 bytes (over
several iteration), when compared to what we do now (only give out a small
part and then re-hash). I can't back that up with any proofs, though, but
I suspect it's much harder to re-generate the hash if you never see more
than a very small part of the output.
(That's especially true since whatever we do, the _one_ thing we can never
do is to actually hide what hash we use. We can hide the data, but we
can't hide the code. Others depend on also making it harder to guess
even what the algorithm for the hash itself is).
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)