Testing random number generators


Geoffrey LE GOURRIEREC <geoffrey.legourrierec@...>
 

Hi all,

I realized recently that no random number generation API
test framework was available in Zephyr (apart from a very simple test
in tests/kernel/common/src/rand32.c).
I realize hardware number generators differ in expected "quality"
and that such a framework should allow tuning expected results,
like the generators' guaranteed period, for instance.

I took a look recently at the ENT program (http://www.fourmilab.ch/random/),
which performs a battery of tests on streams of bytes, and
provides global metrics at the end of the tests (correlation, mean value...).

This is only a suggestion, but we could write a simple generic framework using
the UART serial line to run the test with ENT running on the host computer.
I find ENT to be simple to use, and besides, its byte-level granulatity matches
the API exposed by random.h. I don't have extensive experience with hardware
number generators and therefore am probably unaware of potential issues
regarding the efforts to make generic test metrics (lack of hardware documentation
comes to my mind).

Any ideas or critics are welcome.

Regards,

--
Geoffrey


Kumar Gala
 

On Mar 13, 2017, at 11:10 AM, Geoffrey LE GOURRIEREC <geoffrey.legourrierec@smile.fr> wrote:

Hi all,

I realized recently that no random number generation API
test framework was available in Zephyr (apart from a very simple test
in tests/kernel/common/src/rand32.c).
I realize hardware number generators differ in expected "quality"
and that such a framework should allow tuning expected results,
like the generators' guaranteed period, for instance.

I took a look recently at the ENT program (http://www.fourmilab.ch/random/),
which performs a battery of tests on streams of bytes, and
provides global metrics at the end of the tests (correlation, mean value...).

This is only a suggestion, but we could write a simple generic framework using
the UART serial line to run the test with ENT running on the host computer.
I find ENT to be simple to use, and besides, its byte-level granulatity matches
the API exposed by random.h. I don't have extensive experience with hardware
number generators and therefore am probably unaware of potential issues
regarding the efforts to make generic test metrics (lack of hardware documentation
comes to my mind).

Any ideas or critics are welcome.

Regards,
Seems like a pretty worth while thing to work on. We have some support for a few random number generators in the tree already (drivers/random). So I think a test app as you described shouldn’t be too difficult to work up and writeup how to connect with ENT.

- k


Daniel Thompson <daniel.thompson@...>
 

On 15/03/17 13:37, Kumar Gala wrote:
On Mar 13, 2017, at 11:10 AM, Geoffrey LE GOURRIEREC <geoffrey.legourrierec@smile.fr> wrote:

Hi all,

I realized recently that no random number generation API
test framework was available in Zephyr (apart from a very simple test
in tests/kernel/common/src/rand32.c).
I realize hardware number generators differ in expected "quality"
and that such a framework should allow tuning expected results,
like the generators' guaranteed period, for instance.

I took a look recently at the ENT program (http://www.fourmilab.ch/random/),
which performs a battery of tests on streams of bytes, and
provides global metrics at the end of the tests (correlation, mean value...).

This is only a suggestion, but we could write a simple generic framework using
the UART serial line to run the test with ENT running on the host computer.
I find ENT to be simple to use, and besides, its byte-level granulatity matches
the API exposed by random.h. I don't have extensive experience with hardware
number generators and therefore am probably unaware of potential issues
regarding the efforts to make generic test metrics (lack of hardware documentation
comes to my mind).

Any ideas or critics are welcome.

Regards,
Seems like a pretty worth while thing to work on. We have some
support for a few random number generators in the tree already
(drivers/random). So I think a test app as you described shouldn’t
be too difficult to work up and writeup how to connect with ENT.
Would be a great idea. Especially useful to bring to the surface RNGs that have been interfaced to the system without a whitening filter...


Daniel.