[Cryptography] A TRNG review per day (week?): ATSH204A

[Bill Cox]

On Sun, Nov 9, 2014 at 9:19 AM, Andreas Briese <ab at bri-c.de> wrote:

> Hey Bill,
>
> Great work. you forgot to mention the Atmel warranty:
>
>    -
>
>    Guaranteed Unique 72-bit Serial Number
>
>   wich makes it really unique on the planet :-).
>
> No kidding:
> Atmel states (
> http://www.atmel.com/Images/Atmel-8885-CryptoAuth-ATSHA204A-Datasheet.pdf
> P.7):
>

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.


>   >> P.7
>
> 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 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 attacks (i.e. re-transmitting a
> previously successful transaction) always fail. See Section 3.2, “Random
> Number Generator (RNG)” and Section 8.5.14, “Random Command”.
>
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?


> <<
> >> P. 18
>
>    1.
>
>    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.
>
>   <<
>
> 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.
>
> The „seed“ shall be renewed at sleep/power-up. Did you check this?
>

No, I've just read the docs and some discussion.


>
> By the way, obviously you know about cryptanalysis on RNGs.
> Would you give me feedback about this proposal of an RNG:
> https://github.com/AndreasBriese/breeze
>
> Andreas
>
>
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.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141109/d845797a/attachment.html>