[Ubld.it Staff]

It took a few days to figure out a solution for mdev systems. The product page download section has been updated with a link to a tgz for mdev systems (link is also here). There are 3 files in the tgz, (with paths to make it easy to extract to /). The first file is “README” this file will explain the install in more detail. The second is “/etc/mdev.conf.truerng.addon” this file contains like 2 lines to be added to the tail end of your /etc/mdev.conf. The 3rd file is /lib/mdev/truerng which needs to be in /lib/mdev with execute permissions.

The test system was Alpine Linux, since it was referenced above and an ideal candidate for testing. I hope this works with other mdev systems correctly. The scripts will create the /dev/TrueRNG symlink when the TrueRNG is inserted just like its udev counterpart. It will also set the tty correctly to raw mode so that the terminal doesn’t interpret any codes. Lastly it will remove the symlink when the device is removed.

[Ubld.it Staff]

If there is still a need for mdev rules, we’ll start going over the mdev documentation and see what we can put together. Hopefully we’ll have something in the next few days.

[Ubld.it Staff]

Hey there, Have you tried using RNGCapture? It’s a small command line utility that we wrote because of the issues people were having with third party software. It’s nothing special but it should work just fine. It’s available on the TrueRNG product page under downloads, and also here is a direct link. There is also a blog post about it here.

[Ubld.it Staff]

Currently one doesn’t exist, but we can look into helping make some.

The basics are simple,
* symlink (if you can) to /dev/TrueRNG so if you have multiple ttyACMx devices its easy to find (and start iwth rngd)
* set the serial port to RAW meaning no control characters
* maybe something else I’m missing.

In some systems the udev rules aren’t needed at all, its just over time we’ve found a few quirks with different distros and the udev rules seem to help make things more consistent.

What distro are you running ? and is mdev the default or your choice ? usually mdev is used on embedded systems with busybox.

[Ubld.it Staff]

It sounds like the udev daemon isn’t getting insert notification from the kernel and is only running on bootup, I’ve seen this happen when people switch to mdev (for more embedded environments) instead of udev. Hmm. Maybe I can get a hold of an ipfire virtual machine and poke at it to see whats going on.

[Ubld.it Staff]

Hey there,

Ok lets see what we can do. First off let me say that it really depends on the default port settings per operating system, they are different. The stty rule is needed to force the serial port into raw mode if the default is not already raw. It is possible you don’t need the stty command but if the port isn’t in raw mode it means that serial control characters like flow control and EOF are enabled. If these special control characters are enabled, they do not pass as raw binary bytes through the dev node, and the FIPS-140 test that rngd does can fail because it will see the data isn’t completely white.

I haven’t tested it, but it looks like you’re having issues having multiple RUN statements, since you want the rngd to run when udev enumerates the device, try combineng both with a semi colon instead of 2 RUN statements. Like RUN+=”/bin/stty raw -echo -ixoff -F /dev/%k speed 3000000; /etc/rc.d/init.d/rngd udev-event”

On the note of the rngd: read errors, this is exactly what type of thing can happen without stty. More info can be found on this thread.

And finally as for shutting down rngd when the device is pulled. You might try creating 2 udev rules instead of one that does ACTION=”add|remove” where the remove will shutdown rngd and the add will start it (after the sym link is created, then stty is run on it of course)

[Ubld.it Staff]

Great I’m glad it was just the DTR issue. And that makes sense for the residual, since the usb stack pulls the data from the TrueRNG the driver is just holding it until someone pulls it out. That’s just the design of USB.

[Ubld.it Staff]

Since rngcapture is working fine, the only thing I can think of is DTR. The TrueRNG uses the DTR signal to control the flow of data. It’s always generating random numbers, but when DTR isn’t present it throws them away stopping the stream. In rngcapture we specifically control DTR. Just opening a serial port should behave the same way (without any manual control) but I’m at a loss why this program would stop receiving data but rngcapture works as expected.

Maybe instead of going into a deadlock loop with “while (port.BytesToRead == 0); ” you need to take a more cpu yielding approach with a callback or something. Some quick googling shows you aren’t alone in this issue. See this post on stackoverflow. It looks like it just needs to be done differently. That method works fine for a simple c program (like rngcapture almost does essentially that).

[Ubld.it Staff]

On some systems, /dev/random and /dev/urandom are the same device. For instance OSX and FreeBSD, which implement (I believe) some smarts as to feeding real entropy when available, and pseudo random numbers when not available (to not block).

However, on most Linux distributions, random will block when no entropy is available (and it uses real entropy) and urandom will not, however, I don’t believe that urandom uses any real entropy what so ever, it is all pseudo random.

It is most likely possible to change the default OpenSSL behavior (to use random versus urandom) but I’m pretty sure that currently reads from /dev/urandom have no correlation to the entropy feed in by the TrueRNG.

So on my own test, I turned off the TrueRNG feeding by rng-tools so my entropy would be pretty low. I started logging the /proc node for entropy available. Then I did a read from urandom. I don’t see a noticeable change in entropy available. Without the TrueRNG feeding I’m bobbling from around 130-180. So then I thought, maybe each read gets seeded by a real random number. So then I created a while loop in bash and did hundreds of small reads while I logged entropy available. Same thing, bobbling. Then I did a single read from /dev/random. available entropy drops to near 0 and stays there until the amount of data I requested is fulfilled.

So I have no reason to believe urandom is using any real entropy (and sadly not being aided in any way by the TrueRNG).

[Ubld.it Staff]

Whoops, looks like 1.02 was updated so that the firmware base matches that of 2.0 code base, it should perform just like a 1.01 device (or a 2.0 device with 1 noise generator).

[Ubld.it Staff]

We have tested USB 3.0 ports and Win8 and haven’t noticed any issues. We’ve sent you an email (check your spam folder if you haven’t gotten it) about proceeding with RMA.

[Ubld.it Staff]

@zsaw We have been going back and forth amongst ourselves trying to theorize how this could happen. Those batch of v2’s were tested twice by 2 different people before shipping, and we ran them through ent/fips/histograms and they all checked out.

I’m going to contact you via email and see if we can gather some other info and possibly do a RMA.

For the record there is a 1mb test capture on the product page you can also run through your own code to rule out a capture problem (file is here) if you want to run that through your c# code.

[Ubld.it Staff]

This is correct.
1.0 is the original firmware.
1.01 is the updated whitener
and 2.0 is shipping on new devices with dual noise sources. Some early betas might have gotten mixed up (such as a handful of updated whiteners still saying 1.0, or 2.0 devices saying 1.01).

[Ubld.it Staff]

So currently we do not have a way of programmatically turning off the whitening. We would have to make some one-off units to do so, which means they need to be rebiased and slightly altered schematic. We’re looking into this.

[Ubld.it Staff]

Hey there,

So in regard to the statistically analysis, the updated whitener we (which is technically version 1.01 if you are checking your usb descriptors) passes dieharder tests and fips-140 just fine, this specific test for chi-squared test we are really happy about the performance (of the updated whitener), you will still get some occasional < 5%'s depending on how you chunk the data, and that is due to the nature of the test. It doesn't mean anything is wrong with it statistically and is less of a concern with a TRNG. Most of these tests were made for PRNG's and don't really apply to TRNG's, but we like to try and meet them if we can. As for availablility we should have stock real soon, we've made some slight improvements to the hardware design and we are still running it through its paces but it wont be long.

[Author]

Posts