[Cryptech Tech] Suggested changes to TRNG

[Russ Housley]

> (1) Currently the entropy providers start collecting entropy as soon as
> the FPGA has been configured, something that happens either a bunch of
> ms after power up of the FPGA, or when SW has forced a configuration of
> the FPGA.
> 
> This means that the entropy sources may have just started generating
> noise. This is esp true for the internal entropy source since the
> oscillators are configured at the same time as the collector. And this
> might mean that the noise and entropy might be biased by inital values.
> 
> For this reason I'm thinking of adding a warm up delay of XYZ cycles
> (suggestions in XYZ is appreciated). For the online tests to be able to
> start up we will need to wait a number of cycles anyway.

A pause seems prudent, but it is unclear to me how long it should be.


> (2) Currently the complete chain from csprng to entropy providers are
> basically in sync. What this means is that unless CSPRNG requests seed
> data from the mixer, the mixer does not do anything. Similarly, unless
> the mixer requests data, the entropy providers does not collect any
> entropy. The noise sources still runs however.
> 
> A consequence of this is that when the csprng is reseeded it has to wait
> for the mixer to generate new seeds, which means that the entropy
> providers needs to generate new entropy words, this means that the
> entropy noise rate directly affects the time it takes to do a reseed.
> The output fifo in the csprng is able to handle this delay for the RND
> rate we extract data today, but for higher rates this might mean that
> there can be delays at reseed before data is ready.
> 
> So for for performance reason, but also for adding more unpredictability
> and make it harder to influence the chain and know when that influence
> takes effect, I would like the TRNG to be allowed to do more mixing and
> be able to consume entropy even though the csprng isn't requesting seed
> data.
> 
> What I would like to add is a fifo between the mixer and the csprng.
> This would allow the mixer to prepare seeds for the csprng so seed data
> is ready when the csprng needs it. I would also like to add fifos to the
> entropy providers to allow them to provide enough entropy for the mixer
> to generate seeds when that happens.
> 
> But I would also like to add some periodic mixing to allow the mixer to
> consume entropy and update its state irrespectively of the csprng.

This makes sense to me as long as it is not consuming a lot of power.


> (3) One thing we have discussed is to add a third entropy provider - a
> pseudo random provider. It would would serve one, possibly two purposes:
> 
> 1. As a feedback path from the csprng to the mixer. The first X words
> extracted after a reseed are never provided to application, but instead
> fed back into a fifo (what the entropy provider is). This means that we
> now have a feedback path and internal state that should make it much
> harder for an attacker to control the state generating the seeds.
> 
> 2. As a way of applications to add entropy. The fifo in the third
> entropy provider can be made available for writing data.

Is there overlap with (2)?  Is the feedback running all of the time or just the first X words?


> (4) Right now the chain is reseeded once after cold start. With the
> third entropy provider I'm considering changing this to a double reseed.
> This means that we seed the csprng once, generate enough random values
> to fill the entropy provider and then reseed again to allow the new
> 'entropy' be part of the state of the mixer. And when adding the test
> mode, we make this double reseed how we ensure that the TRNG is placed
> in a good state for operations again.

I like the idea that enough fresh entropy is used for the seed.  Doesn't the feedback in (3) already make sure that happens?

Russ