/dev/random does not block, emits poor entropy

/dev/random does not block, emits poor entropy

[starlight.2013z3]

For contrast, here is a 'rngtest' run against a
3.1.8 Linux kernel with /dev/random enhanced by
the output of a STMicroelectronics ST33 TPM PRNG
(via 'rngd' v4).

bits received from input: 62380032
FIPS 140-2 successes: 3115
FIPS 140-2 failures: 4
FIPS 140-2(2001-10-10) Monobit: 0
FIPS 140-2(2001-10-10) Poker: 0
FIPS 140-2(2001-10-10) Runs: 3
FIPS 140-2(2001-10-10) Long run: 1
FIPS 140-2(2001-10-10) Continuous run: 0
input channel speed: (min=21.119; avg=42.165; max=136.844)Kibits/s
FIPS tests speed: (min=41.374; avg=104.495; max=107.154)Mibits/s
Program run time: 1445.324494 seconds

That's three bit runs and one long bit run
in close to 8MB of random data.  Is well
inside the FIPS 140-2 document requirements.
Would likely be bad if there were none.
ST claims their PRNG is a

   AIS-31 Class P2 compliant true random
   number generator (TRNG)

The 'rngtest' output above is edited slightly
for better reading.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: /dev/random does not block, emits poor entropy

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]

On Sep 19 01:55, starlight.2013z3@binnacle.cx wrote:
> For contrast, here is a 'rngtest' run against a
> 3.1.8 Linux kernel with /dev/random enhanced by
> the output of a STMicroelectronics ST33 TPM PRNG
> (via 'rngd' v4).
> 
> bits received from input: 62380032
> FIPS 140-2 successes: 3115
> FIPS 140-2 failures: 4
> FIPS 140-2(2001-10-10) Monobit: 0
> FIPS 140-2(2001-10-10) Poker: 0
> FIPS 140-2(2001-10-10) Runs: 3
> FIPS 140-2(2001-10-10) Long run: 1
> FIPS 140-2(2001-10-10) Continuous run: 0
> input channel speed: (min=21.119; avg=42.165; max=136.844)Kibits/s
> FIPS tests speed: (min=41.374; avg=104.495; max=107.154)Mibits/s
> Program run time: 1445.324494 seconds
> 
> That's three bit runs and one long bit run
> in close to 8MB of random data.

Ok, let's compare that with the results of Cygwin's /dev/random as you
posted in your previous mail:

rngtest: bits received from input: 3088523264
rngtest: FIPS 140-2 successes: 154295
rngtest: FIPS 140-2 failures: 131


The # of bits received from input is about 49.5 times higher than what
you got from Linux' /dev/random.  So the number of events should be
divided by 49.5 for a fair comparison, right?  Lazily rounded up
I get:

                                         Linux   Cygwin/49.5
bits received from input:             62380032    62394409.4
FIPS 140-2 successes:                     3115        3117.1
FIPS 140-2 failures:                         4           2.7

The failure rate is better than on Linux.  That doesn't look bad to me.
Am I missing something?

Nevertheless I now added code to reseed the OS PRNG after each run of
512 bytes for the /dev/random emulation.  This results in even better
numbers for the price of slowing down access to /dev/random, which is
not much of a problem compared to the blocking behaviour of Linux'
/dev/random.  The new results with /dev/random are now along the
lines of:

  rngtest: bits received from input: 3059180032
  rngtest: FIPS 140-2 successes: 152857
  rngtest: FIPS 140-2 failures: 102
  [...]

which is another ~30% better result.  That should be sufficient, IMHO.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: /dev/random does not block, emits poor entropy

[starlight.2013z3]

Yes, this is great.  Thank you!

Subsequent to my post I learned more
on the topic.  Is complex and loaded
with controversy.  Many cryptographers
assert that Linux's blocking
implementation creates vulnerability
to various timing attacks and that
/dev/urandom is essentially the same
as /dev/random on a practical level
--is better for not blocking.

But the Linex devs are smart folks
and have yet to be convinced. . .

Hardware RNG marketing is deceiving
when it talks about "true" RNG since
even quantum-effect number generators
have non-random patterns that must
be algorithmically cleansed.
Rather than a "true" RNG or TRNG, one
wants as CSPRNG (cryptographically
secure pseudorandom number generator)
that combines a good source of hardware
entropy and appropriate purifying
algorithms.

People get quite hot about the topic,
and apparently the Dilbert cartoon
applies at all times, regardless:

http://dilbert.com/strips/comic/2001-10-25/

When the Federal government shutdown ends
the pages here will contain good information
(NSA influence over NIST not withstanding):

http://csrc.nist.gov/groups/ST/toolkit/rng/index.html


At 16:00 10/15/2013 +0200, Corinna Vinschen wrote:
>/dev/random.  The new results with /dev/random are
>now along the lines of:
>
>  rngtest: bits received from input: 3059180032
>  rngtest: FIPS 140-2 successes: 152857
>  rngtest: FIPS 140-2 failures: 102
>  [...]
>
>which is another ~30% better result.  That
>should be sufficient, IMHO.
>
>
>Corinna
>


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: /dev/random does not block, emits poor entropy

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On Oct 15 10:19, starlight.2013z3@binnacle.cx wrote:
> Hardware RNG marketing is deceiving
> when it talks about "true" RNG since
> even quantum-effect number generators
> have non-random patterns that must
> be algorithmically cleansed.
> Rather than a "true" RNG or TRNG, one
> wants as CSPRNG (cryptographically
> secure pseudorandom number generator)
> that combines a good source of hardware
> entropy and appropriate purifying
> algorithms.

The Windows RtlGenRandom (the underlying implementation of
CryptGenRandom which Cygwin will use from now on)  already is a CSPRNG.
It's sort of reassuring that it already shows pretty good results when
used in the simple /dev/urandom form, given the latest NIST/NSA
entanglements.  This is on Vista SP1 and later.  The implementation on
older systems is somewhat weaker.

> People get quite hot about the topic,
> and apparently the Dilbert cartoon
> applies at all times, regardless:
> 
> http://dilbert.com/strips/comic/2001-10-25/

:)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: /dev/random does not block, emits poor entropy

[Csaba Raduly]

On Tue, Oct 15, 2013 at 4:19 PM,  wrote:
>
> People get quite hot about the topic,
> and apparently the Dilbert cartoon
> applies at all times, regardless:
>
> http://dilbert.com/strips/comic/2001-10-25/

I see your Dilbert and raise you an xkcd:

http://xkcd.com/221/

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

/dev/random does not block, emits poor entropy

[starlight.2013z3]

I see that CryptGenRandom() does not appear
to have parameters to detect or control
the quality of entropy.

So possibly the correct solution to this
issue would be to eliminate

    /dev/random

and just leave

    /dev/urandom

in place.  'openssl' apparently uses /dev/urandom.

If someone needs to fake /dev/random they
can create a symbolic link for it,
knowing the risks they might be taking.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

/dev/random does not block, emits poor entropy

[starlight.2013z3]

Hello,

While poking around TRNG quality I came
across this apparent issue:

   /dev/random does not block, emits poor entropy

Running 1.7.17 but see no updates in the
1.7.18 thru 1.7.25 Changelog entries
regarding /dev/random.

Due to 'argp' library issues I could not
compile 'rngtest' under Cygwin.  Worked
around it by running

   netcat -l -p 8989 172.29.88.18 </dev/random

on the Windows side and

   ncat 172.29.88.10 8989 | rngtest -t 10

on the Linux machine.  Output looks like

rngtest: FIPS tests speed: (min=389.946; avg=74898.778; max=94811.893)Kibits/s
rngtest: Program run time: 60032020 microseconds
rngtest: bits received from input: 3088523264
rngtest: FIPS 140-2 successes: 154295
rngtest: FIPS 140-2 failures: 131
rngtest: FIPS 140-2(2001-10-10) Monobit: 17
rngtest: FIPS 140-2(2001-10-10) Poker: 15
rngtest: FIPS 140-2(2001-10-10) Runs: 53
rngtest: FIPS 140-2(2001-10-10) Long run: 47
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=393.292; avg=188386.332; max=887784.091)Kibits/s
rngtest: FIPS tests speed: (min=389.946; avg=74949.192; max=94811.893)Kibits/s
rngtest: Program run time: 69528238 microseconds

which I think would qualify as "not great."
Is similar to what I see when running

   rngtest -t 10 /dev/urandom

on Linux.

My guess is that the /dev/random driver needs an
adjustment to block when the MS crypto function
calls indicate a lack of available entropy
--assuming that the MS libraries support
entropy qualification of some kind.

I don't subscribe to the list (though I do
look at the archives), so please CC me
on any requests for my input.

Regards


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple