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@xxxxxxxxxxx> *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.
