[PATCH 4/4] crypto/fsl: add RNG support
Heinrich Schuchardt
xypron.glpk at gmx.de
Thu Jun 4 17:45:02 CEST 2020
On 04.06.20 15:20, Michael Walle wrote:
> Am 2020-06-04 14:58, schrieb Heinrich Schuchardt:
>> On 04.06.20 14:52, Michael Walle wrote:
>>> Am 2020-06-04 14:26, schrieb Heinrich Schuchardt:
>>>> On 04.06.20 10:05, Horia Geantă wrote:
>>>>> On 6/4/2020 5:31 AM, Heinrich Schuchardt wrote:
>>>
>>>>> From what I see, driver added by Michael is using the PRNG / DRBG
>>>>> and not the TRNG. Is this acceptable?
>>>>>
>>>>
>>>> If it is only PRNG, this is not what we look for. If a PRNG/DRBG is
>>>> used
>>>> to ameliorate the raw entropy stream like Linux does for the
>>>> /dev/random
>>>> device this is fine. We need something non-deterministic.
>>>
>>> What do you mean by "only PRNG"?
>>>
>>>>> -a PRNG / DRBG (SP800-90A compliant DRBG_Hash) - which is seeded
>>>>> from the TRNG
>>>
>>> So while it is a PRNG, it is non-deterministic because its seeded
>>> from the TRNG.
>>
>> If for every byte that your DM_RNG driver outputs at least one byte from
>> the TRNG is consumed, it is fine. Otherwise it is not what we are
>> looking for.
>
> And why is that? This should really be documented somewhere.
We want to provide raw entropy in the EFI_RNG_PROTOCOL. So this cannot
be a deterministic sequence of bytes where you only have to know the
current state of a PRNG to find the next byte.
As mentioned above you have a TRNG available. What is problematic about
providing its output?
Best regards
Heinrich
More information about the U-Boot
mailing list