[Jorge_CMember]

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 ago by  Jorge_C.

[Jorge_CMember]

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_CMember]

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 ago by  Jorge_C.
• This reply was modified 9 years ago by  Jorge_C.

[Jorge_CMember]

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 ago by  Jorge_C.

[Jorge_CMember]

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 ago by  Jorge_C.

[Author]

Posts