Re: [PATCH 2/2] ath9k: export HW random number generator

[Stephan Mueller <smueller@chronox.de>]

Am Montag, 27. Juli 2015, 12:45:29 schrieb Oleksij Rempel:

Hi Oleksij,

>Am 27.07.2015 um 08:50 schrieb Pan, Miaoqing:
>>  “fips_run_rng_test”  is legacy code, recommend to disable 'FIPS 140-2'
>>  test if to use 'rngd-tools’.
>Ok, lets try simple compression. will it find enough pattern to do
>compression?
>Here what i get on my system:
>output from /dev/random
>-rw-rw-r-- 1 lex lex 2501678 Jul 27 12:01 random.out
>-rw-rw-r-- 1 lex lex 2512892 Jul 27 12:01 random.out.bz2
>
>after compression we got bigger file. i would expect it since we need to
>store bzip header somewhere.
>
>output from /dev/hwrng
>-rw-rw-r-- 1 lex lex 2564096 Jul 27 11:36 hwrng.out
>-rw-rw-r-- 1 lex lex 2468394 Jul 27 11:36 hwrng.out.bz2
>
>Do i understand it correctly, in case of hwrng bzip was able to find
>enough pattern to compressed the data? Even with format overhead?
>
>I'm no an expert, help of an expert would be welcome, added some more
>people to CC

This one does not look good for a claim that the RNG produces white noise. An 
RNG that is wired up to /dev/hwrng should produce white noise. Either by 
having an appropriate noise source or by conditioning the output of the noise 
source.

When conditioning the output, you have to be careful about the entropy claim. 
For example, you cannot state that the data stream from your noise source has 
close to one bit of entropy for each obtained bit. Thus, the conditioner must 
ensure that the data from the noise source is collected and its entropy is 
maintained and accumulated.

However, the hwrandom framework does not provide any conditioning logic. And I 
would say that such conditioner logic should not reside in a driver either. I 
would say that the discussed RNG does not seem fit for hooking it up with the 
hwrandom framework.

Ciao
Stephan