All of lore.kernel.org
 help / color / mirror / Atom feed
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 1/2] hwrng: iproc-rng200 - Set the quality value
Date: Fri, 15 May 2020 00:18:41 +0200	[thread overview]
Message-ID: <dleftjtv0i88ji.fsf%l.stelmach@samsung.com> (raw)
In-Reply-To: <4493123.C11H8YMYNy@tauon.chronox.de> (Stephan Mueller's message of "Thu, 14 May 2020 22:20:26 +0200")

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

It was <2020-05-14 czw 22:20>, when Stephan Mueller wrote:
> Am Donnerstag, 14. Mai 2020, 21:07:33 CEST schrieb Łukasz Stelmach:
>
> Hi Łukasz,
>
>> The value has been estimaded by obtainig 1024 chunks of data 128 bytes
>> (1024 bits) each from the generator and finding chunk with minimal
>> entropy using the ent(1) tool. The value was 6.327820 bits of entropy
>> in each 8 bits of data.
>
> I am not sure we should use the ent tool to define the entropy
> level. Ent seems to use a very coarse entropy estimation.
>
> I would feel more comfortable when using other measures like SP800-90B
> which even provides a tool for the analysis.
>
> I understand that entropy estimates, well, are estimates. But the ent
> data is commonly not very conservative.
>
> [1] https://github.com/usnistgov/SP800-90B_EntropyAssessment

Thank you for pointing this out.

I am running tests using SP800-90B tools and the first issue I can see
is the warning that samples contain less than 1e6 bytes of data. I know
little about maths behind random number generators, but I have noticed
that the bigger chunk of data from an RNG I feed into either ent or ea_iid
the higher entropy they report. That is why I divided the data into 1024
bit chunks in the first place. To get worse results. With ea_iid they
get even worse (128 bytes of random data)


    Calculating baseline statistics...
    H_original: 4.107376
    H_bitstring: 0.795122
    min(H_original, 8 X H_bitstring): 4.107376

but I don't know how much I can trust it, when I get such warning

    *** Warning: data contains less than 1000000 samples ***

ea_non_iid refuses to run tests with less than 4096 bytes of input.

I may suspect that lack of any warnings from ent doesn't make its
results any more reliable.

Anyway. I collected 1024 files 1024 bits each once again and ran the
following tests

    for f in exynos-trng/random*; do ./ea_iid "$f" | grep ^min; done |  sort | head -1
    for f in rng200/random*; do ./ea_iid "$f" | grep ^min; done | sort | head -1

For both RNGs I got the same

    min(H_original, 8 X H_bitstring): 3.393082

which, if I understand correctly, means I should set quality to no more
than 434. Do you think 400 is OK?

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

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

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


[-- Attachment #1.1: Type: text/plain, Size: 2351 bytes --]

It was <2020-05-14 czw 22:20>, when Stephan Mueller wrote:
> Am Donnerstag, 14. Mai 2020, 21:07:33 CEST schrieb Łukasz Stelmach:
>
> Hi Łukasz,
>
>> The value has been estimaded by obtainig 1024 chunks of data 128 bytes
>> (1024 bits) each from the generator and finding chunk with minimal
>> entropy using the ent(1) tool. The value was 6.327820 bits of entropy
>> in each 8 bits of data.
>
> I am not sure we should use the ent tool to define the entropy
> level. Ent seems to use a very coarse entropy estimation.
>
> I would feel more comfortable when using other measures like SP800-90B
> which even provides a tool for the analysis.
>
> I understand that entropy estimates, well, are estimates. But the ent
> data is commonly not very conservative.
>
> [1] https://github.com/usnistgov/SP800-90B_EntropyAssessment

Thank you for pointing this out.

I am running tests using SP800-90B tools and the first issue I can see
is the warning that samples contain less than 1e6 bytes of data. I know
little about maths behind random number generators, but I have noticed
that the bigger chunk of data from an RNG I feed into either ent or ea_iid
the higher entropy they report. That is why I divided the data into 1024
bit chunks in the first place. To get worse results. With ea_iid they
get even worse (128 bytes of random data)


    Calculating baseline statistics...
    H_original: 4.107376
    H_bitstring: 0.795122
    min(H_original, 8 X H_bitstring): 4.107376

but I don't know how much I can trust it, when I get such warning

    *** Warning: data contains less than 1000000 samples ***

ea_non_iid refuses to run tests with less than 4096 bytes of input.

I may suspect that lack of any warnings from ent doesn't make its
results any more reliable.

Anyway. I collected 1024 files 1024 bits each once again and ran the
following tests

    for f in exynos-trng/random*; do ./ea_iid "$f" | grep ^min; done |  sort | head -1
    for f in rng200/random*; do ./ea_iid "$f" | grep ^min; done | sort | head -1

For both RNGs I got the same

    min(H_original, 8 X H_bitstring): 3.393082

which, if I understand correctly, means I should set quality to no more
than 434. Do you think 400 is OK?

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

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

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2020-05-14 22:19 UTC|newest]

Thread overview: 52+ 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
2020-05-14 19:07   ` Ł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 19:07       ` Łukasz Stelmach
2020-05-14 20:20       ` Stephan Mueller
2020-05-14 20:20         ` Stephan Mueller
     [not found]         ` <CGME20200514221852eucas1p2bea169d0b4467b0ec9e195c6ac58a08a@eucas1p2.samsung.com>
2020-05-14 22:18           ` Lukasz Stelmach [this message]
2020-05-14 22:18             ` Lukasz Stelmach
2020-05-15  8:32             ` Stephan Mueller
2020-05-15  8:32               ` Stephan Mueller
     [not found]               ` <CGME20200515090647eucas1p21018edfd835730c9a68dcb186349ee74@eucas1p2.samsung.com>
2020-05-15  9:06                 ` Lukasz Stelmach
2020-05-15  9:06                   ` Lukasz Stelmach
     [not found]             ` <CGME20200515090158eucas1p1b653fc50f1ad4f0f6c92525ab3188d45@eucas1p1.samsung.com>
2020-05-15  9:01               ` Lukasz Stelmach
2020-05-15  9:01                 ` Lukasz Stelmach
2020-05-15  9:10                 ` Stephan Mueller
2020-05-15  9:10                   ` Stephan Mueller
     [not found]                   ` <CGME20200515110002eucas1p136759396d9b61f214d1f14856c009501@eucas1p1.samsung.com>
2020-05-15 10:59                     ` Lukasz Stelmach
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 19:07       ` Łukasz Stelmach
2020-05-14 20:20       ` Stephan Mueller
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
2020-05-19 21:25       ` Ł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-19 21:25           ` Łukasz Stelmach
2020-05-20  6:23           ` Stephan Mueller
2020-05-20  6:23             ` Stephan Mueller
     [not found]             ` <CGME20200520091043eucas1p15ecae108007382a95b01e42241cc7a26@eucas1p1.samsung.com>
2020-05-20  9:10               ` Lukasz Stelmach
2020-05-20  9:10                 ` Lukasz Stelmach
2020-05-20  9:18                 ` Stephan Mueller
2020-05-20  9:18                   ` Stephan Mueller
     [not found]                   ` <CGME20200520104448eucas1p122e9a8ed84d5276a1b796e10ef5e1964@eucas1p1.samsung.com>
2020-05-20 10:44                     ` Lukasz Stelmach
2020-05-20 10:44                       ` Lukasz Stelmach
2020-05-20 11:53                       ` Stephan Mueller
2020-05-20 11:53                         ` Stephan Mueller
2020-05-20 12:00                         ` Krzysztof Kozlowski
2020-05-20 12:00                           ` Krzysztof Kozlowski
2020-05-20 12:11                           ` Stephan Mueller
2020-05-20 12:11                             ` Stephan Mueller
     [not found]                         ` <CGME20200520143211eucas1p21bd93be5c62726aa715db05bb6e7119b@eucas1p2.samsung.com>
2020-05-20 14:31                           ` Lukasz Stelmach
2020-05-20 14:31                             ` Lukasz Stelmach
2020-05-20  8:18           ` Kamil Konieczny
2020-05-20  8:18             ` Kamil Konieczny
2020-05-21 11:00           ` Stefan Wahren
2020-05-21 11:00             ` Stefan Wahren
     [not found]             ` <CGME20200521191415eucas1p2d112a86171b23dcf255e7da53a56f4f3@eucas1p2.samsung.com>
2020-05-21 19:14               ` Lukasz Stelmach
2020-05-21 19:14                 ` Lukasz Stelmach
2020-05-23 18:46                 ` Stephan Müller
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
2020-05-19 21:25           ` Ł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=dleftjtv0i88ji.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.