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

Powered by blists - more mailing lists