Entropy Source for Openssl 3.8

[Dr Paul Dale]

The bottom line is that we support too many different platforms for us 
to attempt to validate all of the available entropy sources.

Technically it is possible.  Mechanically it's impractical.


If NIST would accept, e.g., cpujitter as an entropy source on all 
platforms, we would include it inside the FIPS boundary.  This isn't 
likely to happen and we're left with piecemeal sources.


Pauli


On 31/8/23 19:37, Martin Bonner via openssl-users wrote:
> It is possible for a FIPS approved implementation to use a FIPS approved
> entropy source, and then to incorporate additional entropy from a
> non-approved source via the "personalization string" and "additional input"
> arguments to the DRBG.  Making that available from the FIPS provider would
> be nice (but would need revalidating of course).
>
> Martin Bonner
>
> ----------------------------------------------------------------------
>> *From:*openssl-users <openssl-users-bounces at openssl.org> *On Behalf Of
>> *Dr Paul Dale
>> The code there is somewhat confused by the way the FIPS provider
>> gathers it's entropy.
>> It doesn't access the seed source directly, instead it has call-backs
>> into libcrypto to request entropy.
>> The critical function is ossl_rand_get_entropy in
>> crypto/rand/prov_seed.c.? This function satisfies the FIPS provider's
>> request for entropy and it doesn't access the seed source specified,
>> instead it goes directly to OpenSSL's internal entropy gathering.
>>
>> So, no there isn't a way to do what you want.
>>
>> It wasn't intended to operate this way and I'll look at producing a fix.
>>
>> Pauli
> Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.