Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value

From: Lukasz Stelmach <l.stelmach@samsung.com>
To: Stephan Mueller <smueller@chronox.de>
Cc: Matt Mackall <mpm@selenic.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ray Jui <rjui@broadcom.com>,
	Scott Branden <sbranden@broadcom.com>,
	bcm-kernel-feedback-list@broadcom.com,
	Kukjin Kim <kgene@kernel.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Markus Elfring <elfring@users.sourceforge.net>,
	Matthias Brugger <mbrugger@suse.com>,
	Stefan Wahren <wahrenst@gmx.net>,
	linux-crypto@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value
Date: Wed, 20 May 2020 12:44:33 +0200	[thread overview]
Message-ID: <dleftjh7wa3my6.fsf%l.stelmach@samsung.com> (raw)
In-Reply-To: <15745285.MnsZKaK4VV@tauon.chronox.de> (Stephan Mueller's message of "Wed, 20 May 2020 11:18:32 +0200")

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

It was <2020-05-20 śro 11:18>, when Stephan Mueller wrote:
> Am Mittwoch, 20. Mai 2020, 11:10:32 CEST schrieb Lukasz Stelmach:
>> It was <2020-05-20 śro 08:23>, when Stephan Mueller wrote:
>>> Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach:
>>>> The value was estimaded with ea_iid[1] using on 10485760 bytes read
>>>> from the RNG via /dev/hwrng. The min-entropy value calculated using
>>>> the most common value estimate (NIST SP 800-90P[2], section 6.3.1)
>>>> was 7.964464.
>>> 
>>> I am sorry, but I think I did not make myself clear: testing random
>>> numbers post-processing with the statistical tools does NOT give any
>>> idea about the entropy rate. Thus, all that was calculated is the
>>> proper implementation of the post-processing operation and not the
>>> actual noise source.
>>> 
>>> What needs to happen is that we need access to raw, unconditioned
>>> data from the noise source that is analyzed with the statistical
>>> methods.
>> 
>> I did understand you and I assure you the data I tested were obtained
>> directly from RNGs. As I pointed before[1], that is how /dev/hwrng
>> works[2].
>
> I understand that /dev/hwrng pulls the data straight from the
> hardware. But the data from the hardware usually is not obtained
> straight from the noise source.
>
> Typically you have a noise source (e.g. a ring oscillator) whose data
> is digitized then fed into a compression function like an LFSR or a
> hash. Then a cryptographic operation like a CBC-MAC, hash or even a
> DRBG is applied to that data when the caller wants to have random
> numbers.

I do understand your point (but not entirely, see below). [opinion]
However, I am really not sure that this is a "typical" setting for a HW
RNG, at least not among RNGs supported by Linux. Otherwise there would
be no hw_random framework and no rngd(8) which are suppsed to
post-process imperfectly random data from HW. [/opinion]

> In order to estimate entropy, we need the raw unconditioned data from
> the, say, ring oscillator and not from the (cryptographic) output
> operation.

Can you tell, why it matters in this case? If I understand correctly,
the quality field describes not the randomness created by the noise
generator but the one delivered by the driver to other software
components.

> That said, the illustrated example is typical for hardware RNGs. Yet
> it is never guaranteed to work that way. Thus, if you can point to
> architecture documentation of your specific hardware RNGs showing that
> the data read from the hardware is pure unconditioned noise data, then
> I have no objections to the patch.

I can tell for sure that this is the case for exynos-trng[1]. There is a
post-processor which I have forgotten about since writing the driver,
because from the very beginning I didn't intend to use it. I knew there
is the software framework for post-processing and simply didn't bother.

With regards to iproc-rng200 I cannot be sure.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/hw_random/exynos-trng.c?h=v5.6#n100

Kind regards,
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]