OpenSSL 3.0 - providing entropy to EVP_RAND ?

[OpenSSL - User mailing list]

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?

Thanks
Bala

[Dr Paul Dale-2]

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? 

Thanks
Bala

[OpenSSL - User mailing list]

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 <[hidden email]> 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

[Dr Paul Dale-2]

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 [hidden email] 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

[Dr Paul Dale-2]

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 [hidden email] 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 [hidden email] 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

[OpenSSL - User mailing list]

Thank you for all the help, got this working.

Thanks
Bala

On Thursday, 15 April, 2021, 04:02:10 am IST, Dr Paul Dale <[hidden email]> wrote:

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 [hidden email] 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 [hidden email] 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