linux-kernel - Re: [Security] [patch] random: make get_random

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.01.0905160811550.3301@localhost.localdomain>
Date:	Sat, 16 May 2009 08:23:11 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Willy Tarreau <w@....eu>
cc:	Ingo Molnar <mingo@...e.hu>, security@...nel.org,
	Linux@...a.kernel.org, stable@...nel.org,
	Cox <alan@...rguk.ukuu.org.uk>, Arjan@...a.kernel.org,
	List <linux-kernel@...r.kernel.org>, Alan@...a.kernel.org,
	Eric Paris <eparis@...hat.com>, Jake Edge <jake@....net>,
	linux-security-module@...r.kernel.org, mingo@...hat.com,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Matt Mackall <mpm@...enic.com>, Dave Jones <davej@...hat.com>,
	James Morris <jmorris@...ei.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Roland McGrath <roland@...hat.com>,
	de Ven <arjan@...radead.org>
Subject: Re: [Security] [patch] random: make get_random_int() more random

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 
that.

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 
more ;)

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).

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/