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 16:31:59 +0200 [thread overview]
Message-ID: <dleftj4ksa3cf4.fsf%l.stelmach@samsung.com> (raw)
In-Reply-To: <2041475.ybOAuNAZB8@tauon.chronox.de> (Stephan Mueller's message of "Wed, 20 May 2020 13:53:04 +0200")
[-- Attachment #1: Type: text/plain, Size: 3719 bytes --]
It was <2020-05-20 śro 13:53>, when Stephan Mueller wrote:
> Am Mittwoch, 20. Mai 2020, 12:44:33 CEST schrieb Lukasz Stelmach:
>> 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.
[...]
>>> 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.
Of course, this makes sense.
>>> 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.
Done. I will do some reaserch on iproc-rng200 and I will send v3 with
the altered commit message.
Thank you *very* much for your patience.
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
next prev parent reply other threads:[~2020-05-20 14:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200514190737eucas1p18ccdddb185ea7611683a6859e17bc721@eucas1p1.samsung.com>
2020-05-14 19:07 ` [PATCH 0/2] Set the quality value for two HW RNGs Łukasz Stelmach
[not found] ` <CGME20200514190738eucas1p2695c0d8af064ee702209ca03696ef438@eucas1p2.samsung.com>
2020-05-14 19:07 ` [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value Łukasz Stelmach
2020-05-14 20:20 ` Stephan Mueller
[not found] ` <CGME20200514221852eucas1p2bea169d0b4467b0ec9e195c6ac58a08a@eucas1p2.samsung.com>
2020-05-14 22:18 ` Lukasz Stelmach
2020-05-15 8:32 ` Stephan Mueller
[not found] ` <CGME20200515090647eucas1p21018edfd835730c9a68dcb186349ee74@eucas1p2.samsung.com>
2020-05-15 9:06 ` Lukasz Stelmach
[not found] ` <CGME20200515090158eucas1p1b653fc50f1ad4f0f6c92525ab3188d45@eucas1p1.samsung.com>
2020-05-15 9:01 ` Lukasz Stelmach
2020-05-15 9:10 ` Stephan Mueller
[not found] ` <CGME20200515110002eucas1p136759396d9b61f214d1f14856c009501@eucas1p1.samsung.com>
2020-05-15 10:59 ` Lukasz Stelmach
[not found] ` <CGME20200514190740eucas1p293129b2ef3ba706652a9327e55db9649@eucas1p2.samsung.com>
2020-05-14 19:07 ` [PATCH 2/2] hwrng: exynos " Łukasz Stelmach
2020-05-14 20:20 ` Stephan Mueller
[not found] ` <CGME20200519212617eucas1p1b6e7af0ecb894896b165601fafd6abe8@eucas1p1.samsung.com>
2020-05-19 21:25 ` [PATCH v2 0/2] Set the quality value for two HW RNGs Łukasz Stelmach
[not found] ` <CGME20200519212619eucas1p22fa5d3db2521096dc4b79f6e53016d17@eucas1p2.samsung.com>
2020-05-19 21:25 ` [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value Łukasz Stelmach
2020-05-20 6:23 ` Stephan Mueller
[not found] ` <CGME20200520091043eucas1p15ecae108007382a95b01e42241cc7a26@eucas1p1.samsung.com>
2020-05-20 9:10 ` Lukasz Stelmach
2020-05-20 9:18 ` Stephan Mueller
[not found] ` <CGME20200520104448eucas1p122e9a8ed84d5276a1b796e10ef5e1964@eucas1p1.samsung.com>
2020-05-20 10:44 ` Lukasz Stelmach
2020-05-20 11:53 ` Stephan Mueller
2020-05-20 12:00 ` Krzysztof Kozlowski
2020-05-20 12:11 ` Stephan Mueller
[not found] ` <CGME20200520143211eucas1p21bd93be5c62726aa715db05bb6e7119b@eucas1p2.samsung.com>
2020-05-20 14:31 ` Lukasz Stelmach [this message]
2020-05-20 8:18 ` Kamil Konieczny
2020-05-21 11:00 ` Stefan Wahren
[not found] ` <CGME20200521191415eucas1p2d112a86171b23dcf255e7da53a56f4f3@eucas1p2.samsung.com>
2020-05-21 19:14 ` Lukasz Stelmach
2020-05-23 18:46 ` Stephan Müller
[not found] ` <CGME20200519212621eucas1p13279db41d930b69e115972463c994a37@eucas1p1.samsung.com>
2020-05-19 21:25 ` [PATCH v2 2/2] hwrng: exynos " Łukasz Stelmach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dleftj4ksa3cf4.fsf%l.stelmach@samsung.com \
--to=l.stelmach@samsung.com \
--cc=arnd@arndb.de \
--cc=b.zolnierkie@samsung.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=elfring@users.sourceforge.net \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mbrugger@suse.com \
--cc=mpm@selenic.com \
--cc=rjui@broadcom.com \
--cc=sbranden@broadcom.com \
--cc=smueller@chronox.de \
--cc=wahrenst@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).