Thanks for the nice reply. It’s good you’ve done some analysis, but more in-depth review of a cryptographic random source should be performed. Here’s one that I consider a good example review (disclaimer: I worked on some of it)

]]>Right, and this is a general problem with other public key crypto as well. For example, (EC)DSA can be compromised if you know a small fraction of the random nonce (not key!) bits.

The moral is: randomness is very important in public key crypto and you can’t just hand-wave and say a fix is “good enough.”

]]>ECQMV is vulnerable to an attack against the static private key when the top 4 bits of the ephemeral private key are known. The static key pair is exposed even though it is generated off-meter with a presumably good RNG.

]]>I’m questioning two points that you seem confident in but could warrant further review:

1. That static key pairs are “unlikely to be generated” using the Z-Stack insecure PRNG

2. That the ADCTSTL register provides enough entropy, even with a secure PRNG

I’m guessing your criteria for #1 is that key generation is probably done on a general purpose computer before production, and thus is unlikely to share an implementation with Z-Stack. Is this the case? How likely is it that they reused code from Z-Stack?

Evidence points to #2 being a problem, even with a secure PRNG. Careful modeling of the entropy obtained from ADCTSTL is needed before making claims about it. Unfortunately, the latest version of Z-Stack moved this function out of the library, so it’s not easy to review exactly how it’s used (reseeding rate).

]]>1) A random number generator

2) AES-MMO cryptographic hash

(2) is a callback as many chips have an internal AES-128 block cipher accelerator, thus the soft (and comparatively large) AES-128 block cipher also included in the library can normally be elided. Because this has a very fixed function, it is not really open to abuse.

(1) is a callback because many chips/stacks provide their own RNG. The aim here is to make the library as small as possible due to the constrained resources of the chips this is targeted at. Therefore, if reuse can be done, it should be.

Therefore, the customer cannot “create any number of implementatins with variations on use of crypto”.

Of course, if an implementer decides to use a PRNG with low entropy for the RNG (which the ZigBee Specification says should be FIPS 140-2 compliant) then it will cause potential problems as has been discovered.

]]>