4 ms·

>For which you'd want at least two rings, with mutually-prime numbers of inverters Why? I was under the impression that all that mattered was the phase noise

>For which you'd want at least two rings, with mutually-prime numbers of inverters Why? I was under the impression that all that mattered was the phase noise in the ring oscillators (and therefore the phase drift)? Also, not sure why would you need a shift register? Just something that samples the output of the TRNG on a pin at a reasonably low freq and bitbangs what it gets on an output pin hooked up to the RX pin a serial-USB thingie should do the trick.

denton-scratch 5y ago
Well, I understand the principle to be that you use one ring oscillator to sample the state of the other; then you sample the output of the first oscillator on a clock. Phase noise just makes both oscillators more-or-less chaotic. How are you supposed to measure the phase noise? Yes, you could use a serial-USB chip, and collect one bit at a time. So you're right, there's no need for a shift register. Mutually prime: isn't it desirable that the sampling oscillator runs substantially slower than the sampled oscillator? You don't want successive samples to be from the same cycle of the sampled oscillator. I'm handwaving about mutual primality; but I'm thinking that you want to maximise the length of cycle over which the two oscillators would be expected to coincide, absent phase noise. I suppose having more inverters in each ring would increase the influence of phase noise, and increase the combined cycle length. And I still don't know how you avoid the two oscillators becoming entrained - they can influence one-another through the supply line.
- ur-whale 5y ago
  I believe you only need one ring oscillator: thermal effects pretty much guarantee that phase noise will be present, especially if the ring is short: the shorter the oscillator (very few not gates) the faster it will oscillate, especially with modern silicon. You then sample it using the crystal clock but at a slow pace (say 1kHz). You are correct that you may see some sort of self-synchronization effect between the sampler loop and the ring osc., especially given that it's pretty much impossible to know what the FPGA routing and placement tools will do. The trick here is that yes: the random numbers you're going to get out of these types of potentially intertwined systems is of very low quality from a uniformity perspective: you absolutely can't use the output directly because statistically speaking, it has very low entropy. But from a true random number generation perspective, these time series of bit do contain some entropy of the completely unpredictable kind (generated by a truly random physical process). And therefore, if you use this low-entropy stream of bit, some of which are pretty much guaranteed to be impossible to predict and feed them to - say - a stream cipher, you're going to get something that is both truly (as opposed to pseudo) random and uniform. Clearly, you don't do that last part on the FPGA/CPLD but in software, on the other side of the USB bridge.
  - denton-scratch 5y ago
    > I believe you only need one ring oscillator: thermal effects pretty much guarantee that phase noise will be present OK, that seems to be a different model, that I wasn't aware of. The model that I described can be thought of as a jittery oscillator sampling another jittery oscillator. > the shorter the oscillator (very few not gates) the faster it will oscillate, especially with modern silicon. Yabbut surely the more inverters in the loop, the more jitter per cycle? I thought that the jitter in ring oscillators was ultimately down to the unpredictability of switching speed in gates. So the more gates in the loop, the more jitter. Is this wrong? > these time series of bit do contain some entropy Yes. The output is biased. So you have to debias it (or "distill" it); for a hardware circuit, I'd have thought a hardware debiaser would be more sensible than running it through a software-driven stream cipher. Instead use the Von Neumann debiaser, which as I recall can be implemented with a couple of gates. Ah - now I remember why you need a shift register! The Von Neuman circuit doesn't output bits regularly; it compares successive pair of bits, and outputs a bit only when the inputs differ. With a heavily biased input stream, its output will be quite slow. [Edit] For added jitteriness, you can build up a chain of oscillators, each sampling the next. If you have plenty of gates, I suspect you can make a raw source with a lot of entropy to distill. [Edit Edit] The stream cipher serves as a whitener; the Von Neumann circuit doesn't do that. You still have to encrypt or hash the output to obliterate any patterns the Von Neumann circuit doesn't address - which is lots.

denton-scratch 5y ago

Well, I understand the principle to be that you use one ring oscillator to sample the state of the other; then you sample the output of the first oscillator on a clock. Phase noise just makes both oscillators more-or-less chaotic. How are you supposed to measure the phase noise? Yes, you could use a serial-USB chip, and collect one bit at a time. So you're right, there's no need for a shift register. Mutually prime: isn't it desirable that the sampling oscillator runs substantially slower than the sampled oscillator? You don't want successive samples to be from the same cycle of the sampled oscillator. I'm handwaving about mutual primality; but I'm thinking that you want to maximise the length of cycle over which the two oscillators would be expected to coincide, absent phase noise. I suppose having more inverters in each ring would increase the influence of phase noise, and increase the combined cycle length. And I still don't know how you avoid the two oscillators becoming entrained - they can influence one-another through the supply line.

ur-whale 5y ago
I believe you only need one ring oscillator: thermal effects pretty much guarantee that phase noise will be present, especially if the ring is short: the shorter the oscillator (very few not gates) the faster it will oscillate, especially with modern silicon. You then sample it using the crystal clock but at a slow pace (say 1kHz). You are correct that you may see some sort of self-synchronization effect between the sampler loop and the ring osc., especially given that it's pretty much impossible to know what the FPGA routing and placement tools will do. The trick here is that yes: the random numbers you're going to get out of these types of potentially intertwined systems is of very low quality from a uniformity perspective: you absolutely can't use the output directly because statistically speaking, it has very low entropy. But from a true random number generation perspective, these time series of bit do contain some entropy of the completely unpredictable kind (generated by a truly random physical process). And therefore, if you use this low-entropy stream of bit, some of which are pretty much guaranteed to be impossible to predict and feed them to - say - a stream cipher, you're going to get something that is both truly (as opposed to pseudo) random and uniform. Clearly, you don't do that last part on the FPGA/CPLD but in software, on the other side of the USB bridge.
- denton-scratch 5y ago
  > I believe you only need one ring oscillator: thermal effects pretty much guarantee that phase noise will be present OK, that seems to be a different model, that I wasn't aware of. The model that I described can be thought of as a jittery oscillator sampling another jittery oscillator. > the shorter the oscillator (very few not gates) the faster it will oscillate, especially with modern silicon. Yabbut surely the more inverters in the loop, the more jitter per cycle? I thought that the jitter in ring oscillators was ultimately down to the unpredictability of switching speed in gates. So the more gates in the loop, the more jitter. Is this wrong? > these time series of bit do contain some entropy Yes. The output is biased. So you have to debias it (or "distill" it); for a hardware circuit, I'd have thought a hardware debiaser would be more sensible than running it through a software-driven stream cipher. Instead use the Von Neumann debiaser, which as I recall can be implemented with a couple of gates. Ah - now I remember why you need a shift register! The Von Neuman circuit doesn't output bits regularly; it compares successive pair of bits, and outputs a bit only when the inputs differ. With a heavily biased input stream, its output will be quite slow. [Edit] For added jitteriness, you can build up a chain of oscillators, each sampling the next. If you have plenty of gates, I suspect you can make a raw source with a lot of entropy to distill. [Edit Edit] The stream cipher serves as a whitener; the Von Neumann circuit doesn't do that. You still have to encrypt or hash the output to obliterate any patterns the Von Neumann circuit doesn't address - which is lots.