Fortuna: With a Single Entropy Source

Question

I have worked on a random number generator that has turned out to give results pretty close to those of Fortuna with a single source.

I was wondering how it affects the performance and claims of Fortuna as a RNG in this special case of using a single source.

How will the recovery rate be affected?

I think a solution which does not compromise with a multi-pool system can be: Use a single source to distribute secrets to a different pool. (i.e. my events processed though from one observation go to different pools as per the original design of Fortuna.)

This will be slower, but it will still be a good randomness generator without any compromise. Is this true?

Answer 1

The recovery rate is unaffected by feeding Fortuna with a single source.

This is Fortuna:

The 32 entropy pools live inside the accumulator. The accumulator collects entropy via the following function:-

function AddRandomEvent
input: R prng state, modified by this function.
s Source number in range 0, ... , 255.
i Pool number in range 0, ... , 31. Each source must distribute its
  events over all the pools in a round-robin fashion.
e Event data. String of bytes; length in range 1, ... , 32.

Ferguson et al. suggest feeding the pools in a round robin fashion. I disagree as they never catered for a steady entropy rate. They have developed /invented this equation to bound the recovery time:-

with t = time, i = 13 and t being time. At 8 bits /s, this leads to t being 1/8th second. I can't get my head around it and believe it to be technobabble to paper over the fact that they have no input entropy estimator. They explicitly state that input entropy measurement is irrelevant to the security of the PRNG. From the architectural diagram above, your entropy enters the accumulator at a rate of 8 bits /s. Fortuna's creators have decided that 128 bits of security is sufficient. It follows then that even with a fully compromised generator state, total recovery to design level security should occur in 8 seconds. And the generator is always seeded with at least pool 0, so I suggest feeding entropy directly into that pool only.

There is a get out of jail card for the authors in their statement limiting the feasible attack vectors. They disallow the attacker controlling the destination pool for his attack entropy. Hence the round robin method of securing the reseeding.

For the life of me, I cannot fathom the wisdom of multiple entropy pools. If all pools are eventually used for reseeding, why can't you have a single pool as the default Linux generator has? That works. I think that some of the analysis problems might be to do with the huge complexity of design. There are so many variables that it's difficult to perform a rigorous mathematical analysis. The main confounding factor is the automatic reseed rate affected by rapid output. I suspect that only a Monte Carlo simulation can resolve this accurately. Remember that these guys invented Yarrow and that didn't work well enough to stay with. And I don't like it as it's too complicated and unpredictable(!).