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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 16 May 2009 12:00:39 +0200
From:	Willy Tarreau <w@....eu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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 Fri, May 15, 2009 at 03:47:17PM +0200, Ingo Molnar wrote:
> 
> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> > On Thu, 14 May 2009, Jake Edge wrote:
> > >
> > > It seems like this should be queued up for stable, yes?  I just 
> > > saw the 2.6.29.4 review patches go out, but this wasn't part of 
> > > it ...
> > 
> > Well, I was hoping to maybe have actual timing numbers from some 
> > better hash, in case Matt can make one that is efficient enough. 
> > So I committed the randomness improvement as a clear _improvement_ 
> > over what we had, but it may not be the final version.
> 
> yep, it was just a quick hack really. If someone can do a stronger 
> hash that also happens to be faster i guess we all will be happy 
> campers. The performance figures showed room for improvement - how 
> well are those hashes optimized? Many thousands of cycles ... is 
> that really justified?

In fact we must keep in mind that those hashes produce far more data
than we need and we're throwing that data to the bin on every call.
If we use SHA1, we get 160 bits. We should save them and return them
by 5 packets of 32 bits, then only call SHA1 once every 5 calls. That
way, we get one slower exec every 5 calls but faster calls on average.

And if we can't get a good hash to be fast enough, let's make this
configurable. Most of us won't ever care about the strength of the
hash. People concerned about security won't care about the slower
hash. If we set the slower hash by default and have a tunable for
it, everyone will have the solution that fits them.

Willy

--
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/