[Ubld.it StaffModerator]

It’s also worth mentioning that with the TrueRNGPro, you can turn off the whitening algorithm. This gives you access to the raw random numbers before any xoring or merging of samples is done.

Typically the reason you see a even distribution is due to the whitening. The raw values (if they are of interest to you) produce more of a bell curve. Which when plotted — look like a bell. The center of the bell being the most common values, and the outlayers 0 and 255 being the least common number. Some of our customers are more interested in this or implement their own whitening algorithm using this data. This is more in line with your flipping a coin analogy and getting heads more times in a row than you do from a random number generator.

As for the ‘un-generatable’ numbers, I’m still a little confused because if you check the distribution of a sample set, you will see that all bytes have a pretty even distribution, if you count the frequency of each byte (which you can do with “ent -c” in linux) . If you were to plot the count of each byte, they will be within the same order of magnitude of each other, which means all numbers are generated at about the same frequency.

I hope this helps further answer your question.

• This reply was modified 7 years, 8 months ago by  Ubld.it Staff.

[Ubld.it StaffModerator]

Quadko,

For the TrueRNG, each bit has probability of 0.5. The probability of getting 2 1′s in a row is 0.5 x 0.5 =0.25. Or 0.5^2. The probability of getting 32 1′s in a row is 0.5^32 = 2.3283064e-10 or about 1 in 4294967296 which would occur about every 24 minutes with the TrueRNGpro at 3 Mbps.

With most pseudo random generators, you will never see 32 zeros but will see every other state unless it is running through a FIPS-140-2 filter which eliminates certain patterns.

[Ubld.it StaffModerator]

Sure Denis, if you have it hosted somewhere just post a link here. Otherwise try emailing it to support@ubld.it and we will link it up. If it’s too big it will have to be dropboxed or something.

Thanks again.

[Ubld.it StaffModerator]

The baud rate setting here has no effect on the modes (of the pro) it just makes sure the controlling tty doesn’t limit the rate of bytes through the virtual serial port. It is in Normal mode by default.

[Ubld.it StaffModerator]

Sure thing, be sure to post any test scripts with the details, and possibly your rgnd configuration, since rngd is responsible for watermarking the random pool and filling it based on that, that way we can try to re-create what you are experiencing.

[Ubld.it StaffModerator]

This is a tough question. This could be caused by your usb chipset, or a snafu in VirtualBox. The only way to determine this is to do a little debugging. I assume you are running Windows as your real host ? You can try not passing the TrueRNG to the VM, and running it in windows with our Windows Driver. We have a tool called rngcapture that (runs in a dos window) but can create a large dump capture of random data. Start there and see if you get an error in windows. Next if you have another machine (hopefully native linux) you can try the TrueRNG Pro there.

Virtualized USB is a tricky beast sometimes, and while we use VMs here to test, we found VMWare Player’s usb support much better than VirtualBox, not to know 100% the specifics, but something about proxyied USB versus passthru. What you can try also is turning off USB 3.0 support (the Pro does not need 3.0).

Some googling on your XHCI messages point towards a chipset/bios problem on the machine, but your case in compounded by the Virtual Machine.

We run each unit through a series of tests before they leave here, but if the unit is faulty we will gladly replace it. If you could help by trying some of the things mentioned above (new machine, windows only, vmware player, 3.0 off, etc) it would be greatly appreciated in helping diagnose your issue.

[Ubld.it StaffModerator]

There should be no problems with 24/7 use. We have personally had a few of these plugged in for a few years now running 24/7 and haven’t noticed any problems. The V2 has 2 noise generators that are mixed together, even if one was to fail, the other would still be generating enough random data to carry it, if they both were to fail they would theoretically fail in different ways and the mixing of the two could still produce good entropy, we have tested this by artificially causing a generator to fail… and at the end of the spectrum if you are using RNGD, it will be running fips 140-2 on the incoming stream before entropy is inserted in the kernel. I hope this helps.

[Ubld.it StaffModerator]

Thanks Sylvain!

[Ubld.it StaffModerator]

Your frequency distribution plot should look about like this. There is some variation due parts tolerances. The mean should be between 400 and 600. The standard deviation should be between 30 and 100 (usually about 50).

If you want the mean to be some other value, you can just subtract to move the distribution to that point to scale by some multiple. By removing the LSB, you get rid of some of the bias (i.e. the “spikes” in the distribution) and scale it by 1/2 so the mean and standard deviation is now 1/2 of what was before.

Here are a couple of our unit tests:

RNG1 Mean: 491.560824 Std Dev: 51.150222 Within Expected Range
RNG2 Mean: 492.534488 Std Dev: 53.114889 Within Expected Range

RNG1 Mean: 480.277512 Std Dev: 46.301158 Within Expected Range
RNG2 Mean: 481.020530 Std Dev: 47.724982 Within Expected Range

[Ubld.it StaffModerator]

8 values is not statistically significant enough to see the distribution. This is a statistical probability distribution and not guaranteed over a finite set of values.

see https://en.wikipedia.org/wiki/Probability_distribution

For the ADC bias, it is bias introduced by the ADC of the micro controller. The entropy of the LSB is reduced by the ADC bias. This is dependent on the internal design of the converter and manufacturing variations. This means that the LSB value is more likely to be either a zero or one depending on a large number of factors.

There are many documents on this topic such as
https://www.maximintegrated.com/en/app-notes/index.mvp/id/748

Hope this helps

[Ubld.it StaffModerator]

Sorry Ben, we just sent out a response to your email.

[Ubld.it StaffModerator]

Hi there. So 1 yes it is still sent in 64 byte URBs. 2) The data won’t be whitened, Data shows up in Gaussian distribution and not every bit will have equal entropy. 3) Yes, see the TrueRNGPro additional modes for more documentation on that. 4) Yes, raw mode doesn’t throw away any of the samples as the whitened mode does so it is faster.

[Ubld.it StaffModerator]

Paul, we’ll contact you via e-mail.

[Ubld.it StaffModerator]

Thanks for your input, we will look into this and possibly change the next rev of the board after we re-run the calculations.

[Ubld.it StaffModerator]

It should be a few minute job to modify the mdev rules for the TrueRNGV2 to work on the pro. the Pro has a different usb PID, aside from that it functions the same way as a USB CDC serial port, except faster and the other shell scripts to put it into RAW mode and what not.

As for script contributions, we will gladly take any improvements.

[Author]

Posts