[Cryptech Tech] trng ready for play

[Fredrik Thulin]

On Monday, October 06, 2014 09:28:23 PM Joachim Strömbergson wrote:
> Aloha!
> 
> Fredrik Thulin wrote:
> > If the above is correct, I have to ask why you need a timeout on the
> > fetching of data from entropy providers? Why not just say that the
> > mixer requests N bits from all the providers and either they have N
> > bits in their buffers or they don't.
> 
> Yes, your description is basically correct. 

Great, thanks.

> But the reason why you need the ability to timeout is that:
> 
> (1) We are using strict round robin access from the entropy providers.
> We don't move from one provider to the next unless we have gotten data
> from the previous (or a timeout).
> 
> (2) You don't know how often and when a reseed operation will occur and
> thus when an entropy provider must provide data.
> 
> If we take the avalanche based entropy provider it can provide entropy
> at a rate of a few kbps. The rosc based entropy provider can provide
> data in hundred of kbps up to low Mbps. If we want to a few reseeds in a
> second, the avalanche based entropy provider will not be able to keep up
> even if we add a fifo that can provide a lot of data.

I think you will agree if I state the problem like this: "as soon as the mixer 
requests entropy faster than the entropy providers can provide it, the mixer 
will loose sooner or later" - right?

What I'm saying is that if it reduces complexity (I think it could), the mixer 
ought to loose at T+0 milliseconds after this event occurs, and it seems to me 
that you are saying it should loose at T+5 (or something) milliseconds after 
the event.

The added elasticity of a timeout would keep the mixer from loosing some 
times, sure, but the in-sustainable situation would still be there, just 
hidden from plain view and still happening from time to time. 

...
> > The mixer then has to handle the case where it didn't get the
> > requested number of bits back from all sources, but it won't have to
> > handle timeouts. I think this would be less complex.
> 
> What do you suggest that the mixer should do if it doesn't get the
> requested amount of data?

Don't know, that requires some thought.

I guess one way to model it is to say the mixer could be asked for entropy in 
a blocking or non-blocking way by the upper layers. If it is asked to block, 
it would just repeat until all entropy providers have returned enough bits (or 
the upper layer aborts the request perhaps) and if it was asked to do non-
blocking entropy gathering it would respond EAGAIN up the stack.

I think there might be other recovery strategies worth considering, but I 
think it would be a good idea to start with something simple.

/Fredrik