Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?

2021-04-16 Thread Bala Duvvuri via openssl-users
 Thank you for all the help, got this working.

Thanks
Bala
 On Thursday, 15 April, 2021, 04:02:10 am IST, Dr Paul Dale 
 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 = _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 
 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 
 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 

Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?

2021-04-14 Thread Dr Paul Dale

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 = _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 
 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 
  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 

Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?

2021-04-14 Thread Dr Paul Dale
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 
 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






Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?

2021-04-14 Thread Bala Duvvuri via openssl-users
 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 
 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 
 
   

Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?

2021-03-24 Thread Dr Paul Dale
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 3.0 - providing entropy to EVP_RAND ?

2021-03-24 Thread Bala Duvvuri via openssl-users
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