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.'

  • $\begingroup$ Looking at fortuna.c (as used in FreeBSD) might help if the pseudo-code confuses you a bit. $\endgroup$
    – e-sushi
    Commented Mar 12, 2018 at 13:50
  • $\begingroup$ I did, but this check I am talking about is not implemented in the FreeBSD version of Fortuna. But I don't know why, or why I can deviated from that. $\endgroup$
    – BasilFX
    Commented Mar 12, 2018 at 13:55
  • $\begingroup$ Sounds maybe strange, but we live in a world where the authors of most of the crypto primitives are still alive. You could simply contact Bruce and ask him :) He may not respond to every request of course, but this seems one that might be answered. $\endgroup$
    – Maarten Bodewes
    Commented Mar 12, 2018 at 14:14

1 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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.