OpenSSL 3.0 - providing entropy to EVP_RAND ?

Dr Paul Dale pauli at openssl.org
Wed Apr 14 22:31:43 UTC 2021


Comments inline.

Pauli

On 15/4/21 12:09 am, Bala Duvvuri wrote:
> HI Paul,
>
> Thanks a lot for your response, thank you for pointing to 
> /providers/implementations/rands/test_rng.c and the code to run NIST test.
>
> Still finding it a bit difficult to wrap around these new APIs
>
> In the old implementation using OpenSSL 1.1.1, to generate random numbers:
>
> a> we have set the callback for custom entropy (using 
> RAND_DRBG_set_callbacks) for the RAND_DRBG_get0_master() DRBG instance 
> (DRBG defaulted to CTR mode)
> b> Also we have set the personalization string using 
> RAND_DRBG_instantiate and the reseed interval to 1 using 
> RAND_DRBG_set_reseed_interval for both master and public/private DRBG
> c> RAND_bytes is used to avail random numbers.
>
> ""In summary, we want to use the CTR_DRBG implementation and provide 
> our custom entropy/nonce from hardware""
>
> I am not sure if my understanding is clear, can you please let me know 
> this basic question how to go about this in OpenSSL 3.0?
>
> 1>Will I be able to use the built in DRBG and set a new custom 
> provider for the built in DRBG as parent?

Yes, exactly.  This is what I've been saying.


> 2> OR, is this the approach I need to follow
>
> rand = EVP_RAND_fetch(NULL, "CTR-DRBG", NULL);
>
> Can you let me know how can I link this "rand" to new parent that I 
> setup ?

You can't link DRBG's to parents after creation.  This code will use the 
OpenSSL built in entropy source and you won't be able to change it.

>
> 3> >> The built in DRBG's don't need the nonce, they will act as per 
> SP800-90Ar1 section 9.1 with a nonce available from their parent.
> /providers/implementations/rands/seed_src.c is the OpenSSL seed source 
> and it doesn't supply nonces.
>
> So does the built in DRBG need a nonce as above statements are 
> contradictory?

It can accept a nonce.  However, if one isn't provided it uses a random 
once grabbed from it's parent via the generate call.  The latter path is 
easier.


> 4> Also, where is the drbg_data defined/looked up in this case for the 
> test data vectors
>
> 0 acvp_test.c 1341 const struct drbg_st *tst = &drbg_data[id];
> 1 acvp_test.c 1468 ADD_ALL_TESTS(drbg_test, OSSL_NELEM(drbg_data));

Try:

    grep drbg_data test/*



> Thanks
> Bala
>
> On Wednesday, 14 April, 2021, 05:02:22 pm IST, Dr Paul Dale 
> <pauli at openssl.org> wrote:
>
>
> For setting up a parent for a DRBG, look at 
> /providers/implementations/rands/test_rng.c which produces seed 
> material (test_rng_generate) and nonces (test_rng_nonce).  The built 
> in DRBG's don't need the nonce, they will act as per SP800-90Ar1 
> section 9.1 with a nonce available from their parent. 
> /providers/implementations/rands/seed_src.c is the OpenSSL seed source 
> and it doesn't supply nonces.
>
> For the CAVS tests, look at test/acvp_test.c or test/evp_test.c which 
> both include code to run NISTs tests.
>
>
> Pauli
>
> On 14/4/21 8:47 pm, Bala Duvvuri wrote:
> 1> >>The best way to do this, is to create a provider which acts as a 
> seed source and to then use this as the parent of the primary DRBG. 
> See, for example, test/testutil/fakerandom.c for how to do this. The 
> key is to set up the seed source before the RNG subsystem is first used.
>
> In our case we provide the entropy and nonce from hardware sources (as 
> its on embedded platform) as requested by DRBG in older version.
> Now, if we setup a custom provider and use it as parent of the primary 
> DRBG, its not clear how the entropy and nonce from this provider will 
> be accessed, which API is invoked for the entropy/nonce consumption 
> (any specific callbacks set)? Can you please explain the steps or 
> example of the usage?
>
> 2> Also, we need set DRBG for CAVS test (Input: EntropyInput, Nonce, 
> PersonalizationString, AdditionalInput, EntropyInputPR, 
> AdditionalInput, EntropyInputPR), with OpenSSL 1.1.1, the below steps 
> were done:
>
> RAND_DRBG_new(NID_aes_256_ctr, RAND_DRBG_FLAGS, NULL);
> RAND_DRBG_set_callbacks // This will setup to return the provided 
> entropy and nonce inputs
> RAND_DRBG_instantiate // Pass personalization string.
> RAND_DRBG_generate
>
> Can you kindly let me know the equivalent steps with OpenSSL 3.0?
>
>
> Thank you for your help in this.
>
> Thanks
> Bala
>
> On Wednesday, 24 March, 2021, 11:56:18 am IST, Dr Paul Dale 
> <pauli at openssl.org> <mailto:pauli at openssl.org> wrote:
>
>
> RAND_add() forces a reseed to the DRBGs and uses the passed material 
> (not as entropy but as additional input).
>
> EVP_RAND_reseed() is a more direct interface but remember that the 
> built in DRBGs are free to ignore what the user claims is /entropy/. 
> History has shown us time and again that /entropy/ is often anything but.
>
> The *best* way to do this, is to create a provider which acts as a 
> seed source and to then use this as the parent of the primary DRBG.  
> See, for example, test/testutil/fakerandom.c for how to do this.  The 
> key is to set up the seed source before the RNG subsystem is first used.
>
> If you simply want to replace the built-in DRBGs with a real random 
> source, create a provider and set the appropriate environment/config 
> variables.
>
>
> Pauli
>
>
> On 24/3/21 4:14 pm, Bala Duvvuri via openssl-users wrote:
>> Hi All,In OpenSSL 1.1.1 version, we were using RAND_DRBG for random number generation.Using "RAND_DRBG_set_callbacks", we were able to call into our custom API for entropy and nonce generation.How can this be achieved with EVP_RAND implementation i.e. does it allow entropy to be provided? ThanksBala
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210415/88989c3b/attachment-0001.html>


More information about the openssl-users mailing list