linux-kernel - Re: [RFC][PATCH] Pseudo-random number generator

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: <200612041615.kB4GF7lx031249@turing-police.cc.vt.edu>
Date:	Mon, 04 Dec 2006 11:15:07 -0500
From:	Valdis.Kletnieks@...edu
To:	Jan Glauber <jan.glauber@...ibm.com>
Cc:	linux-crypto <linux-crypto@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] Pseudo-random number generator

On Fri, 01 Dec 2006 14:19:15 +0100, Jan Glauber said:
> New s390 machines have hardware support for the generation of pseudo-random
> numbers. This patch implements a simple char driver that exports this numbers
> to user-space. Other possible implementations would have been:

> +	for (i = 0; i < 16; i++) {
> +		entropy[0] = get_clock();
> +		entropy[1] = get_clock();
> +		entropy[2] = get_clock();
> +		entropy[3] = get_clock();

By the time this loop completes, we'll have done 64 get_clock() - and if an
attacker has a good estimate of what the system clock has in it, they'll be
able to guess all 64 values, since each pass through the loop will have fairly
predictable timing.  So as a result, the pseudo-random stream will be a *lot*
less random than one would hope for...

> +		/*
> +		 * It shouldn't weaken the quality of the random numbers
> +		 * passing the full 16 bytes from STCKE to the generator.
> +		 */

As long as you realize that probably 12 or 13 or even more of those 16 bytes
are likely predictable (depending exactly how fast the hardware clock ticks),
and as a result the output stream will also be predictable.

I think this needs to either find a way to stir in entropy from sources other
than the clock, or make it clear that the returned data is pseudo-random but
likely predictable by a determined attacker.  As such, it's probably a bad
choice for many things that /dev/urandom is usable for, such as session keys
and the like.

Content of type "application/pgp-signature" skipped