Hardware RNG, improving the design and noise characteristics

Discussion in 'The Projects Forum' started by fermevc, Mar 17, 2016.

  1. fermevc

    Thread Starter New Member

    Jul 20, 2015
    10
    0
    I've made a USB TRNG device acording to information found at XR232USB and everything is working as stated by the author.
    Only difference between my device and original is the speed of delivery of random data, and I'm guessing it has to do with the fact that I've rearanged the physical placement of el. components on pcb. I've spent a couple of months reeducating myself on basic electronics concepts, searched this and other forums in order to understand the concept of noise generation proposed by author and finaly decided to ask for help and guidance.
    Since I'm using the same MCU and I haven't changed anything in MCU code provided by author , I would like to focus on noise generation part of the circuit. I've tried to run a simulation in LTSpice with no success (bad LM393 model, or just my lack of knowledge).
    My main goal is to speed up the random data delivery (currently it's arround 72kbps, I've simply measured the time needed for storing 1MB of received random data into file, it takes 113 seconds and I've done it 100 of times). The device is visible as COM port and the port settings are "230400, 8, n, 1".
    I dont have an oscilloscope at the moment, but I think that output from "oscilator" part of comparator was arround 150kHz - what limits the bandwidth?
    I would realy apreciate any advice, thought or suggestion regarding the whole concept or just a part of circuit.
    I think that this kind of device is ideal for testing a couple of cryptoanalisys concepts I have in mind (asuming that the device can produce only good keys) and to test generated data with a kind of novel randomness test (my coleague just mentioned something about this, I don;t have a clue what's on his mind).
    Thanks in advance!
    Igor
     
  2. dannyf

    Well-Known Member

    Sep 13, 2015
    1,825
    364
    What exactly are those differences? If you don't tell people what's wrong, how do you expect others to help you?

    The design you linked to seems to follow the RC oscillator route I mentioned a while ago: it relies on the phase noise of an RC oscillator.

    On first glance, three issues:
    1. Very high baud rate on the internal RC oscillator. Requires the received to be more error tolerant.

    2. The lm393 RC oscillator can be eliminated.

    3. The schematic can have a potential error. I say potential in that given the right combination, it can work, but it is not robust.

    If you are looking to a random number generator with a build in virtual com, look for the launchpad series from TI. I used a lm4f120 launchpad plus no other parts, and it generates random numbers via the com port directly.

    Those boards can be had for a few dollars so why bother with building your own?
     
  3. dannyf

    Well-Known Member

    Sep 13, 2015
    1,825
    364
    To speed up the generation of random numbers, you can speed up the frequency of the RC oscillator, speed up the code execution, and change the code flow: interrupt driven uart for example vs polling.
     
  4. AnalogKid

    Distinguished Member

    Aug 1, 2013
    4,544
    1,251
    RS-232 is a handshake protocol. This means that the device can supply data only as fast as the computer can receive and process it. It is possible that there is something in the Windows or Linux configuration of the USB port, or the operation of the program that is capturing and storing the USB data, that is limiting the overall system speed.

    ak
     
    fermevc likes this.
  5. fermevc

    Thread Starter New Member

    Jul 20, 2015
    10
    0
    Thanks for fast response!
    I've stated the diferences, first - physical layout of components, second - speed.
    Nothing's wrong here, I've said that device is working as it should.
    I was trying to give as much info about the device and ask questions all in one post, so it may be confusing.
    For me, this topic is of interest for educational purposes (did a research on HW RNGs) and to test some hypothesys I've built this device because it didn't use PN junction principle and I had all the components. Producing this device was faster for me than to wait some ordered boards to arrive.
    As I get more involved into the cryptography, I wanted to improve the overal characteristics of the device with the help of people that have more knowledge in electronics.
    I'll take a look in suggested TI board, and other info dannyf gave, thanks!
     
  6. fermevc

    Thread Starter New Member

    Jul 20, 2015
    10
    0
    I see your point AnalogKid, but I've tried various baud rates (lower and higher than 230400, if baudrate is below 56kbps the speed of delivery drops below 72kbps as it should), so I think this is not the cause.
    I would be happy with 200+ kbps as stated by the author.
    The SW app "polls" one byte at a time using FOR loop (you send a command to the device by stating how many Bytes you want and hit enter), and I think that even on slow PCs, this basic FOR loop is fast but this should be further investigated and of course finaly there is a MCU code.
    About MCU code (firmware), the autor said that "...The bitsampling routine of a current firmware can check momentary state of the noise signal more than 1 million times per second..." (it's not classic sampling within the internal ADC, he uses LSB of fast counter when the change in input signal ocurs...), so I'm aware that I can't have 1Mbs because input signal change is 150KHz and there are start and stop bits, and other commands in firmware (I'm sorry if this sounds stupid or wrong, please correct me).
     
  7. dannyf

    Well-Known Member

    Sep 13, 2015
    1,825
    364
    He is measuring phase noise, as I suggested earlier. The fastest would be to use the capture functionality of the timer. The maximum but rate would depend on the oscillator frequency - each cycle is one bit.

    Using the ADCs lsb also works and tends to run at much higher speed, without any external part.
     
    fermevc likes this.
  8. fermevc

    Thread Starter New Member

    Jul 20, 2015
    10
    0
    After reading a couple of articles on phase noise, I'm beginning to understand the concept.
    I can't argue about the idea for input capture, ADC and interrupts but the author clearly states that he didn't want to use interrupts (except for reset) and he also said "...Even if we only took the LSB from ADC probes of an externally injected analog noise, these bits would surely correlate with some internal processes in the AVR core, making this method unacceptable for independent random number generation. (ATMEL recommends to mitigate this effect with a feature called "noise reduction" - but that does not mean anything else than completely stopping the controller's program execution for the duration of every single AD-cycle, thus cracking down all computational performance of the AVR most of the time, which is no option for this application as well..."
    Another thing I can't understand is "...My circuit utilizes a strange effect that is normally unwanted in a regular comparator setup. Because of its small hysteresis and very high amplification factors, if one applies feedback to the negative comparator input, such comparator will tend to instability and chaotic oscillation. Yet, with few external components, it IS possible controlling this effect and enforce stable noise generation with frequencies range up to the cutoff frequency of the comparator..."
    I can't find what is the cutoff frequency for LM393.
     
  9. ronv

    AAC Fanatic!

    Nov 12, 2008
    3,292
    1,255
    The LM393 can toggle at about 500Khz with the small signal input.
    It sounds like you may suffer from one of the problems described in Handling the Interface.
    Is it in a metal box? Did you use all the decoupling shown in the schematic?
     
  10. fermevc

    Thread Starter New Member

    Jul 20, 2015
    10
    0
    Only component that is missing regarding original schematic is ferite bead (Ch1) near the usb connector (couldn't find smd part localy, so I've put "smd jumper 000". The device is curently without a metal shield because I wanted to test out the "protection feature" described in "Handling the interface". I can confirm that device is working as described. The testing of EMI was done by simply presenting my smart phone close to device. If phone is idle and WiFi is off, the device is delivering data, if the phone activates WiFi or there is a incomin/outgoing call, the "protection routine" fires up, communication is blocked and device is restarted. Metal shieling of whole device or just the oscillator part was something I'm planning to do later and I would consider additional filtering.
    How will you describe the input signal in my case - small or large?
     
  11. dannyf

    Well-Known Member

    Sep 13, 2015
    1,825
    364
    Here is a rough sketch of how this can be done on a generic mcu - I think your avr follows the same principle:

    Code (C):
    1.  
    2.         sRNG_SEN=RNG_PORT;                    //read rng_sens pin
    3.         if (IO_GET(sRNG_SEN, RNG_SEN)) IO_CLR(RNG_PORT, RNG_CLK);            //flip rng_clk
    4.         else IO_SET(RNG_PORT, RNG_CLK);
    5.         do {
    6.             RNG_cnt++;                        //increment RNG_cnt
    7.         } while (((sRNG_SEN ^ RNG_PORT) & RNG_SEN) == 0); //wait for RNG_SEN to change state
    8.         if (RNG_cnt & 0x01) IO_SET(RNG_PORT, RNG_OUT); else IO_CLR(RNG_PORT, RNG_OUT);    //set / reset rng_out based on lsb of rng_cnt
    9.  
    Essentially, two pins: RNG_CLK drives a r/c network, and RNG_SEN senses the voltage on the capacitor. RNG_CLK is set out-of-phase with RNG_SEN so this is a software relaxation oscillator.

    RNG_cnt is our counter: it counts the number of cycles it takes until RNG_SEN is flipped. and the counter's lsb determines the output state of RNG_OUT - our random bit pin.

    I put it on a 12f675 and it runs at about 9kbps (10K/4.7uf).
     
    Last edited: Mar 18, 2016
  12. dannyf

    Well-Known Member

    Sep 13, 2015
    1,825
    364
    The downside of that approach is that the resolution of the counter is limited -> the whole loop takes about 6 instructions to run so on a 12F675 (4Mhz oscillator) the minimum resolution is 6us.

    A better approach is to use a timer (TMR0 for example):

    Code (C):
    1.  
    2. #define RNG_cnt            TMR0                //tmr0 as our counter
    3.  
    4.         sRNG_SEN=RNG_PORT;                    //read rng_sens pin
    5.         if (IO_GET(sRNG_SEN, RNG_SEN)) IO_CLR(RNG_PORT, RNG_CLK);            //flip rng_clk
    6.         else IO_SET(RNG_PORT, RNG_CLK);
    7.         do {
    8.             //RNG_cnt++;                        //increment RNG_cnt
    9.         } while (((sRNG_SEN ^ RNG_PORT) & RNG_SEN) == 0); //wait for RNG_SEN to change state
    10.         if (RNG_cnt & 0x01) IO_SET(RNG_PORT, RNG_OUT); else IO_CLR(RNG_PORT, RNG_OUT);    //set / reset rng_out based on lsb of rng_cnt
    11.  
    minimum change from the prior version: we just needed to redefine RNG_cnt to TMR0 -> tmr0's counter.

    I didn't do any testing but by slowing down the blinking rate (through insertion of delays at end of the cycle), the blinking seems to be fairly random to me, :)

    Simplicity is the beauty of this approach: it takes just a mcu + 1 resistor + 1 capacitor. Either approach can be done on pretty much any mcu.

    Moderators note: please use code tags for the used language
     
    Last edited: Mar 18, 2016
  13. dannyf

    Well-Known Member

    Sep 13, 2015
    1,825
    364
    That's simply not true - the adc relies on the basic nature of any man-made devices -> it is not perfect. the last couple digits of any adc will always fluctuates unpredictably. I have done extensive testing of that on a multitude mcus to be sure of that.
     
  14. dannyf

    Well-Known Member

    Sep 13, 2015
    1,825
    364
    Undesired, yet, but nothing strange about the phase noise -> in his case, from the left-most rc oscillator. The 2nd comparator is simply an output shaper, not necessary here.
     
  15. ronv

    AAC Fanatic!

    Nov 12, 2008
    3,292
    1,255
    I think it would be very small input signal, but the way it is made the comparitor is sitting right at it's switching threshold so circuit noise will make it toggle. At least I think that is how it works. :D
    For sure only 5 or 10 mv of noise on the power supply would sync it up and force it to the protection feature. Can you watch the code to see how often it needs to retry? Just a few would really slow it down.
     
  16. dannyf

    Well-Known Member

    Sep 13, 2015
    1,825
    364
    Here is the adc version of the same thing:

    Code (C):
    1.  
    2.         IO_FLP(RNG_PORT, RNG_CLK);            //flip the clk pin to create a clock
    3.         RNG_cnt = adc_read(RNG_ADC);        //read the adc -> not connected to any external pin
    4.         if (RNG_cnt & 0x01) IO_SET(RNG_PORT, RNG_OUT); else IO_CLR(RNG_PORT, RNG_OUT);    //set / reset rng_out based on lsb of rng_cnt
    5.  
    I got about 10kbps with a stock adc_read() routine (2us Tad, full 10-bit, right adjusted, with channel select). If you tailor the adc routine for your specific application (by eliminating channel selection, and only return the lowest 8 bits of adc), you can speed up the execution considerably.

    Moderators note: Please use code tags for the used language.
    Please read the following thread how to use them:
    Expand code syntax beyond the web languages.
     
  17. fermevc

    Thread Starter New Member

    Jul 20, 2015
    10
    0
    @dannyf, thank you for all your effort, code and hints!
    This is a new approach for me, and I need more time to digest the code examples you've presented.
    I don't have too much experience in MCU programming, it took me 2 months to go over author's Assembly code (which is, btw, commented very good) and I hope I can understand "C" faster.

    Sorry ronv, I didn't understood you question, what retry you're referring to?
     
  18. ronv

    AAC Fanatic!

    Nov 12, 2008
    3,292
    1,255
    I think the code detects when there are to many 1's or 0's in a row and makes an error - then restarts. This slows things down.
    If you have a scope you could scope the output of the comparator to see if there are missing pulses like shown in the picture.
     
  19. dannyf

    Well-Known Member

    Sep 13, 2015
    1,825
    364
    I would be seriously surprised if this thing actually does 72kbps - 220k/0.1u is too slow for that kind of speed.
     
  20. dannyf

    Well-Known Member

    Sep 13, 2015
    1,825
    364
    Optimizng the code a little bit, I can push the generic version to about 12kbps.

    Using port change interrupt flag to test pin state changes, I can generate random bits at 33kbps, on a pic running at 1MIPS.

    AVRs can run at 16MIPS so I think it is possible to get close to 500kbps+ out of an avr using this approach.
     
Loading...