<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Nov 9, 2014 at 9:19 AM, Andreas Briese <span dir="ltr"><<a href="mailto:ab@bri-c.de" target="_blank">ab@bri-c.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hey Bill, <div><br></div><div>Great work. you forgot to mention the Atmel warranty: </div>
<div title="Page 1">
<div>
<div>
<div>
<ul style="list-style-type:none">
<li><p><span style="font-size:10.000000pt;font-family:'ArialMT'">Guaranteed Unique 72-bit Serial Number </span></p>
</li>
</ul>
</div>
</div>
</div>
</div><div>wich makes it really unique on the planet :-).</div><div><br></div><div>No kidding: </div><div>Atmel states ( <a href="http://www.atmel.com/Images/Atmel-8885-CryptoAuth-ATSHA204A-Datasheet.pdf" target="_blank">http://www.atmel.com/Images/Atmel-8885-CryptoAuth-ATSHA204A-Datasheet.pdf</a> P.7): </div></div></blockquote><div><br></div><div>I believe them, and a unique serial number is a good thing. In fact, it might be the "seed" they talk about. There is no way to insure that these serial numbers are not recorded by Atmel.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
<div title="Page 7">
<div>
<div>
<div><p><span style="font-size:10.000000pt;font-family:'ArialMT'">>> P.7 </span></p><p><span style="font-size:10.000000pt;font-family:'ArialMT'">The ATSHA204A can generate high-quality random numbers and employ them for any purpose, including as
part of the crypto protocols of this device. Because each 32 </span><span style="font-family:ArialMT;font-size:10pt">byte (256-bit) random number is not dependent on
past numbers generated on this or any other device, their inclusion in the protocol calculation ensures that
replay </span><span style="font-size:10pt;font-family:ArialMT">attacks (i.e. re-transmitting a previously successful transaction) always fail. See </span><span style="font-size:10pt;font-family:ArialMT;color:rgb(0,143,255)">Section 3.2, “Random
Number Generator (RNG)” </span><span style="font-size:10pt;font-family:ArialMT">and </span><span style="font-size:10pt;font-family:ArialMT;color:rgb(0,143,255)">Section 8.5.14, “</span><span style="font-size:10pt;font-family:CourierNewPSMT;color:rgb(0,143,255)">Random </span><span style="font-size:10pt;font-family:ArialMT;color:rgb(0,143,255)">Command”</span><span style="font-size:10pt;font-family:ArialMT">. </span></p></div></div></div></div></div></div></blockquote><div>That's how it should work, but why does their TRNG need the seed? Doesn't that violate this statement that each random number does not depend on past numbers?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div title="Page 7"><div><div><div><p><span style="font-size:10pt;font-family:ArialMT"><<</span></p><div>>> P. 18</div><div>
<div title="Page 18">
<div>
<div>
<div>
<ol start="0" style="list-style-type:none">
<li><p><span style="font-size:10.000000pt;font-family:'ArialMT'">Random numbers are generated from a combination of the output of a hardware RNG and an internal seed
value, which is not externally accessible. The internal seed is stored in the EEPROM, and is normally updated
once after every power-up or sleep/wake cycle. After the update, this seed value is retained in SRAM registers
within the device that are invalidated if the device enters sleep mode or the power is removed. </span></p>
</li>
</ol>
</div>
</div>
</div>
</div></div><div><<</div><div><br></div><div>As far as i understand this, Atmel is actually saying, they do, what you found out, but they call the „seed“ == „nonce" in their papers.</div><div><br></div><div>The „seed“ shall be renewed at sleep/power-up. Did you check this?</div></div></div></div></div></div></div></blockquote><div><br></div><div>No, I've just read the docs and some discussion.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div title="Page 7"><div><div><div><div> <br></div><div>By the way, obviously you know about cryptanalysis on RNGs. </div></div></div></div></div></div><div>Would you give me feedback about this proposal of an RNG: <a href="https://github.com/AndreasBriese/breeze" target="_blank">https://github.com/AndreasBriese/breeze</a></div><div><br></div><div>Andreas</div><div><br></div></div></blockquote><div><br></div><div>No, I'm not qualified to have a useful opinion about your breeze PRNG. I read your README.md, and it sounds cool. My un-useful opinion is that it looks like it would be hard for me to determine the state of several of your state variables just from the low bytes, at least if they are mixed together somewhat before outputting them. I haven't read the code.<br></div><br></div>Bill<br></div></div>