# Tag Info

## Hot answers tagged fortuna

17

A simple way to imagine the effect of the hash function is a truncation. A "good" hash function ought to behave like a random oracle. If your source has entropy $s$ bits, then this means that the source somehow assumes $2^s$ possible values. When processed with a random oracle with an $n$-bit output, you force the $2^s$ input values into $2^n$ possible ...

7

Is the purpose of using the Fortuna PRNG more about security and preventing a 'seed leakage' than it is about the 'quality' of its generated random values? No. It's not about the 'quality' of generated random values. It's about DieHarder being very paranoic about things that are indeed good quality. Just because your RNG gave you zero three times in a row, ...

7

TL;DR: Fortuna is a CSPRNG so you can replace components pretty arbitrarily, because you're not bound by compatibility requirements and the modifications should work, although there are some points that are note-worthy. In Fortuna (PDF), AES-256 is used in exactly one place: To generate the keystream based on the current counter (the function is even called ...

4

Perhaps obvious, but couldn't you download other implementations, design a test set of your own, and run it through multiple implementations to verify the same results? There are these implementations: http://sourceforge.net/projects/fortunaprng/ https://github.com/dlitz/pycrypto/tree/master/lib/Crypto/Random/Fortuna If system entropy is an issue, you ...

3

It should not be possible to attack this scheme itself. The XOR function will work like a one time pad, where the output of each PRNG can be either the plaintext stream or the key stream. So the output of the function should be random as long as one of the two streams can be thought to be a secure and well seeded PRNG. In real life scenarios the main cause ...

3

Testing properly implemented Fortuna is little different than testing any alleged cryptographically secure random number generator. The fundamental problem is a philosophical one, as well as a practical one. For simulation it may be sufficient to choose digits from pi, which is universally believed to be randomly distributed. But, as a cryptographic key or ...

3

Ferguson and Schneier define SHAd-256 in their book Practical Cryptography in Chapter 6.3.1 Length Extensions. For any hash function SHA-X, where X is 1, 256, 384 or 512 we define SHAd-X as the function that maps m to SHA-X(SHA-X(m)). In particular, SHAd-256 is just the function m ↦ SHA-256(SHA-256(m)). They clearly defined SHAd-256 to prevent length ...

3

If nothing else, it makes the output of the pool irrecoverable. One of Fortuna's goals is to make prior Fortuna outputs safe from a compromise (the discovery of all of Fortuna's current data by an adversary). If the pool continued on without a reset, with little or no entropy added before the compromise took place, the adversary could more easily calculate ...

2

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

2

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

2

As noted by izaera, that reset of the pool is explicitly specified in Fortuna, and not an implementation artifact. The pools in Fortuna are SHA-256 hashes. By definition, in order to obtain a pool's result, the SHA-256 hash must be obtained (in the present code, that's the job of sha256_done). With a standard SHA-256 implementation, there is no way to ...

2

Robert Brown of Duke University has an excellent test suite called "Dieharder". Supposedly this is the most stringent battery of PRG tests available. I have never used it but it will be worth your while to check it out.

2

I see essentially three ways to design this API: Take a pool Take a counter and have the accumulator calculate the pool as pool = counter mod poolCount Take a sourceId Of these 2) seems clearly superior to 1) since the caller doesn't need to care how many pools there are, or how to distribute among the pools. Comparing 1), 2) with 3) is more difficult, ...

2

No, in your situation (where you don't care about security), there isn't any harm in seeding the generator from its own output (or, for that matter, reseeding it by just incrementing the original seed, and resubmitting it). The chief issue would be if you would fall into a loop (that is, you start repeating outputs); if the seed you generate is 128 bits or ...

1

Use SHA-256. Truncating the hash does reduce its collision resistance, but you can't "lose entropy" if you're only keeping 128 bits in each pool anyway.

1

You can't contaminate the pool with low entropy data. Hash functions "extract" up to the output size or the hash - slightly less, because of collisions. The source number makes the output different for different sorces even if the input is the same. The length is needed because else we could not differate two small inputs from one large input with special ...

Only top voted, non community-wiki answers of a minimum length are eligible