linux-kernel - Re: [PATCH v2 1/2] hwrng: iproc-rng200

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2041475.ybOAuNAZB8@tauon.chronox.de>
Date:   Wed, 20 May 2020 13:53:04 +0200
From:   Stephan Mueller <smueller@...onox.de>
To:     Lukasz Stelmach <l.stelmach@...sung.com>
Cc:     Matt Mackall <mpm@...enic.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        bcm-kernel-feedback-list@...adcom.com,
        Kukjin Kim <kgene@...nel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Markus Elfring <elfring@...rs.sourceforge.net>,
        Matthias Brugger <mbrugger@...e.com>,
        Stefan Wahren <wahrenst@....net>, linux-crypto@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-samsung-soc@...r.kernel.org,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value

Am Mittwoch, 20. Mai 2020, 12:44:33 CEST schrieb Lukasz Stelmach:

Hi Lukasz,

> 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]

The hw_random framework only makes these hardware RNG accessible for in-kernel 
as well as user space use.
> 
> > 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.

The quality field is used by add_hwgenerator_randomness to increase the Linux 
RNG entropy estimator accordingly. This is the issue.

And giving an entropy rate based on post-processed data is meaningless.

The concern is, for example, that you use a DRBG that you seeded with, say, a 
zero buffer. You get perfect random data from it that no statistical test can 
disprove. Yet we know this data stream has zero entropy. Thus, we need to get 
to the source and assess its entropy.

> 
> > 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].

So you are saying that the output for the exynos-trng is straight from a ring 
oscillator without any post-processing of any kind?

If this is the case, I would like to suggest you add that statement to the git 
commit message with that reference. If so, then I would withdraw my objection.

> 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/dri
> vers/char/hw_random/exynos-trng.c?h=v5.6#n100
> 
> Kind regards,


Ciao
Stephan