linux-kernel - Re: [PATCH 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: <dleftjimgx8tc3.fsf%l.stelmach@samsung.com>
Date:   Fri, 15 May 2020 11:01:48 +0200
From:   Lukasz Stelmach <l.stelmach@...sung.com>
To:     Stephan Mueller <smueller@...onox.de>
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 1/2] hwrng: iproc-rng200 - Set the quality value

It was <2020-05-15 pią 00:18>, when Lukasz Stelmach wrote:
> 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

[...]

> 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

Oddly enough I've got the same number for other random sources on my x86

| Source       | ea_iid -i | ea_iid -c (h') |      ent |
|--------------+-----------+----------------+----------|
| /dev/random  |  3.393082 |       0.768654 | 6.300399 |
| /dev/urandom |  3.393082 |       0.759161 | 6.348562 |
| tpm-rng      |  3.393082 |       0.735722 | 6.323990 |
| exynos-trng  |  3.393082 |       0.687825 | 6.327820 |
| rng200       |  3.393082 |       0.740376 | 6.291959 |

I suspect 1024 bits is too little for ea_iid to give a meaningfull
result. BTW ent results also seem a little oddly low for crng. Any
thoughs?

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

Download attachment "signature.asc" of type "application/pgp-signature" (488 bytes)