It is recommended that a new seed file be generated approximately every ten minutes by seed file manager in FORTUNA,though it depends on the application and on the rate of the accumulation of entropy.

Can I be referred to mathematics behind this calculation of 10 minutes and dependence on rate of entropy accumulation?


1 Answer 1



There can't be an exhaustive mathematical proof of the seed file refresh rate as there isn't any exact assessment of entropy generation within a generic computer thingie.

Most of the entropy on my desktop comes from typing this answer. If you leave the machine alone, entropy generation rate can be much lower than 1 bit /s. This rate was empirically measured, but internally relies on entropy being quantified in jiffies which aren't exactly SI units of anything. Even this is uncertain as there is no accurate quantitative assessment in the literature. Realistically there can't be because if a computer isn't doing anything, there's no entropy generation. And if you're playing Halo, the entropy rate is very high as you pummel the key board and IO system.

Anecdotal evidence leads me to be personally sceptical that a random Fortuna input event contains 8 bits of true entropy as suggested. A great deal of the security proofs of Fortuna revolve around this groundless assumption.

I'm almost certain that the figure is pulled out of the air which is supported by the "A reasonable solution would be to rewrite the seed file at every shutdown and every 10 minutes or so" assertion. That's as good as anything else. Similarly the 1 MB max output stipulation is probably just what looks nice and rounded as it's "not an inflexible restriction".

A simple example is to consider a machine equipped with a true random number generator. Say one of those DIY efforts that reads unconnected sound noise. A seed file would be entirely unnecessary as adequate entropy could easily be gathered from the sound card. Ergo reseed time = ∞.

A seed file that's always younger than 10 minutes gives Fortuna something to work with for seeding the pools at start up. Computers are notoriously short of entropy at start up. If you can't accurately measure the entropy generation rate, you therefore can't develop an accurate relationship to how often that entropy should be persisted for the other side of a reboot. You could change it to every hour.

  • $\begingroup$ Does not it depend on the breaking capability of best of the computers available while in collaboration? Has it something do with the hash and AES? If I hash the entropy, say 8 bits/sec, and seed it to a DRBG, now most powerful computer would need some time to break it before new seed is generated. That brings this way lower safe value of 10minutes? $\endgroup$
    – Jay
    Jun 21, 2017 at 11:25
  • $\begingroup$ If I insure I have entropy rate of 8bits/sec then how would the calculation be? $\endgroup$
    – Jay
    Jun 21, 2017 at 11:32
  • $\begingroup$ @Jay Everything changes if you have a measured and guaranteed entropy generation rate. Entropy accumulation, pool reseeding, attack recovery calculations and architecture could be entirely different (and simplified). Fortuna is explicitly based on the fact that you do not need to know how much entropy the events have. It's a necessary kludge to make it work in an indeterminate entropy environment. There are answers on this forum that indicate AES cannot be broken in under 24 hrs with contemporary hardwa... $\endgroup$
    – Paul Uszak
    Jun 21, 2017 at 11:51
  • $\begingroup$ @Jay ... hang on. Are you clear about the seed file? There's two types of seeding. The boot seed and the continuous pool reseeding. Which seed are you talking about..? $\endgroup$
    – Paul Uszak
    Jun 21, 2017 at 11:53
  • 1
    $\begingroup$ Let us continue this discussion in chat. $\endgroup$
    – Jay
    Jun 21, 2017 at 13:05

Your Answer

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