rngd: failed fips test

[Jorge_C]

Hello,

I just recently purchased a TrueRNG for my centos server since my entropy pool was always hanging around 120-160. I successfully set up the TrueRNG with the udev rules available on this site and now my entropy pool is always maxed out and fills up quickly when used.

I decided to make a 5G file to test the randomness with ent and dieharder (which produces failures for smaller test files) and to do so I used the following command:

dd if=/dev/ttyACM0 of=truerng5G.bin bs=1M count=5120 iflag=fullblock

That is running fine at around 47 KB/s. However while monitoring /var/log/messages for another program I noticed rngd is output this error every minute or so: “failed fips test”. I had this same issue earlier but it was much worse with this error happening a few times in less than a minute followed by a message saying it was disabling the source because of the failure. I fixed this by restarting the server (didnt have physical access to replug the device at the time).

When it failed completely earlier It would output at like 5 KB/s. Currently its still running at full speed at around 47 KB/s so I don’t think it has failed completely.

Just doing some more testing this seems to be happening when rngd fills the entropy pool while dd is also using the device. Does this sound like this is what the issue is? What does a fips failure mean? Is that a failure to read from the device or is that a failure of the randomness?

My worry here is that it is only happening now at an accelerated rate because I am stressing it by running dd and rngd on the same device. I’m worried this will continue to happen with just rngd running, just at a slower rate. This wouldn’t be an issue if it didn’t eventually quit because of the errors so I’d like to figure out exactly whats causing them.

Here’s some infos about my setup:
CentOS release 6.6 (Final)
rng-tools-2-13.el6_2.i686
Linux 2.6.32-504.12.2.el6.i686 #1 SMP Wed Mar 11 19:05:53 UTC 2015 i686 GNU/Linux
stty -F /dev/ttyACM0 outout:

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

[Jorge_C]

Ok Its for sure nothing to do with using DD and rngd at the same time, the error is most definitely caused by rngd alone.

I just restarted the centos server with the TrueRNG unplugged. Once it boots I plug it in and run the following:

rngd -o /dev/random -r /dev/TrueRNG –fill-watermark=90% -t 1 -s 1024

Every second this causes rngd to output the fips error. Decreases the amount written at once using the -s flag slows this error down but does not stop it. At the default of 64, this error still pops up every minute or so.

Does this mean the TrueRNG I bought is defective?

EDIT: Ok I just tried a few different versions of rngd and they all have the same issue. This is being caused by the –timeout or –feed-interval option. Every time rngd adds entropy to the main pool it produces a fips error. This can’t be good, really would like some input on this problem before its too late to take advantage of Amazon’s return policy.

• This reply was modified 9 years, 8 months ago by Jorge_C.

[Jorge_C]

Ugh I can only edit my post once, thats kind of lame. I made a mistake earlier and wasn’t actually running the latest version. When I tried again using rngd 5 it seems to keep the entropy filled without showing any fips failures. Now, however, the speed is low through /dev/random. Before it would be around 47 KB/s but now its barely 10 KB/s. This is the command I am using to test the throughput:

dd if=/dev/random of=/dev/null iflag=fullblock count=1024 bs=128

Using /dev/TrueRNG instead of /dev/random gives the full speed. This seems like another problem with rngd. Which version is best?

Ok I’ve now tried all the versions. Anything version 3 and under doesnt keep the entropy pool full (only fills it every 60 seconds) unless you pass the –timeout (otherwise known as –feed-interval) option with something less than 60. All versions less than 3 generate a fips failure whenever they try to fill the entropy pool, whether the pool is full or not. Versions greater than 3 lack the –timeout or –feed-interval options but still manage to keep the entropy pool full. However they only do it at 1/4th the speed that the device supports.

So now the only issue I need to fix is this slow /dev/random output from rngd.

• This reply was modified 9 years, 8 months ago by Jorge_C.

[Ubld.it Staff]

Jorge,

Please contact us via e-mail with your order number so we can start a support request. We’ll get you fixed up quickly. E-mail: support@ubld.it

ubld.it

[Jorge_C]

My order # is #002-8779659-9757002.

Here’s also the output of rngtest -c 100 for both /dev/random and /dev/TrueRNG

/dev/random:

rngtest: starting FIPS tests...
rngtest: bits received from input: 2000032
rngtest: FIPS 140-2 successes: 100
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=88.879; avg=92.280; max=177.222)Kibits/s
rngtest: FIPS tests speed: (min=119.209; avg=124.346; max=126.314)Mibits/s
rngtest: Program run time: 21180684 microseconds

/dev/TrueRNG:

rngtest: starting FIPS tests...
rngtest: bits received from input: 2000032
rngtest: FIPS 140-2 successes: 100
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=349.734; avg=366.134; max=19531250.000)Kibits/s
rngtest: FIPS tests speed: (min=122.266; avg=124.015; max=126.314)Mibits/s
rngtest: Program run time: 5349974 microseconds

Apparently the input channel speed for /dev/random is very slow. This only happens using the latest version of rngd. If I switch to the old v2 rngd the input channel speed for /dev/random is as it should be around 47 KB/s but it crashes after a few minutes when it gets too many fips failures and disables the TrueRNG.

edit:
Also found something interesting when running cat /dev/TrueRNG | rngtest -c 1000:
rngtest: starting FIPS tests…
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 998
rngtest: FIPS 140-2 failures: 2
rngtest: FIPS 140-2(2001-10-10) Monobit: 1
rngtest: FIPS 140-2(2001-10-10) Poker: 1
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=177.806; avg=353.555; max=20646.142)Kibits/s
rngtest: FIPS tests speed: (min=97.813; avg=123.935; max=126.314)Mibits/s
rngtest: Program run time: 55397035 microseconds

see the bolded text, this may be related to the fips failures I’m getting when using the old rngd version.

• This reply was modified 9 years, 8 months ago by Jorge_C.
• This reply was modified 9 years, 8 months ago by Jorge_C.

[euler357]

For a hardware random number generator, some percentage of FIPS failures is normal. If you weren’t getting any failures, that would be a problem. The reason is that in a random sequence, the patterns that rngtest is looking for happen randomly (see page 5 of the TrueRNG manual http://ubld.it/wp-content/uploads/2014/02/TrueRNG_Manual_rev2.pdf). There are also several papers published on testing hardware random number generators (for example: http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf) . It is only a problem if the failures are consistently high (over maybe 1% of the total). Here is a longer test showing what should happen:

rngtest 4
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests…
rngtest: entropy source drained
rngtest: bits received from input: 29500399616
rngtest: FIPS 140-2 successes: 1473873
rngtest: FIPS 140-2 failures: 1146
rngtest: FIPS 140-2(2001-10-10) Monobit: 133
rngtest: FIPS 140-2(2001-10-10) Poker: 144
rngtest: FIPS 140-2(2001-10-10) Runs: 441
rngtest: FIPS 140-2(2001-10-10) Long run: 434
rngtest: FIPS 140-2(2001-10-10) Continuous run: 1
rngtest: input channel speed: (min=1818181818.182; avg=28514767076.017; max=0.000)bits/s
rngtest: FIPS tests speed: (min=37.472; avg=85.994; max=90.396)Mibits/s
rngtest: Program run time: 328350153 microseconds

Using the ent tool:
ent FILENAME
Entropy = 7.999984 bits per byte.

Optimum compression would reduce the size
of this 10485760 byte file by 0 percent.

Chi square distribution for 10485760 samples is 232.74, and randomly
would exceed this value 75.00 percent of the times.

Arithmetic mean value of data bytes is 127.4826 (127.5 = random).
Monte Carlo value for Pi is 3.143464334 (error 0.06 percent).
Serial correlation coefficient is -0.000603 (totally uncorrelated = 0.0).

Your rngtest results looks fine. Just to be sure, can you please stop rngd and run ent (ent FILENAME) on a 10MB file captured from the TrueRNG directly to see if the TrueRNG is ok?

(Assuming that you used our udev script or have manually disabled modemmanager — it sends junk out over the port to try to auto-detect a modem so you need to have this uninstalled or disabled)
Commands are:
dd if=/dev/TrueRNG of=FILENAME bs=1k count=10k iflag=fullblock
ent FILENAME

dd will take 3-4 minutes to run.

Chris

[euler357]

I’m running Ubuntu 13.10 and rngd 4. I tried to reproduce your issue but can’t.

Here is a video of what happens when I try what you posted: http://youtu.be/nSD3MD2JTvE

Notice that when I run rngtest with the same block size as rngd, I get 0 failures. This is because rngd does the FIPS test and discards those blocks that are “failures”. This is the expected behavior.

Also, notice that my speed went down to 16k or so when using your rngd options. When I run it from init.d or directly without your options (i.e rngd -r /dev/TrueRNG -o /dev/random), I get the full speed back.

As for the -t 1 (timeout) option, I’m not 100% sure what this does and why you need it. It seems to coincide with the timing of your error message though (timeout = 1 sec, your error = 1 second intervals).

Chris

[Jorge_C]

The timeout options seemed necessary for me in earlier versions because without it rngd only increases the entropy pool every 60 seconds, which isn’t good enough and causes the entropy pool to be at around 120-180 except once every 60 seconds when it shoots back to up max and then quickly drains itself again before the next 60 second interval. I also should point out that -t doesn’t cause my fips errors, it merely increases the frequency of them. If I leave it stock with the old version it WILL still disable the entropy source after 25 failures, it just happens in 30 or so minutes with stock options compared to just a minute or so with the -t option speeding things up. My error only correspondes to when rngd versions 1-3 update the entropy pool.

Having fips failures isn’t a problem, ok, but having 25 fips failures is still a problem because rngd will disable the entropy source after that many fips failures. So while it may not affect the quality of the entropy, it will still fail to increase the entropy forever when using the older versions. This is annoying but I can use the newer versions and don’t get any fips errors, I just get really slow throughput.

here’s the ent output from the 10MB sample:

Entropy = 7.999982 bits per byte.

Optimum compression would reduce the size
of this 10485760 byte file by 0 percent.

Chi square distribution for 10485760 samples is 262.63, and randomly
would exceed this value 35.79 percent of the times.

Arithmetic mean value of data bytes is 127.4993 (127.5 = random).
Monte Carlo value for Pi is 3.141457039 (error 0.00 percent).
Serial correlation coefficient is 0.000417 (totally uncorrelated = 0.0).

Going through /dev/TrueRNG was fast too, 45/8 KB/s.

So to recap, At the moment the only problem I am having is slow output from /dev/random at about 10 KB/s (1/4 the speed). The throughput from /dev/TrueRNG is fine however. When I switch back to an early version of rngd it will output at full speed from /dev/random but will produce fips failures whenever it fills the entropy pool, eventually disabling TrueRNG after 25 fips failures.

[Jorge_C]

I feel like an idiot now. I was finally able to get the speed from /dev/random back up to normal. The -s option (number of bytes written to the device at a time) I was using with the latest version was causing the slowdown. I thought increasing the number of bytes written to 1024 would increase the speed, not sure why I never tried it without that option on the latest version. Everything seems fine now, latest version of rngd allows you to ignore fips failures and the speed is fine. Was just the options I was using.

Thanks for the support, glad everything is working right. Now I can finally generate the 5GB test file without having to worry about fips failures too.

• This reply was modified 9 years, 8 months ago by Jorge_C.

[euler357]

Jorge,

Your ent output and speed looks good – no issues that I see.

Glad that you got it working – let me know how your 5G test goes.

BTW. The command line for running dieharder on the file is:

dieharder -a -g 201 -k 2 -s 1 -f input_file > dieharder.results.txt

Chris
https://cockrum.net

[Author]

Posts