<div dir="ltr"><div><div>I just did another simple test.  After cold-booting my Raspberry Pi, I called "./haslet random" and recorded the 32-byte result.  I had the update-seed parameter turned off.  I did this 4 times.  Then I generated about 800 values in a loop, which resulted in only 161 unique 32-byte values.  All 4 cold boot values were in the list of 161 unique values.<br></div><br></div><div>I then generated 5326 64-byte values, of which 1171 were unique.  Looking at just the first 32 bytes, there were 171 unique values.  Looking at just the second 32-byte values, there were 1171 unique values.<br><br></div><div>I then generated 5348 96 byte values, of which 3217 were unique.  The first group had the same 171 unique values, and the second had 1179.  The 3rd group of 32 had 3217 unique values.<br></div><div><br></div><div>My best guess as to what's going on here is that the device has a ring-oscillator based entropy source, but that it generates only a few bits of entropy for each use.  It seems to be called before generating each 32-byte "random" value, which is why the second set of 32-bit values have more possible values, and the 3rd has even more.  However, the number of unique values in the final column of 32*N byte values is always equal to the number of unique values of the entire string of bytes.<br><br></div><div>In the most common use case, where a Linkys router or some other embedded device calls the random function only a few times ever, then Atmel will be able to easily guess the values generated, since they are the ones who created the initial seeds.  For devices that always publish a public key somewhere after using this random function to generate the secret, Atmel would always be able to determine the private key.  The only way I see to generate a secure key would be to disable the EEPROM and combine enough entropy from the random function results, then whiten it, as I described in my prior post.<br><br></div><div>Since this device does not seem to get any signals such as a clock from the Raspberry Pi, yet it returns different values after a cold boot on the first call to random, I think there is strong evidence that some sort of entropy generator does exist on the part.  However, with that EEPROM, it could still just be a PRNG.  There is no way to be sure, and Atmel does not seem very forthcoming about what they actually put inside the part.<br></div><div><br></div><div>This remains the scariest TRNG I have reviewed!<br></div><div><br></div>Bill<br></div>