Ring Oscillator: True Random Number Generator (TRNG) vs Physically Unclonable Function (PUF)

In the TRNG construction, the rings do not have a common enable signal, the only point in time where they are synchronized is at power up. Then they run freely, each at its own pace. This does not create a great deal of randomness per se but that does generate a lot of glitches at the flipflop inputs. The hope is create more randomness out of meta-stability. For the PUF there is a common enable so the ring oscillators are racing against each other with a common synchronizing point at the start. The challenge input selects which instances are competing. For a given challenge and a given chip, the outcome of the race tends to have always the same outcome as the precise frequency of each ring depends on the precise physical characteristics of each of their stages.

It is not related to how long the RO are running, this is just how the outputs are used which makes the difference. You can even remove the enable signal in the PUF, that will still work because what counts is the difference in the frequencies while for the TRNG this is the actual output values at the time of sampling that matters.

That TRNG may be truly random but it is tricky to get right (to get a high data rate). Other constructions relying on asynchronous rings or chaotic maps are a safer bet.


The PUF measures oscillator frequency, which depends on how the atoms were arranged during device manufacture. The RNG uses randomness of oscillator frequency and phase over short time periods.

Where the randomness comes from

Any timing device (pendulum, Quartz resonator, RC oscillator etc.) has some inherent "noise" or "jitter" as it is known to designers. If we build an oscillator whose output is a stream of pulses, the inter-pulse time is not perfectly consistent. This noise has similar properties and behaviour to the more familiar types of noise and is just as random.

enter image description here

In a ring oscillator TRNG each oscillator's phase relative to the sample clock drifts over time. Most of the drift is due to the difference between oscillator and sampling frequencies but some is caused by jitter.

Put another way, imagine a single ring oscillator with an enable input. It is turned on then sampled after some time T. Each period lasts (1/f)+jitter. After a long time, a large number of jitter values are added to the phase. The output could be either a 1 or 0 with equal probability. Unfortunately, for Gaussian jitter,N jitter values together only have an N^0.5 times wider standard deviation.

RNGs efficiently capture randomness

This scheme is inefficient, requiring many jitter samples per bit. The phase distribution must be so wide as to be nearly uniform. Sampling the output of N ring oscillators XORed together allows production of more random bits than sampling the same N ring oscillators at F/N. There's some statistical analysis that shows why but it can be understood intuitively by considering the number of opportunities the jitter values have to move the phase of an oscillator just enough to cause a bit flip. Oversampling produces lots of mostly correlated bits per oscillator. Xoring combines them to make a whitened output stream.

PUFs reduce the impact of randomness

PUFs are designed to reduce the effect of random noise sources on their results. An ideal PUF depends only on the way the atoms landed during device manufacture. The PUF design you have shown is not "predicting" the output value of the ring oscillator at some time T. It counts output pulses. The output is roughly: "Is the frequency of the first selected ring oscillator higher than that of the second selected ring oscillator?". For reasonably long run times this is not significantly effected by jitter values. The jitter effects scale with the 0.5th power while the number of counts increases linearly. Longer run times converge towards a perfect frequency comparison. For oscillators with very close frequencies, jitter can play a big part in the result. This is why some PUF challenge values may not have a definitive 1 or 0 answer on a given device.