[Ubld.it Staff]

1) In windows, the INF simply provides the USB Serial driver so that you can access the random stream generated by the device. It does not seed the windows kernel. Even in Linux this does not happen automatically, there is another program (rngd) that reads the TrueRNG and seeds the kernel. While this is technically possible in windows, I am unsure how to facilitate that, but applications by themselves can use the device by reading the serial port.

2) Not knowing how the source code of KeePass looks, I doubt it knows to pull entropy from the TrueRNG. Not to say that it couldn’t do so, there is just no standard mechanism for something like that in windows that I am aware of. The Device Descriptor for TrueRNG acts like a standard USB Serial port, so it’s just a matter of reading data out of the port.

3) I just put a blog post up with a link to a tool we wrote to capture data from the TrueRNG in windows, it appears that RealTerm likes to lock up while using it randomly as many of our users have stated. The rngcapture program we made isn’t pretty but it works. Here is a link to the blog post. The tool is also in the Downloads tab of the product page.

[Ubld.it Staff]

That’s great news. We didn’t want to force people to symlink hwrng because some systems have a built in hwrng already (as that is the default node for hardware random number generators). But It’s great you were able to get it working!

[Ubld.it Staff]

Just for the record, I am seeing similar results. Without rngd running I get like 5 bytes/s which is to be expected since I have no entropy. With rngd running (and with the TrueRNG) I get about 12.6kB/s dding from /dev/random. And I get like 47k directly from the rngd.
I have to assume there are a few factors here. First rngd is probably polling the entropy and has some millisecond delays on reaction. Second rngd is running a fips-140 test on chunks before it contributes to the kernel. Third the kernel can choose to not accept all the bytes and mix in natural entropy. Between all of the variables it takes quite a hit. But going from a few bytes a second to > 10kB/s from /dev/random is still great in our opinion.

ubld.it

[Ubld.it Staff]

Hey there,

So first off your speculation about fullblock is true, we made a blog post about it back in april, it just seems to be the nature of how character devices deal work with dd.

As for your other 2 issues… First let me think about the two TrueRNG’s, you are correct the udev rule would end up making only 1 sym link, but in order to have both contributing to the entropy pool, you may need 2 instances of rngd. We haven’t tried doing that but I would assume if you launch them both using command line arguments:
e.g. rngd -r /dev/ttyACM0 and rngd -r /dev/ttyACM1
It may just work, you can try this manually and then modify some custom start scripts if it works…

As for your other item, the available entropy not increasing, I would have to assume that rngd is unable to contribue to the entropy pool for whatever reason, maybe because of the changed permissions ? You have 2 identical installs, and 1 works and 1 doesn’t, obviously something is different. It’s difficult to diagnose without seeing it. I would suggest looking at /var/log/messages or running rngd in the foreground with verbose on to see if it gives any indication of why.

Also, check your version of rngd, Some versions of rngd don’t accept the watermark in percentage, only in absolute bits.

[Ubld.it Staff]

The USB PID we use for TrueRNG was officially sub-licensed to us via Microchip, which they provide as a service since we use a Microchip microcontroller in the TrueRNG. We have not added our PID to the linux repository for usb.ids however (which I believe is where the name matching comes from in Linux). But there should be no fear of PID conflict.

[Ubld.it Staff]

Nick, we’ll send you an e-mail. Most customers already have v2 firmware.

[Ubld.it Staff]

This looks pretty normal to me. From the TrueRNG side (hardware), it is generating plenty of entropy. However, there are other factors at play. First off according to your settings, rngd is only filling once per second. So thats why on most of the dips, entropy goes down, then back up. If rngd was more responsive it would theoretically attempt to fill faster. I think rngd’s lowest interval is 1 second, unless you omit the option and let it force feed the pool as fast as it can.

Here is a snippet from the ubuntu man page of rngd.

-t n, –feed-interval=n (default: 60)
If feed-interval is not zero, rngd will force-feed entropy to
the random device even when the entropy pool is full every feed-
interval seconds. Setting this too low may cause rngd to
dominate the contents of the entropy pool.
.

Second is the kernel it’s self. Just because rngd tries to give it entropy, doesn’t mean the kernel has to take it. This algorithm of accepting outside entropy (to mix with naturally occuring hardware event entropy) varies from kernel version to kernel version and distribution.

For the most part I can say what I’m seeing if I plot these numbers on a spreadsheet is normal. For reference, I believe our graph was taken on a Ubuntu machine without using the feed interval argument.

[Ubld.it Staff]

It’s possible that minicom/picocom are setting flow control characters on the tty. Since the TrueRNG’s output is random, it randomly will push out any byte which may be a control character if the tty is set for that sort of thing. Are you using /dev/tty.usbmodem[12345] or are you using /dev/cu.usbmodem12345 with dd/cat ? The difference I believe is cu. asserts DTR which is implemented on the TrueRNG as flow control (DTR on meaning you are ready for data).

Try doing a fresh plug/unplug (that will reset any flow control I hope), then without opening the port with any terminal program do cat /dev/cu.usbmodem[12345 whatever or tab completion] > testfile and see if it works.

Here’s some more info on the difference between tty.usbmodem and cu.usbmodem

https://stackoverflow.com/questions/8632586/macos-whats-the-difference-between-dev-tty-and-dev-cu

I’ve just always known cu.usbmodem to be the way to go as it’s not a real tty, and this is true for other usb-serial devices like FTDI chips in Arduino’s etc.

[Ubld.it Staff]

Yep, it uses the cdc-acm driver.

[Ubld.it Staff]

Just doing
dd if=/dev/cu.usbmodem141 of=random.bin count=1m bs=64
appears to work just fine in mavericks, you don’t need to run it through cu to use the cu device as a interface to dd. And I tried it with multiple counts and block sizes, and let it run in a while loop for awhile and I didn’t have any issue.

[Ubld.it Staff]

Thanks for the feedback on the TrueRNG.

Being a hardware random number generator, the TrueRNG has a tiny amount of analog-to-digital converter (ADC) bias that is inherent in physical devices. In your example, this bias is about 0.01247%. This has a negligible affect on the entropy and shouldn’t be an issue for most applications.

For the dieharder test, we missed the lack of the -g 201 command line argument in the published test. Future tests will be run with this option.

In general, the dieharder tests often fail for hardware random number generators for a variety of reasons. From the dieharder man page:

“The null hypothesis for random number generator testing is “This
generator is a perfect random number generator, and for any choice of
seed produces a infinitely long, unique sequence of numbers that have
all the expected statistical properties of random numbers, to all
orders”. Note well that we *know* that this hypothesis is technically
false for all software generators as they are periodic and do not have
the correct entropy content for this statement to ever be true.*
However, many hardware generators fail a priori as well, as they
contain subtle bias or correlations due to the deterministic physics
that underlies them.* Nature is often *unpredictable* but it is rarely
*random* and the two words don’t (quite) mean the same thing!”

The current version of TrueRNG has a minimal XOR whitening algorithm, just enough to remove some of the bias without impacting throughput. We do have an experimental version that changes the whitening algorithm to null out most of the ADC bias, with a small decrease on throughput. Although this has minimal effect on the entropy of the stream, it does help to pass the Chi Square and some of the Dieharder tests (with the right command line options this time!)

With the changed whitener, We’ve captured two 1.8GB files and ran the ent, rngtest, and dieharder tests on the data. We have duplicated your ent test on 100MB chunks via “split test1.8GB.txt -n 18 –filter ent”. When grep’d for the Chi Square value, we got:

For test1.8G-1.dat
would exceed this value 50.00 percent of the times.
would exceed this value 75.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 25.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 75.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 25.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 99.50 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 10.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 25.00 percent of the times.
would exceed this value 75.00 percent of the times.

For test1.8G-2.dat
would exceed this value 25.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 99.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 75.00 percent of the times.
would exceed this value 2.50 percent of the times.
would exceed this value 25.00 percent of the times.
would exceed this value 75.00 percent of the times.
would exceed this value 10.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 50.00 percent of the times.
would exceed this value 25.00 percent of the times.
would exceed this value 50.00 percent of the times.

For comparison, we reran the dieharder test on 1GB of data using the original whitener and got a few weak and a failed test (dab_bytedistrib – which uses Chi squared internally). The results are somewhat better with the changed whitener but still has a single failure in the dab_bytedistrib test. We’re guessing that the small amount of bias that remains from the physical device accumulates over such a large dataset causing the failure.

After testing, we plan to incorporate the updated whitener into the baseline. We will also be correcting our manual, and thanks for pointing that out.

If you would be interested in a version with the updated whitening, email us at info@ubld.it and we will work something out.

[Ubld.it Staff]

Once again I want to thank you for your contributions and making installation easier for other users. We appreciate this behavior. In the future we may update the TrueRNG with more features, if and when we do we, we will be happy to send you an early release for your troubles. Thanks again.

[Ubld.it Staff]

So good news is I was able to reproduce your problem exactly with Centos 6. Here’s some initial observations;

Centos 6.5 – 2.6.32-431 kernel – default termios settings

speed 9600 baud; line = 0;
-brkint -imaxbel

Mint 15 – 3.8.0-33 kernel

speed 57600 baud; line = 0;
eof = ^A; min = 1; time = 0;
-brkint -icrnl ixoff ixany -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

First thing to notice is Mint 15 is doing -everything (which is what we want, and explains why I wasn’t seeing this problem initially). The next thing to notice is 3.xxx kernel vs 2.6.xx kernel which is where I think the biggest disconnect between distros is.

So I have the advantage of using a USB analyzer to see what exactly is going where to see what effect these things have. First thing I notice is on the CentOS side, it’s actually sending characters upstream to the microcontroller. This isn’t an issue, the micro just drops then, but this is wasted bandwidth (maybe about 1k/s difference if that). Adding stty -echo seems to fix that and characters are no longer being sent upstream.

The second part is the stream stopping. So when the stream stops the DTR flag is killed, this means linux actually closed the port. It appears that linux sees the EOF/KILL/Whatever character in the stream randomly (which you can see different stop points to prove that) it closes the port and thinks its done reading data. After doing stty -icanon, the stream is perfect (from the analyzer side) and doesn’t do anything odd any more.

Now looking at -echoe and -echok these seem to only affect what happens when data is sent to the microcontroller from linux, such as adding a nl after cr.

So what we really need is stty raw -echo

Testing this on both distros produces the following.

CentOS 6.5

speed 9600 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost
-isig -icanon -echo

The delta between the initial state is -icrnl -opost -sig -icanon -echo

On Mint 15 we get

speed 57600 baud; line = 0;
eof = ^A; min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

The delta here is exactly the same, except the initial state also had ixoff ixany. Stty shows this for those flags

 * [-]ixany      let any character restart output, not only start character
   [-]ixoff      enable sending of start/stop characters

So I decided to go with stty raw -echo -ixoff

I’m in the process of updating the udev rules on the web site with the changes.

Again I appreciate your help, please let me know if there is anything we can do for you in return.

[Ubld.it Staff]

I would be lying if I said I wasn’t embarassed by not explicitly setting the termios settings in the udev rules. We’ve been testing the TrueRNG on mostly debian based distros for months now and never ran into this issue. I would think the default port states would be identical. In fact we are running a long entropy test as we speak capturing 100gigs of data to analyze, and it hasn’t hiccuped 1 bit.

While inspecting the rng-tools daemon init code just now, they don’t set any termios settings (and why should they?, they don’t know anything about the source file descriptor). While in canonical mode, and with other line mode features enabled I can picture this happening. My knee jerk reaction says we want to use raw (which is basically -everything). But I will experiment tomorrow starting with the same distro as you.

I really appreciate your patience and effort thus far. I’m going to spend the next few days installing a few major distros to inspect this case further and update our udev rules with your fix. I will say setting the baud rate shouldn’t make any difference at all, as the serial port is virtualized it’s at the mercy of the usb bus… but it doesn’t hurt anything to set it to a high number.

[Ubld.it Staff]

Nice script, much appreciated!

[Author]

Posts