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

Date:	Mon, 14 Apr 2014 09:36:56 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Torsten Duwe <duwe@....de>
Cc:	"Theodore Ts'o" <tytso@....edu>, Greg Price <price@....edu>,
	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>
Subject: Re: [PATCH resend 0/2] random: Use DRBG sources

On Mon, Apr 14, 2014 at 9:13 AM, Torsten Duwe <duwe@....de> wrote:
> On Mon, Apr 14, 2014 at 08:49:58AM -0700, Andy Lutomirski 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.
>
> Ahem, The TPM RNGs are true HWRNGs, but they are very limited.
> Their main purpose is to generate enough bits so that the TPM
> can generate a genuine key pair after a few seconds.
>
> Why do you want to put those valuable true random bits into urandom?

I don't consider 256 bits, once per TPM initialization, to be valuable
in the sense that we should try to conserve them.  I consider them
valuable in the sense that we should put them where that matter most,
ASAP.  That place is IMO urandom, since readers of /dev/random will
happily block until /dev/random is adequately seeded.

If urandom is working correctly, seeding it with 256 cryptographically
secure bits, once, is enough.  Seeding it more is nice, but doing that
is IMO much lower priority.

Because urandom can be weak shortly after bootup, the TPM is there,
and putting these bits into urandom will either make urandom quite
secure, if the TPM is trustworthy, or will at least be harmless, if
the TPM is untrustworthy.

As an added benefit, this code is very simple and can easily coexist
with your code.

>
>> Arguably we should be feeding the input pool as well, but if the
>
> Yes.
>
>> /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.
>
> That confuses me a bit.

Currently there is no quick algorithm to seed urandom from sources
like a TPM.  IMO we should have one.  There are also people who are
nervous about devices like the TPM, and they may object to crediting
any entropy from the TPM.  The amount of entropy credited affects
urandom reseeding, and setting it to zero and/or turning the whole
hwrng/khwrngd thing off should not prevent urandom from getting the
benefit of a TPM.

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