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]

Date:	Sat, 16 May 2009 17:47:05 +0200
From:	Willy Tarreau <w@....eu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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, May 16, 2009 at 08:23:11AM -0700, Linus Torvalds wrote:
> 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.

if we use incremental values (such as modulus after a multiply), yes. But
SHA1 is not know yet to be easily reversible. I mean, it's not because you
can read the 160 bits of a hash which corresponds to a stupid counter that
you can guess the next 160 bits you will get. Of course the "stupid counter"
I'm speaking about must include some randomness itself so that it does not
end up with a small set of finite elements. But I'm not worried at all about
giving out all of the 160 bits of an SHA1 result.

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/