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: <20090516154705.GA27139@1wt.eu>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ