From: "H. Peter Anvin" <hpa@zytor.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
joern@logfs.org, macro@linux-mips.org, ralf@linux-mips.org,
dave.taht@gmail.com, blogic@openwrt.org, andrewmcgr@gmail.com,
smueller@chronox.de, geert@linux-m68k.org, tg@mirbsd.de
Subject: Re: [PATCH, RFC 08/12] random: mix in architectural randomness earlier in extract_buf()
Date: Sun, 22 Sep 2013 21:11:58 -0700 [thread overview]
Message-ID: <523FBF8E.3000600@zytor.com> (raw)
In-Reply-To: <1379882338-7209-9-git-send-email-tytso@mit.edu>
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@mit.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));
> }
>
next prev parent reply other threads:[~2013-09-23 4:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-22 20:38 [PATCH, RFC 00/12] random driver changes Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 01/12] random: run random_int_secret_init() run after all late_initcalls Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 02/12] random: Statically compute poolbitshift, poolbytes, poolbits Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 03/12] random: Allow fractional bits to be tracked Theodore Ts'o
2013-09-23 4:01 ` Theodore Ts'o
2013-09-23 4:03 ` H. Peter Anvin
2013-09-22 20:38 ` [PATCH, RFC 04/12] random: Account for entropy loss due to overwrites Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 05/12] random: fix the tracepoint for get_random_bytes(_arch) Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 06/12] random: optimize spinlock use in add_device_randomness() Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 07/12] random: allow architectures to optionally define random_get_entropy() Theodore Ts'o
2013-09-23 10:38 ` Stephan Mueller
2013-09-23 11:05 ` Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 08/12] random: mix in architectural randomness earlier in extract_buf() Theodore Ts'o
2013-09-23 4:11 ` H. Peter Anvin [this message]
2013-09-23 4:33 ` Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 09/12] random: optimize the entropy_store structure Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 10/12] random: cap the rate which the /dev/urandom pool gets reseeded Theodore Ts'o
2013-09-22 21:21 ` H. Peter Anvin
2013-09-22 21:40 ` Theodore Ts'o
2013-09-22 22:45 ` H. Peter Anvin
2013-09-22 23:23 ` Theodore Ts'o
2013-09-23 0:26 ` H. Peter Anvin
2013-09-22 20:38 ` [PATCH, RFC 11/12] random: speed up the fast_mix function by a factor of four Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 12/12] random: adjust the generator polynomials in the mixing function slightly Theodore Ts'o
2013-09-25 10:51 ` Jörg-Volker Peetz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=523FBF8E.3000600@zytor.com \
--to=hpa@zytor.com \
--cc=andrewmcgr@gmail.com \
--cc=blogic@openwrt.org \
--cc=dave.taht@gmail.com \
--cc=geert@linux-m68k.org \
--cc=joern@logfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=smueller@chronox.de \
--cc=tg@mirbsd.de \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.