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: <523FBF8E.3000600@zytor.com>
Date:	Sun, 22 Sep 2013 21:11:58 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Theodore Ts'o" <tytso@....edu>
CC:	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	joern@...fs.org, macro@...ux-mips.org, ralf@...ux-mips.org,
	dave.taht@...il.com, blogic@...nwrt.org, andrewmcgr@...il.com,
	smueller@...onox.de, geert@...ux-m68k.org, tg@...bsd.de
Subject: Re: [PATCH, RFC 08/12] random: mix in architectural randomness earlier
 in extract_buf()

On 09/22/2013 01:38 PM, Theodore Ts'o wrote:
> Previously if CPU chip had a built-in random number generator (i.e.,
> RDRAND on newer x86 chips), we mixed it in at the very end of
> extract_buf() using an XOR operation.
> 
> We now mix it in right after the calculate a hash across the entire
> pool.  This has the advantage that any contribution of entropy from
> the CPU's HWRNG will get mixed back into the pool.  In addition, it
> means that if the HWRNG has any defects (either accidentally or
> maliciously introduced), this will be mitigated via the non-linear
> transform of the SHA-1 hash function before we hand out generated
> output.
> 
> Signed-off-by: "Theodore Ts'o" <tytso@....edu>


This doesn't mix in across the entire width of the hash (my original
motivation for putting this at the end was to do it after the hash is
folded in half -- which is still believe is cryptographically dubious,
but please don't take my word for it, as I'm not a professional
cryptographer.)  As such, this change should *probably* have
EXTRACT_SIZE changed to 2*EXTRACT_SIZE (or simply "20") both in the for
loop and in the declaration of the union.

	-hpa

>  drivers/char/random.c | 22 +++++++++++-----------
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index ba23d5c..6d5e8e6 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -993,6 +993,17 @@ static void extract_buf(struct entropy_store *r, __u8 *out)
>  		sha_transform(hash.w, (__u8 *)(r->pool + i), workspace);
>  
>  	/*
> +	 * If we have a architectural hardware random number
> +	 * generator, mix that in, too.
> +	 */
> +	for (i = 0; i < LONGS(EXTRACT_SIZE); i++) {
> +		unsigned long v;
> +		if (!arch_get_random_long(&v))
> +			break;
> +		hash.l[i] ^= v;
> +	}
> +
> +	/*
>  	 * We mix the hash back into the pool to prevent backtracking
>  	 * attacks (where the attacker knows the state of the pool
>  	 * plus the current outputs, and attempts to find previous
> @@ -1021,17 +1032,6 @@ static void extract_buf(struct entropy_store *r, __u8 *out)
>  	hash.w[1] ^= hash.w[4];
>  	hash.w[2] ^= rol32(hash.w[2], 16);
>  
> -	/*
> -	 * If we have a architectural hardware random number
> -	 * generator, mix that in, too.
> -	 */
> -	for (i = 0; i < LONGS(EXTRACT_SIZE); i++) {
> -		unsigned long v;
> -		if (!arch_get_random_long(&v))
> -			break;
> -		hash.l[i] ^= v;
> -	}
> -
>  	memcpy(out, &hash, EXTRACT_SIZE);
>  	memset(&hash, 0, sizeof(hash));
>  }
> 

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