So, I've continued and assumed I can use the header files in the "fips-2.0" directory and added them to my code with: : #include <../fips-2.0/include/openssl/fips.h> #include <../fips-2.0/include/openssl/fips_rand.h> : All compile fine.
When executing the test using NID_sha1 as the DRBG type, then FIPS_drbg_instantiate() fails. I can see that the DRBG successfully got and freed entropy data from my hardware source. So I guess it must be the personalization information given as part of the instantiation which is wrong. The fips test application simply gives it 10 bytes from a static array but I am not sure what the length sould be. The documentation says: "If the personalisation string is of an invalid length for the DRBG mechanism a non-fatal error is returned". What does non-fatal error means? I assumed that the length must be 16 bytes (128 bits) since the NID_sha1 DRBG is 128 bit strong? It still fails. Any suggestions? (FIPS is enabled successfully) Leon Brits Senior Design Engineer > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Leon Brits > Sent: 14 May 2013 11:26 AM > To: [email protected] > Subject: RE: DRBGs questions > > Hi Stephen, > > Thanks for your reply. > > So I finished the code to create my own DRBGs, but on compile it fails to > find the required headers. From the test code on the internet it seems > that I need to include fips.h and/or fips_rand.h. Is this correct? > > These files are however not in the include directory created when I > installed the FIPS compiled OpenSSL (/usr/local/ssl/include/openssl for > Ubuntu). I found it in /usr/local/ssl/fips-2.0/include/openssl which is > not in the system include path returned by my build system's pkg-config > query for OpenSSL. Is it ok to just manually point to those two files or > should the application rather compile against the headers files found > under the 'fips-2.0/include/openssl' directory? > > Sorry if this is trivial question, but I just do not want to compromise > the FIPSness of my setup. > > Regards, > Leon Brits > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] > > On Behalf Of Dr. Stephen Henson > > Sent: 13 May 2013 06:53 PM > > To: [email protected] > > Subject: Re: DRBGs questions > > > > On Mon, May 13, 2013, Leon Brits wrote: > > > > > Hi all, > > > > > > We have a chip (a RNG) which generates randomness at 250kbps and > > > would > > like this to seed a customer selected type of DRBG so that the > > customer can get randomness which is FIPS certified. > > > I've read the FIPS user guide to implement a structure to switch > > > between > > the four types of DRBGs based on the customer selection. > > > I've setup the getEntropy() callback functions per DRBG type context > > > to > > read entropy data from 'n file pointer at which the RNG data is > available. > > I will instantiate() and uninstantiate() a DRBGs based on the customer > > selection during initialization of my library. > > > So my questions are: > > > > > > 1. How does the application now access the randomness (normal > RAND_* > > commands)? > > > > > > > > > > If you set up the default DRBG to use your entropy gathering technique > > then calls to RAND_* will use it. > > > > > 2. In my case, what is the purpose of FIPS_drbg_reseed() and > > FIPS_drbg_generate()? Should I provide a customer interface to them? > > Will they need it? > > > > These apply to the separate instantiations of a DRBG. If you just use > > the default DRBG then the calls are made automatically. If you want an > > independent DRBG then you have to use those calls to generate random > data. > > > > Steve. > > -- > > Dr Stephen N. Henson. OpenSSL project core developer. > > Commercial tech support now available see: http://www.openssl.org > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > Development Mailing List [email protected] > > Automated List Manager [email protected] > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
