Re: Remove PRNG from Linux Kernel

From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Frederick Gotham <cauldwell.thomas@gmail.com>
Cc: linux-crypto@vger.kernel.org
Subject: Re: Remove PRNG from Linux Kernel
Date: Sat, 9 Nov 2019 00:03:53 -0500	[thread overview]
Message-ID: <20191109050353.GD23325@mit.edu> (raw)
In-Reply-To: <XnsAB01A0BBA9FB8fgotham@195.159.176.226>

On Fri, Nov 08, 2019 at 03:48:02PM -0000, Frederick Gotham wrote:
> 
> There cannot be any software-based psuedo-random number generators on my 
> device, and so far I've removed three of them:
> 
> (1) The built-in PRNG inside OpenSSL
> (2) The Intel RDRAND engine inside OpenSSL
> (3) The simulator library that goes with the tpm2tss engine for OpenSSL 
> (tcti-mssim)

Why must there not be a "pseudo-random number generator"?  Who made
that rule?  What is the goal of not allowing such a thing?

Note that in general, most people would not refer to such things as a
"PRNG", but a Cryptographic Random Number Generator (CRNG).  And in
general, it's considered a very good thing put a CRNG in front of a
hardware random number generator for several reasons:

  (1) Hardware random number generators, including TPM-based RNG's are
      slow, and

  (2) using a hardware RNG directly means you are investing all of
      your trust in the hardware RNG --- and hardware RNG have been known to
      have their share of insecurities.

What makes you so sure that the you can trust the implementation of
the TPM's random number generator?

Far better is to mix multiple entropy sources together, so that if one
happens to be insecure, or has failed in some way, you still will have
protection from the other entropy sources.

> I need to remove the PRNG from the Linux kernel and replace it with something 
> that interfaces directly with the TPM2 chip.
> 
> Has this been done before?

As far as I know, no, because most people would consider this a
Really, REALLY, **REALLY** bad idea.  Note that the TPM2 chip has a
very slow connection to the main CPU, and there are many applications
which will need session keys at a high rate (for example, opening
multiple https connections when browsing a web page), for which the
TPM2 would be totally unsuited.

If you really want to use the TPM2 chip, there are userspace libraries
which will access it directly, and you can see how slow and painful
using the TPM chip really would be....

						- Ted