# Fortuna: why are source ID and data length added together with entropy data into the pools

Section 9.5.6 of Cryptography Engineering states that

The concatenation [of source number, length of data, and data itself] is then appended to the pool.

Why are we including source number and data length? The source number is fixed for each source, the length of data is constant for many sources, so aren't we contaminating the pool with low entropy data?

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 patterns. This depends on the usage of the hash function.

• I think I kind of understood your first paragraph, but your next two still leave me confused. Why do we need to differentiate the entropy data? Apr 16 '15 at 8:03
• To prevent that the same input is hashed to the same output for different sources. We would lose some information if we didn't do this, to be exact the information from which source it is. This could also maybe prevent some attacks against multiple occurrence of the same output - don't know if such an attack exists, but better don't take a risk.
– Nova
Apr 16 '15 at 8:11
• How can that ever happen? If the sources are indeed spitting out repetitive/identical data across reseeds then adding source number and data length won't save us anyways. Furthermore we should then re-evaluate our decision to use these sources for entropy. Apr 16 '15 at 8:40
• @wmjdgla: No, I mean the same data from different sources. If two sources have the same data collected (can happen), than they would result in identical output from both. With the source number, this doesn't happen.
– Nova
Apr 16 '15 at 18:04
• The data from different sources is distributed across different pools in a round-robin manner, so in order for two pools to hash to the same output, the sources would have to repeatedly output the same data so that the pools would collect the same data after multiple rounds of round robin (a clear sign that they are poor entropy sources). In that case, adding the source number is just introducing another repetitive string of data and it gives us no guarantee that it'll produce a different data string across different pools. Apr 17 '15 at 1:44

Adding the source and length actually collects more entropy. Consider the case of using system counters as entropy sources. If at some timestamp CounterX=123, and CounterY=123, we actually retain at least one bit more entropy by stirring in a source identifier ("CounterX=123CounterY=123") instead of simply "123123". The source of the value is additional entropy, it adds log2(total number of sources) bits of entropy to the pool when combined with a value. The length is similar; it adds more entropic information about the values being added to the pool (we stir in "len=4val=1231len=2val=23" versus "123123")

Ideally, we can collect a stream of values of the form: timestamp,source,length,data and periodically hash them into the pool. Use of a a good cryptographic hash in theory ensures we exctract all the entropy available from the source data (up to the hash length).

• I agree it collects more entropy, but how much is that going to be? In the crypto context, entropy is always relative to the attacker's knowledge. The harder it is for the attacker to guess/predict the data, the more entropy it has. Source number and data length are mostly fixed and the attacker can easily guess/infer their values; thus the amount of entropy gain is marginal. Won't it make more sense to just collect more data from the sources as opposed to adding these low entropy data? Apr 17 '15 at 3:24