For security personalization of a device within the production environment our customer requires the following:

The private / public key pair should be placed within the device and within the Secure process environment.

To generate the private key, parts of the entropy are to be generated by an external random number generator.

Corresponding random data should be imported into the device.

I understand what they want but have no idea, how this additional entropy could be combinded with the device internal true-random-number generator. I understand, that a number of external generated random numbers should be combinded with the internal generator to yield the random numbers on which my private keys shall be based. How is this done in practice? To take the first 16 numbers from the internal and the other 16 numbers from the external source would be by far too trivial.

  • $\begingroup$ Your last sentence above and your comment to 'itsme' is causing some confusion. Why is it far too trivial to simply combine, and are there other restrictions on the external entropy generation rate? $\endgroup$ – Paul Uszak Apr 11 '17 at 10:37
  • $\begingroup$ Is the private key generated by your "device" with an fixed API, or do you generate the key in software and import it into the device afterwards? $\endgroup$ – mat Apr 11 '17 at 11:46
  • $\begingroup$ The private key is generated by the device using a special API function. 32 random bytes must be prepared. There is a device internal true random number generator. The question is now, how to combine the TRNG with some external entropy. It is not specified, how much entropy is meant by "some parts of the entropy". $\endgroup$ – MichaelW Apr 11 '17 at 13:55

Based on the current details, this will work where I = internal generator and E is the external one:-

random bytes = I ⊕ SHA1(E)

The equation assumes that I is a good quality RNG. The key here is to get enough entropy from E. You should measure it's (min.)entropy generation rate in bit/s sample and then take enough samples to ensure you have F times 16 bytes of it. F is a safety factor which ideally should be >2 but I'd just go with F = 100. If you have an analogue entropy source you can easily get 10 kSa/s with an on chip ADC, and a digital entropy source can be sampled at something in the order of 10 MSa/s. Depends really on the features of your micro controller.

The hash allows a dissimilar amount of entropy to be easily combined. It also acts as a randomness extractor for E, so you don't have to be debias the entropy and it'll deal with huge auto correlation.

Note. I would make the argument that there's no point in having the internal generator (I). If you have the luxury of a true entropy generator, use it. The hash extractor function means that additional whitening is not necessary. As Shane tells Joey, if you can use it, one's all you need. And how would I be seeded anyway?


Simply xor the data. The xor of two random sources has at least as much entropy as the maximum of the entropies of both sources, as long as both random sources are independent.

  • $\begingroup$ This would require to have both streams synchronized: C(i) = A(i)+B(i). What about if I want to generate n random numbers and only m <n numbers are available from the external source? $\endgroup$ – MichaelW Apr 11 '17 at 10:04
  • 1
    $\begingroup$ How many random bytes do you need? It shouldn't be many! Normally we use the external and the "true" internal random just to initialize a pseudo random number generator (like from ISO 18031), which is then used to produce random (as it is available "cheaply", often we xor random from the true random number generator of the device to the output of the PRNG). $\endgroup$ – itsme Apr 11 '17 at 11:50
  • $\begingroup$ Kudos on not using the NIST stuff... $\endgroup$ – Paul Uszak Apr 11 '17 at 12:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.