# What are the differences between rand() function and RNG (Random number generator) peripheral?

I'm wonder for RNG (Random number generator) peripheral in STM32F4XXXX MCUs. look in this Reference Manual (page 748). On the other hand, we have the rand() function in stdlib library that do the same task. Now I have two questions:

1. What are the differences (advantage and disadvantage) between rand() function and RNG (Random number generator) peripheral?
2. Look at this part: Please explain about these both option (especially second option).

Dave's answer quite nicely resume it, but to clarify a little bit more on the second option:

a real hardware random number generator uses a physical entropy source. Such an entropy source could be cosmic radiation, electrical noise, avanlanche effect from a reverse-biased diode (or BJT transistor), chua circuit, etc. The less deterministic the entropy source, the better the quality of the random output. An ideal entropy source would be to use a quantum physics effect, or something that cannot possibly modeled with deterministic equations.

Another important factor with random number generators is that the entropy source may generate only a limited amount of entropy per unit of time. A good example is the chua circuit: while it is quite random, it has very poor speed and cannot possibly be used for real-life application.

In many processor/microcontrollers with built-in RNGs, the clock drift from 2 to 4 clocks which are deliberatly incorrectly synchronized is used. Then, they use both analog and digital filters to randomize even more the pattern and shift-in the result in a register. Performing such filtering requires a few cycles, which explains the minimum amount of cycles required on a given clock before the newer value is available.

The clock drifting is not quite a quantum effect, so it could be modeled, but it is random enough, because it is dependent on a lot of parameters, such as temperature, silicon process, frequency of operation, electrical noise, background radiations, etc.

In applications where the hardware RNG do not have sufficient throughtput (such as in highly demanding cryptographic applications), it is quite common to use the hardware RNG as a seed for a pseudo random number generator such as the rand() function in the sdtlib. However, such application usually provide a better implementation of rand() which is specifically design to run from a seed which may be discarded very often with true random values. In newer Intel processor with integrated hardware RNGs, the pseudo-random algorithm part is directly integrated in the silicon, so it is performed by hardware, yielding very high random throughtput.

If you mind about the rand() method itself, it is only a methematical expression which is designed to generate a large enough amount of entropy. Large enough being dependant on the application: for cryptographic keys generations, the randomness is required to be of higher quality that the randomness required for a simple random shuffle in your favorite music player. It is obvious that the higher the quality of the random output, the higher the computational cost of the random number.

The operations involved in a random number are quite similar to the one involved in computing the MD5 hash of a file: they try to use a kind of bit avalanche effect so that a single bit change in a seed value changes the whole generating pattern. As a side note, I do NOT recommand using MD5 as a pseudo-random number generator; it was only an example. It would be both inefficient and not so random, but the point is there: if you feed the same file to an MD5 hasing algorithm, you will always get the same deterministic output, pretty much the same way you would always get the same output from the rand() function if you input the same seed unless your implementation depends on some arbitrary elements such as current time.

The key difference is that the rand() library function is a pseudorandom number generator — given any particular starting (seed) value, it will always produce the same sequence of numbers.

On the other hand, the RNG peripheral is a true random number generator, and it will produce nonrepeatable sequences of numbers.

• Thanks. and those both option..? – Roh Apr 8 '14 at 17:16
• What does "and those both option..?" mean? Is it a question? – John U Apr 9 '14 at 11:43

The two topics you outline can be described relatively easily:

• 1: You cannot generate random numbers faster than once every 40 clock cycles, so this results in 48MHz/40 = ~1M Sample/s
• 2: The hardware contains a monitor which will check every generated number for strange behaviour. E.g. if you used temperature as a source and had a highly stable temperature environment, it could happen that the RNG would generate the same number sequences again an again (like a pseudo-random number generator would do if you start with the same seed value). The component would monitor this and provide you with a signal if the RNG works as it is expected to. In case you need your numbers to be "really" random, you might want to monitor this flag to see if they really are. How exactely this is done and how the RNG actually works is probably given in the remaining text.

Suppose that one designs a mechanical roulette-wheel spinner which energizes a motor for a certain length of time, waits for the wheel and ball to come to rest, and observes which pocket the ball is in. Normally after each spin the ball and wheel will end up in a slightly different place, and small variations in the ball's location after one spin can make a huge difference in where it ends up on the next spin. Thus, even if the motor is always energized for the same length of time, the pocket where a ball lands on one spin will be independent of where it landed the spin before.

Now suppose, however, that a few of the numbers have or develop slight depressions in them, and the motor's bearings develop flat spots. Then some spins would be random, but after a spin which results in the ball landing in a depression and the bearing at a flat spot, the next spin might very well be biased toward having the same result as the last spin where that occurred. If most spins don't simultaneously hit the divot and flat spot, their existence probably won't affect things too much. On the other hand, if one divot/flat combo happen to be placed just right so that a ball there will reasonably consistently land on a second, and that one happens to be placed so as to send the ball back to the first, then one end up with some extremely skewed behaviors.

If, after landing on 4 and 23, the next spin is a 4, that doesn't necessarily indicate a problem. A 4 should appear about 1/38 of the time in that situation. Further, acquisition of random data should just capture the pocket number, since nothing useful is known about how often the ball should come to rest in various parts of the pocket. Nonetheless, it may be useful for whatever's recording the numbers to also "observe" where in the pocket the ball stops and watch for any unusual patterns. The distribution of locations could be skewed toward the front or back without indicating a problem, but if there's a narrow spike in the distribution that could be cause for concern.

If consecutive readings from a random generator are statistically independent, compensating for bias is not difficult (though the time required is nondeterministic). If, however, a generator falls into a state where readings are not independent (e.g. the cyclic state of the wheel above), compensation becomes basically impossible--thus the need for a hardware RNG to include circuitry to detect such behaviors.