linux-kernel - Re: [PATCH resend 0/2] random: Use DRBG sources

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] [day] [month] [year] [list]

Date:	Mon, 14 Apr 2014 10:22:54 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"Theodore Ts'o" <tytso@....edu>, Greg Price <price@....edu>
Cc:	Matt Mackall <mpm@...enic.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	tpmdd-devel@...ts.sourceforge.net,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>
Subject: Re: [PATCH resend 0/2] random: Use DRBG sources

On Mon, Apr 14, 2014 at 8:49 AM, Andy Lutomirski <luto@...capital.net> wrote:
> [Resent because I forgot to email lkml.  This also surreptitiously
>  fixes a silly typo on a patch description.]
>
> This is my attempt to come up with a workable way to use so-called
> entropy sources like a TPM to feed /dev/urandom.
>
> Arguably we should be feeding the input pool as well, but if the
> /dev/random algorithm is correct, this shouldn't matter.  I don't want
> sensible use of TPMs for /dev/urandom to block on a long debate about
> /dev/random, so these patches have no effect on /dev/random.

Please consider these patches withdrawn.  I'll redo them on top of the
hwrng stuff.

Reasons:

 - add_drbg_randomness can probably be replaced with
add_device_randomness.  I'm not convinced that I like
add_device_randomness as a way to add small amounts of entropy: if an
attacker knows the initial state of the nonblocking pool, they can use
it to back out small amounts of entropy added via
add_device_randomness, which allows them to track all input_pool
entropy added by add_device_randomness.  This type of attack is
impractical for large amounts of device randomness added at once, so
this is orthogonal to the purpose of my patches.

 - The hwrng code itself is already a sensible place to do this kind
of initial seeding of the nonblocking pool, so I think that it would
be better to improve the hwrng code a bit instead.

My current thought is to split CONFIG_HW_RANDOM into
CONFIG_HW_RANDOM_DEVICES and CONFIG_HW_RANDOM.
CONFIG_HW_RANDOM_DEVICES will default to m and will expose
hwrng_register but not the /dev/hwrng code.  hwrng_register will call
add_device_randomness, but I'll add logging so that we can tell that
it's working.

I'll also rewrite the tpm hwrng driver.  There should be a hwrng
instance per TPM, and it shouldn't show up until there's actually a
TPM there.

--Andy

>
> Andy Lutomirski (2):
>   random: Add add_drbg_randomness to safely seed urandom from crypto hw
>   tpm,random: Call add_drbg_randomness after selftest
>
>  drivers/char/random.c            | 56 +++++++++++++++++++++++++++++++++++-----
>  drivers/char/tpm/tpm-interface.c | 15 ++++++++++-
>  include/linux/random.h           |  1 +
>  include/trace/events/random.h    | 19 ++++++++++++++
>  4 files changed, 83 insertions(+), 8 deletions(-)
>
> --
> 1.9.0
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/