Seeding the Fortuna PRNG for the first time

Question

I am trying to understand how the Fortuna PRNG should be seeded correctly for the first time.

Let's assume that we do have a large-enough seed file available, but not any entropy sources during first boot. To my understanding, I would:

• initialize the PRNG (section 9.5.4)
• load the seed file (section 9.6.2)
• produce random numbers (section 9.5.5)

The last step would produce an error: the check on the end of the pseudo-code in section 9.5.5 would assert that ReseedCnt is zero: PRNG not seeded yet.

When I track the usage of ReseedCnt, I observe the following:

• ReseedCnt is set to zero during initializiation.
• When reading the seed file, ReseedCnt is untouched.
• When generating random data, ReseedCnt is incremented when enough entropy is available in Pool[0] and enough time has passed (not the case during first boot).

So, is the paper missing some steps on what to do in this situation? Section 9.6.6 about first boot explicitly states: 'Having an outside source of randomness to create the first seed file is probably the best solution.'

Answer 1

You have to appreciate that Bruce and Niels' paper isn't source code. They wrote "We assume there are several sources of entropy in the environment" and "feel free to choose AES (Rijndael), Serpent, or Twofish for this function". It's a bit of a concept paper without a hard implementation. That's been left to others.

An example of this is on Silicon Labs micro controllers. That implementation is ultimately seeded with real entropy from reading the internal temperature sensor. Those tend to jitter somewhat, creating true randomness. Even they though add this proviso: "The user is encouraged to implement additional entropy sources." The implementation of FreeBSD palms this off to various device drivers to call the random_harvest_*() function themselves.

This entropy input step is outside of the Fortuna construct. They clearly couldn't predict where Fortuna would be running so it was correct to leave this to particular implementations. It could easily be avalanche diodes, keyboard key scanning firmware or even the internal temperature sensors that are scattered throughout desktop motherboards these days.