<div dir="ltr"><div><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 8, 2014 at 7:52 PM, Cox, Landon <span dir="ltr"><<a href="mailto:Landon.Cox@atmel.com" target="_blank">Landon.Cox@atmel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div link="blue" vlink="purple" lang="EN-US">
<div>The correct way to use the ATSHA204 or ATSHA204A random number generator is:
<p><u></u><span>1)<span style="font:7pt "Times New Roman"">     
</span></span><u></u>Wake<u></u><u></u></p>
<p><u></u><span>2)<span style="font:7pt "Times New Roman"">     
</span></span><u></u>Random or Nonce Mode 0 (with seed update)<u></u><u></u></p>
<p><u></u><span>3)<span style="font:7pt "Times New Roman"">     
</span></span><u></u>Additional Random/Nonce Mode 0 commands<u></u><u></u></p>
<p><u></u><span>4)<span style="font:7pt "Times New Roman"">     
</span></span><u></u>Idle or sleep<u></u><u></u></p>
</div></div></blockquote></div><br></div>A more secure way to use this part is:<br><div class="gmail_extra"><br></div>1) Call the "random" function 512 times, with EEPROM updates turned OFF<br><div class="gmail_extra"><br></div><div class="gmail_extra">2) Combine the LSBs of the results to create a single 512 bit value<br><br></div><div class="gmail_extra">3) Call SHA256 on the 512 bit value, resulting in a whitened true random 256-bit value<br></div><br>This procedure is more secure than relying on the EEPROM seed as a "random" source.  Not only does this get around some simple back-doors that may be in the device, but this procedure eliminate the limit on how many random values can be generated.  Normally the device refuses to generate "random" data after about 1,000,000 calls.<br></div><br></div><div>While there is some evidence, there is still no convincing proof that there is an entropy source in this device at all.  There is some evidence that Atmel has inserted a back-door.  My advice is to avoid this line of parts from Atmel for cryptographic use.<br><br>I think any Linux system that already has this part should go ahead and add the "random" values it generates using the procedure above to the /dev/random pool.  Repeating this procedure every few minutes could help the entropy pool recover if it's state is compromised for any reason.  However, do not update the entropy estimate in the pool, because we cannot be sure we've added any actual entropy!  This is how we use random values from the Intel RDRAND instruction, or any other source of randomness that is suspect.<br></div><div><br></div><div>The great thing about FOSS software is we are free to improve it.  Landon, who uses an Atmel email address, wants you to use the EEPROM seed, which could hide a back-door.  If people want a more secure version that does not rely on the EEPROM seed, I would be happy to fork the Hashlet code and make this fix.<br></div><div><br></div><div>Bill<br></div></div>