Hello Chen-Yu,
On 2024-07-17 04:58, Chen-Yu Tsai wrote:
On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@xxxxxxxxxxxxxx>
wrote:
On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote:
> On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
> > rngtest: FIPS 140-2(2001-10-10) Long run: 0
>
> I don't know if it means something, but I noticed that I have
> ``Long run: 0`` with all my poor results,
> while Chen-Yu had ``Long run: 1``.
>
> Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
> very poor result (100% failure):
> https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6rB2S7jg+dnoX8hAoWg@xxxxxxxxxxxxxx/
The conclusions I draw from that rather ugly situation are:
- The hwrng should not be enabled by default, but it should by done
for each board on which it is known to work well.
- RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be
defined in DT for each board:
* introduce new 'rochchip,rng-sample-count' property
* read 'quality' property already used for timeriomem_rng
I will prepare a follow-up patch taking those conclusions into
account.
Just for completeness, here my test result on the NanoPi R5C:
root@OpenWrt:~# cat /dev/hwrng | rngtest -c 1000
rngtest 6.15
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: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 875
rngtest: FIPS 140-2 failures: 125
rngtest: FIPS 140-2(2001-10-10) Monobit: 123
rngtest: FIPS 140-2(2001-10-10) Poker: 5
rngtest: FIPS 140-2(2001-10-10) Runs: 4
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=85.171; avg=141.102;
max=4882812.500)Kibits/s
rngtest: FIPS tests speed: (min=17.809; avg=19.494;
max=60.169)Mibits/s
rngtest: Program run time: 139628605 microseconds
I doubt this is per-board. The RNG is inside the SoC, so it
could be a chip quality thing.
Totally agreed. I see no way how a board design could affect the
HWRNGs built into Rockchip SoCs. I even checked the RK3399 and
RK3566 Hardware Design Guides to be extra sure.
On the RK3399 we also saw wildly varying results.
In my opinion, that qualifies the RK3399's HWRNG as unsuitable for
general use. Having a HWRNG that fails to pass the tests on _some_
units is simply not acceptable from the security standpoint.
