Openssl aes-256 ctr drbg
Hi, What is the Number of Bytes Returned by aes-256 ctr drbg ? Thanks, Nagarjun
Re: [openssl-users] FIPS: Any setup required for using a default DRBG ?
From: jonetsu jone...@teksavvy.com Date: 03/26/15 11:11 Is FIPS_mode_set(1) taking care of setting up a default DRBG ? Yes. It does. When using post_cb() from fips_test_suite.c in for instance the fips_hmac.c demo, with only but a FIPS_mode_set(1) call, it is reported that the four DRBGs are tested: DRBG AES-256-CTR DF, DRBG AES-256-CTR, DRBG SHA256 and DRBG HMAC-SHA256, amongst others. After FIPS_mode_set(1) is executed along with the POST tests, a call to RAND_pseudo_bytes() will not run the tests again. In this context, when do occur the DRBG continuous tests as shown in table 6b of the 2.0.9 Security Policy ? Is there a need to actually call FIPS_selftest() ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Question regarding lock of the master drbg during the fork
Hello, I have a question regarding the usage of the master DRBG during the fork operation. As far as I understand from the source code and articles, during the fork the library will perform the lock of the master DRBG to obtain the entropy for public and private DRBG. However, the library does not perform the check of the lock state itself and it is unclear for me, what will happen if the master DRBG is locked during the creation of the fork process. Additionally, what was the purpose of such complicated scheme for DRBGs except for NIST requirements? Is it possible to solve fork problem without implementing the chain of DRBGs? Can you please help with this? Articles: https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/ https://wiki.openssl.org/index.php/Random_fork-safety Here is the code from the rand_lib.c: rand_drbg_lock(drbg->parent); if (RAND_DRBG_generate(drbg->parent, buffer, bytes_needed, prediction_resistance, NULL, 0) != 0) bytes = bytes_needed; drbg->reseed_next_counter = tsan_load(>parent->reseed_prop_counter); rand_drbg_unlock(drbg->parent);
[openssl-users] OpenSSL DRBG in FIPS mode confusion.
Hi All, OpenSSL uses 256 bit AES-CTR DRBG as default DRBG in FIPS mode. I have question associated with this. 1. OpenSSL wiki says : Default DRBG is 256-bit CTR AES *using a derivation function* 2. Where as the document http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf mentions "no derivation function" in one place and in another sections mentions both *Section 4 Modes of Operation and Cryptographic Functionality* Random Number Generation;[SP 80090] DRBG5 Hash DRBG Symmetric key generationPrediction resistance HMAC DRBG, no reseed supported for all variations CTR DRBG (AES), no derivation function *Section 6 Selftest * DRBG KAT CTR_DRBG: AES, 256 bit with and without derivation function Please can any one let me know what is the default behavior? Is there any way to toggle between using and not using derivation function. Regards Jayalakshmi -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Drbg kat test data: Openssl-fips 2.0.16
Hi There is DRBG kat test data in fips_drbg_selftest.h. (Openssl-fips-2.0.16) Can anyone let me know, What is the source of this constant arrays. NIST link or any other source will be helpful? Regards Manish
[openssl-users] FIPS: Which DRBG ?
Hello, Following on the 'SP800-90 DRBG in OpenSSL FIPS 140 for SP800-90A?' topic, the OpenSSL source code does not seem to mention SP 800-90A. Only SP 800-90. So the certifications were made for SP 800-90, is that right ? Also, does it depend on the application to choose which DRBG and moreover, for regular FIPS uses, does it matter which DRBG is used since they are all approved ? One more question: is there a way for us to actually know/test which one id used by an application ? I currently am using a FIPS_post_set_callback() placed in FIPS_mode_set() - can this be useful to identify which DRBG is used ? Maybe FIPS_drbg_set_callbacks() could be more useful ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] FIPS: Any setup required for using a default DRBG ?
Hello, Is FIPS_mode_set(1) taking care of setting up a default DRBG ? Would a subsequent call to RAND_pseudo_bytes() for instance be using the default DRBG ( 256-bit CTR AES ?) There are quite a few DRBG-related FIPS methods described in the User Guide, and one that is called FIPS_get_default_drbg(). Does this have to be actually called ? I'm asking since I added in crypto/o_fips.c a FIPS_post_set_callback() in FIPS_set_mode() with a case switch on FIPS_TEST_DRBG (amongst others). SHA256, HMAC-SHA256, AES-128-CBC, AES-256-CTR amongst others are reported to be tested, although there's no sign of the FIPS_TEST_DRBG. Nor FIPS_TEST_CONTINUOUS for that matter. Wouldn't the DRBG be tested in a 'continuous' way before each use ? - thanks. Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS: Which DRBG ?
Hi, For the second question any DRBG that are approved in FIPS SP 800-90A are approved for any application. You can chose over tha Hash, HMAC or CTR DRBG equivalently. Best regards Q Gouchet Le 23 mars 2015 09:38, jonetsu jone...@teksavvy.com a écrit : Hello, Following on the 'SP800-90 DRBG in OpenSSL FIPS 140 for SP800-90A?' topic, the OpenSSL source code does not seem to mention SP 800-90A. Only SP 800-90. So the certifications were made for SP 800-90, is that right ? Also, does it depend on the application to choose which DRBG and moreover, for regular FIPS uses, does it matter which DRBG is used since they are all approved ? One more question: is there a way for us to actually know/test which one id used by an application ? I currently am using a FIPS_post_set_callback() placed in FIPS_mode_set() - can this be useful to identify which DRBG is used ? Maybe FIPS_drbg_set_callbacks() could be more useful ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: FIPS Mode and Default DRBG (OpenSSL 1.0.x and FIPS 2.0 Module)
On Sat, Jul 28, 2012, Jeffrey Walton wrote: Hi All, According to the FIPS 2.0 User Guide (Default DRBG, page 64): A special DRBG instance called the default DRBG is used to map the DRBG to the RAND interface. Unfortunately, the documentation (both the Security Policy and User Guide) does not appear to state the underlying generator. Which of the four SP800-90 generators are used as the default, and what is the stated security level of the underlying algorithm? The default DRBG is decided by the application and not the module. In the case of the OpenSSL application it is specified in rand_lib.c and via the OPENSSL_DRBG_DEFAULT_TYPE and OPENSSL_DRBG_DEFAULT_FLAGS defines to allow them to be overridden by local compilation options or at runtime. The default in there is 256 bit CTR AES using a derivation function. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
test vectors for CTR DRBG
Hello, I'm looking for the test vectors for CTR DRBG random number generator. I got test vectors from http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip which contains CTR_DRBG.rsp file. However, I'm looking for the following scenario which is not covered right now: [AES-128 no df] [PredictionResistance = False] [EntropyInputLen = 256] [NonceLen = 0] [PersonalizationStringLen = 0] [AdditionalInputLen = 0] Can anybody please provide such testing vectors? Thanks a lot! Jiri
[openssl-users] SP800-90 DRBG in OpenSSL FIPS 140 for SP800-90A?
At the moment OpenSSL FIPS validation supports ANSI X9.31 with AES128 for RNG, however it will be outdated in 2015. Another alternative RNG in OpenSSL FIPS is SP800-90 DRBG, however the new requirement is to use DRBG per SP800-90A. Are the DRBGs in SP800-90/OpenSSL-FIPS-2.0.9 the same as what SP800-90A requires? Otherwise how can OpenSSL 2.0 FIPS be used in any new validations? Thanks, xxiao ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: What is the underlying algorithm in RAND_bytes() function?
On Mon, May 12, 2014 at 03:00:23AM -0700, harika_n wrote: I am using RAND_bytes function to generate cryptographically secure random numbers. I want to know if it uses Hash based DRBG or HMAC based DRBG. If it uses Hash based DRBG what is the underlying hash function used? I looked at the source code and found that it uses some MD function but I could not find which MD it is using. Depending on what random generator engine is used. The default builtin one is a hash based DRBG. crypto/rand/rand_lcl.h ... the default MD is SHA1. Ciao, Marcus __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
DRBG algorithm and ReturnedBits
Hi,
If we check the DRBG specifications -
http://csrc.nist.gov/groups/STM/cavp/documents/drbg/DRBGVS.pdf
For cases with prediction resistance enabled, each trial consists of the
following functions called in sequence:
(1) instantiate drbg
(2) generate ReturnedBitsLen random bits, do not print
(3) generate ReturnedBitsLen random bits, print out
(4) uninstantiate
Also in fips_drbgvs.c
if (gen == 2)
{
OutputValue(ReturnedBits, randout, randoutlen,
out, 0);
FIPS_drbg_free(dctx);
dctx = NULL;
gen = 0;
}
What is reason to call the FIPS_drbg_generate twice?
Why do we need to call generate function twice?
thanks,
Bala
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
DRBG algorithm and ReturnedBits
Hi,
If we check the DRBG specifications -
http://csrc.nist.gov/groups/STM/cavp/documents/drbg/DRBGVS.pdf
For cases with prediction
resistance enabled, each trial consists of the following
functions called in sequence:
(1) instantiate drbg
(2)
generate ReturnedBitsLen random bits, do not print
(3) generate ReturnedBitsLen random bits, print
out
(4) uninstantiate
Also in fips_drbgvs.c
if (gen == 2)
{
OutputValue(ReturnedBits, randout,
randoutlen,
out, 0);
FIPS_drbg_free(dctx);
dctx = NULL;
gen = 0;
}
What is reason to call the FIPS_drbg_generate twice?
Why do we need to call generate function twice?
thanks,
Bala
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Question regarding lock of the master drbg during the fork
Сергей , We are aware that we do not handle the fork(2) system call perfectly. My advice would be to not hold a lock while calling fork(2). OpenSSL, as of 1.1.0, does hold per-process locks itself. The locking callbacks were present in 1.0.2 and before but are now obsolete. Even if it isn’t perfect, OpenSSL does attempt to reseed the DRBG chains when fork(2) is called. This is not designed to meet any of the NIST requirements. Rather it is to ensure that the parent and child processes have different random seed material. High quality random numbers are critical to security — they are the foundation upon which everything else is based. OpenSSL tries to not take any shortcuts here. The DRBG chains are part of the considered solution — the public and private DRBGs are distinct and a compromise of one shouldn’t impact the other; they are also per thread which shouldn’t negatively impact performance (by locking). Спасибо, Pauli (my Русский is very rusty) -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 28 Aug 2019, at 6:51 pm, Сергей Юнаковский wrote: > > Hello, > I have a question regarding the usage of the master DRBG during the fork > operation. As far as I understand from the source code and articles, during > the fork the library will perform the lock of the master DRBG to obtain the > entropy for public and private DRBG. > However, the library does not perform the check of the lock state itself and > it is unclear for me, what will happen if the master DRBG is locked during > the creation of the fork process. > > Additionally, what was the purpose of such complicated scheme for DRBGs > except for NIST requirements? Is it possible to solve fork problem without > implementing the chain of DRBGs? > > Can you please help with this? > > Articles: > https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html > <https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html> > http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/ > <http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/> > https://wiki.openssl.org/index.php/Random_fork-safety > <https://wiki.openssl.org/index.php/Random_fork-safety> > > Here is the code from the rand_lib.c: > rand_drbg_lock(drbg->parent); > if (RAND_DRBG_generate(drbg->parent, >buffer, bytes_needed, >prediction_resistance, >NULL, 0) != 0) > bytes = bytes_needed; > drbg->reseed_next_counter > = tsan_load(>parent->reseed_prop_counter); > rand_drbg_unlock(drbg->parent);
[openssl-users] FIPS: Which DRBG is default ?
Hello, When an application does not define OPENSSL_DRBG_DEFAULT_TYPE nor OPENSSL_DRBG_DEFAULT_FLAGS nor any compilation options (if applicable), is the default DRBG the 256 bit CTR AES (+ deviation function) in FIPS mode ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL DRBG in FIPS mode confusion.
On 15.03.2017 10:50, Jayalakshmi bhat wrote:
> Hi All,
>
> OpenSSL uses 256 bit AES-CTR DRBG as default DRBG in FIPS mode. I have
> question associated with this.
>
> 1. OpenSSL wiki says : Default DRBG is 256-bit CTR AES *using a derivation
> function*
> 2. Where as the document
> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf
> mentions "no derivation function" in one place and in another sections
> mentions both
> *Section 4 Modes of Operation and Cryptographic Functionality*
> Random Number Generation;[SP 80090] DRBG5 Hash
> DRBG
> Symmetric key generation Prediction resistance
> HMAC DRBG, no reseed
> supported for all variations
> CTR DRBG (AES), no derivation function
> *Section 6 Selftest *
> DRBG KAT CTR_DRBG: AES, 256 bit with and without derivation function *
> *
>
> Please can any one let me know what is the default behavior? Is there any way
> to toggle between using and not using derivation function.
>
> Regards
> Jayalakshmi
>
The default is set by the FIPS enabled OpenSSL crypto library (not by the
OpenSSL FIPS object module itself) in RAND_init_fips(), rand_lib.c:277:
openssl-1.0.2k/crypto/rand/rand_lib.c:277:if (FIPS_drbg_init(dctx,
fips_drbg_type, fips_drbg_flags) <= 0) {
The default value is DRBG_FLAG_CTR_USE_DF, wich follows from
openssl-1.0.2k/crypto/rand/rand_lib.c:251:# ifndef OPENSSL_DRBG_DEFAULT_FLAGS
openssl-1.0.2k/crypto/rand/rand_lib.c:252:# define OPENSSL_DRBG_DEFAULT_FLAGS
DRBG_FLAG_CTR_USE_DF
openssl-1.0.2k/crypto/rand/rand_lib.c:256:static int fips_drbg_flags =
OPENSSL_DRBG_DEFAULT_FLAGS;
openssl-1.0.2k/crypto/rand/rand_lib.c:261:fips_drbg_flags = flags;
and you can change it using void RAND_set_fips_drbg_type(int type, int flags).
Regards,
Matthias St. Pierre
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Openssl aes-256 ctr drbg
The number you asked for typically. Pauli On 21/9/21 4:49 pm, Nagarjun J wrote: Hi, What is the Number of Bytes Returned by aes-256 ctr drbg ? Thanks, Nagarjun
Removal of Dual EC DRBG from the OpenSSL FIPS module
It took a couple of hours of code hacking followed by six long months of waiting, but at long last revision 2.0.6 of the OpenSSL FIPS Object Module v2.0 (validation certificate #1747) has finally been approved: https://www.openssl.org/source/openssl-fips-2.0.6.tar.gz https://www.openssl.org/source/openssl-fips-ecp-2.0.6.tar.gz Usually new revisions add support for new platforms; with 2.0.6 the Dual EC DRBG algorithm implementation is entirely removed from the module. This removal eliminates dead code that no one in their right mind would use deliberately, and also eliminates the accidental or malicious enabling of that algorithm. Revision 2.0.6 is a direct replacement for all previous revisions (2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5). Anyone concerned about the presence of the toxic and officially deprecated Dual EC DRBG algorithm is encouraged to upgrade to revision 2.0.6. Note that the formal paperwork for revision 2.0.7, with support for eleven new platforms, was submitted some time ago. As the removal of Dual EC DRBG was not approved at that time, that revision still includes the Dual EC DRBG implementation. We've put in a query asking if we will be permitted to retroactively remove Dual EC DRBG from that as well. If that approval is not given we'll be in the odd position of re-introducing Dual EC DRBG with revision 2.0.7 when that is eventually approved. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] FIPS: Which DRBG ?
The key issue still remains, are the validated SP800-90 DRBGs the _same_ as SP800-90A's DRBGs? If yes then we can probably use Openssl-FIPS with SP800-90A, otherwise OpenSSL-FIPS 2.0.9 probably can no longer be used for any new validations? Thanks, xxiao --- Hi, For the second question any DRBG that are approved in FIPS SP 800-90A are approved for any application. You can chose over tha Hash, HMAC or CTR DRBG equivalently. Best regards Q Gouchet Le 23 mars 2015 09:38, jonetsu jone...@teksavvy.com a écrit : Hello, Following on the 'SP800-90 DRBG in OpenSSL FIPS 140 for SP800-90A?' topic, the OpenSSL source code does not seem to mention SP 800-90A. Only SP 800-90. So the certifications were made for SP 800-90, is that right ? Also, does it depend on the application to choose which DRBG and moreover, for regular FIPS uses, does it matter which DRBG is used since they are all approved ? One more question: is there a way for us to actually know/test which one id used by an application ? I currently am using a FIPS_post_set_callback() placed in FIPS_mode_set() - can this be useful to identify which DRBG is used ? Maybe FIPS_drbg_set_callbacks() could be more useful ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: error retrieving entropy
On Fri, Mar 22, 2013, voryl wrote: Hi Would you know if there are SP 800-90 DRBG replacement for FIPS_rand_set_key and FIPS_rand_set_dt? No, those are for the X9.31 PRNG. If you want to supply entropy to the DRBG then you need to supply appropriate callbacks. The FIPS capable OpenSSL supplies the necessary callbacks automatically on initialisation so this only applies if you want to use a the FIPS module without the FIPS capable OpenSSL, or you wish to provide your own instance of the DRBG. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
What is the underlying algorithm in RAND_bytes() function?
I am using RAND_bytes function to generate cryptographically secure random numbers. I want to know if it uses Hash based DRBG or HMAC based DRBG. If it uses Hash based DRBG what is the underlying hash function used? I looked at the source code and found that it uses some MD function but I could not find which MD it is using. -- View this message in context: http://openssl.6102.n7.nabble.com/What-is-the-underlying-algorithm-in-RAND-bytes-function-tp50089.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
[openssl-users] CTR_DRBG with or without a derivation function (re: FIPS 140-2)
To quote from several places: Once you call FIPS_mode_set (and assuming it returns non-zero), you are using the NIST approved DRBGs. From OpenSSL's Random Numbers wiki page: The default DRBG is 256-bit CTR AES using a derivation function ... To use the FIPS random number generator, simply use RAND_bytes as described earlier. Note that the call to FIPS_mode_set must succeed in order to operate in FIPS 140 mode. But if I look at the OpenSSL/FIPS security policy it lists: CTR DRBG (AES), no derivation function as being approved but there is no mention of whether CTR DRBG (AES) with a derivation function is approved or not. Thoughts? Thanks in advance, Steve ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Drbg kat test data: Openssl-fips 2.0.16
Manish asked: > There is DRBG kat test data in fips_drbg_selftest.h. (Openssl-fips-2.0.16) > Can anyone let me know, What is the source of this constant arrays. NIST > link or any other source will be helpful? I'm pretty sure that the test data for the DRBG KAT (known answer test) came from the NIST algorithm test tool when the OpenSSL team tested all of the algorithm implementations. The CAVP also posts sample test vectors if you are looking for that sort of thing: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/random-number-generators#DRBG Mark J. Minnoch Co-Founder, CISSP KeyPair Consulting +1 (805) 550-3231 <(805)%20550-3231> mobile https://KeyPair.us <https://keypair.us/> https://www.linkedin.com/in/minnoch *We expertly guide technology companies in achieving their FIPS 140 goals* *Blog post: You Have Your FIPS Certificate. Now What? <https://keypair.us/2018/03/you-have-your-fips-certificate-now-what/>*
OpenSSL 3: FIPS DRBG Tests
I am writing the FIPS DRBG AVS per NIST SP800-90A. I have some questions. 1. Is the TEST-RAND ok for nist test? I am planning to basically follow the steps in test/acvp_test.c:drbg_test(), but the data is read in from a file rather than an in memory structure. 2. Some of the test vectors provide you with a 2nd entropy value to use for the 2nd call to generate. Can I call EVP_RAND_set_prams() with a OSSL_RAND_PARAM_TEST_ENTROPY before the 2nd call to generate? 3. And finally, our existing test, based on openssl-fips-2.0.5 called FIPS_drbg_new(). That function allows you to pass an EC curve NID in the upper 16 bits of the drbg type. Not sure how to do this in OpenSSL 3, however, I see no mention of EC curves in: https://csrc.nist.gov/csrc/media/projects/cryptographic-algorithm-validation-program/documents/drbg/drbgvs.pdf So it may be a moot issue. Thanks, Kory
[openssl-users] DRBG and prediction resistance
Hi All, What is the reason that the DRBG random generation function- fips_drbg_bytes does not consider prediction resistance as input? Inside fips_drbg_bytes rv = FIPS_drbg_generate(dctx, out, rcnt, 0, adin, adinlen); //prediction resistance disabled And as a result the entropy generation callback - get_entropy , is never invoked. How can we enable prediction resistance when using fips_drbg_bytes? thanks, Bala ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: fingerprint does not match on FIPS_mode_set when FIPS + openssl is dynamically linked into build
Cassie Helms cassie.helms@... writes: Built fips_algvs on build system and scp'd to target system as suggested. Hmm. I incorporated building fips_algvs into my build system and ran it from the rpm install on the target machine. I get different results now -- can anyone point to what this might indicate, coupled with the fips fingerprint error? # fips_algvs fips_test_suite post FIPS-mode test application FIPS 2.0 validated module 14 Mar 2012 DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK POST started Integrity test started ERROR:2D06B06F:lib=45,func=107,reason=111:file=fips.c:line=229 Integrity test Failed Incorrectly!! DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK DRBG AES-256-CTR test started DRBG AES-256-CTR test OK DRBG SHA256 test started DRBG SHA256 test OK DRBG HMAC-SHA256 test started DRBG HMAC-SHA256 test OK DRBG P-256 SHA256 test started DRBG P-256 SHA256 test OK X9.31 PRNG keylen=16 test started X9.31 PRNG keylen=16 test OK X9.31 PRNG keylen=24 test started X9.31 PRNG keylen=24 test OK X9.31 PRNG keylen=32 test started X9.31 PRNG keylen=32 test OK Digest SHA1 test started Digest SHA1 test OK Digest SHA1 test started Digest SHA1 test OK Digest SHA1 test started Digest SHA1 test OK HMAC SHA1 test started HMAC SHA1 test OK HMAC SHA224 test started HMAC SHA224 test OK HMAC SHA256 test started HMAC SHA256 test OK HMAC SHA384 test started HMAC SHA384 test OK HMAC SHA512 test started HMAC SHA512 test OK CMAC AES-128-CBC test started CMAC AES-128-CBC test OK CMAC AES-192-CBC test started CMAC AES-192-CBC test OK CMAC AES-256-CBC test started CMAC AES-256-CBC test OK CMAC DES-EDE3-CBC test started CMAC DES-EDE3-CBC test OK Cipher AES-128-ECB test started Cipher AES-128-ECB test OK CCM test started CCM test OK GCM test started GCM test OK XTS AES-128-XTS test started XTS AES-128-XTS test OK XTS AES-256-XTS test started XTS AES-256-XTS test OK Cipher DES-EDE3-ECB test started Cipher DES-EDE3-ECB test OK Cipher DES-EDE3-ECB test started Cipher DES-EDE3-ECB test OK Signature RSA test started Signature RSA test OK Signature ECDSA P-224 test started Signature ECDSA P-224 test OK Signature ECDSA K-233 test started Signature ECDSA K-233 test OK Signature DSA test started Signature DSA test OK ECDH P-224 test started ECDH P-224 test OK POST Failed Power-up self test failed Old results below -- ./fips_algvs fips_test_suite post FIPS-mode test application FIPS 2.0 validated module 14 Mar 2012 DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK POST started Integrity test started Integrity test OK DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK DRBG AES-256-CTR test started DRBG AES-256-CTR test OK DRBG SHA256 test started DRBG SHA256 test OK DRBG HMAC-SHA256 test started DRBG HMAC-SHA256 test OK DRBG P-256 SHA256 test started DRBG P-256 SHA256 test OK X9.31 PRNG keylen=16 test started X9.31 PRNG keylen=16 test OK X9.31 PRNG keylen=24 test started X9.31 PRNG keylen=24 test OK X9.31 PRNG keylen=32 test started X9.31 PRNG keylen=32 test OK Digest SHA1 test started Digest SHA1 test OK Digest SHA1 test started Digest SHA1 test OK Digest SHA1 test started Digest SHA1 test OK HMAC SHA1 test started HMAC SHA1 test OK HMAC SHA224 test started HMAC SHA224 test OK HMAC SHA256 test started HMAC SHA256 test OK HMAC SHA384 test started
Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?
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,
Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?
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 <mailto:pa...@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
Re: Differences between openssl-fips-2.0.7 and 2.0.8
On 11/19/2014 10:03 AM, Philip Bellino wrote: Hello, I am currently using openssl-fips-2.0.7 and I noticed that 2.0.8 is available on the website. Neither distribution contain a changelog, so I was wondering what changes were made to 2.0.8. Thanks, Phil The relevant differences cam be found in the Modification History section of the Security Policy document. The only relevant difference between 2.0.8 and 2.0.7 source code is the re-removal of Dual EC DRBG. I say re-removal and not removal because Dual EC DRBG was originally removed with revision 2.0.6. However, the 2.0.6 submission languished at the CMVP for six months during which time we added additional platforms to revision 2.0.7, using code which still included Dual EC DRBG as that removal had not yet been approved. As it turns out both 2.0.6 and 2.0.7 were approved in the same week. We had to wait for 2.0.8 to remove Dual EC DRBG again, hopefully permanently this time. If you don't care about the presence of Dual EC DRBG -- which you shouldn't be using and which isn't usable anyway due to a bug discovered by Steve Checkoway et. al. in their analysis of Dual EC DRBG implementations (http://dualec.org/) -- then there is no reason to upgrade to 2.0.8 if 2.0.7 is currently working for you. As a general rule you should use the latest available revision of the OpenSSL FIPS Object module for all new development, as that revision will support all tested platforms. But, there is no need to upgrade already deployed FIPS module instances. Since we are generally not allowed to introduce bugfixes or performance enhancements to already validated FIPS modules, the latest revision is generally not better in any significant sense than earlier revisions. In particular we are generally unable to address vulnerabilities that we know are present in or with the FIPS module (e.g. Lucky 13), so we don't. The revision increment usually only represents the addition of specific new platforms. The exception to that rule is the removal of Dual EC DRBG, which can be considered a bugfix and/or enhancement. Even there the presence of unused Dual EC DRBG code in the older revisions does not *directly* represent a security vulnerability. I say directly because there is an argument, forcefully expressed to me by several stakeholders and interested parties, that the mere presence of latent Dual EC DRBG code is a potential problem. I have discussed that issue in a personal blog entry: http://veridicalsystems.com/blog/immutability-of-fips/ for those who care to stare into that abyss. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL FIPS Object Module 2.0.8 now available - Dual EC DRBG removed (again)
It only took nine months, but we finally have a revision of the OpenSSL FIPS Object Module v2.0 (validation certificate #1747) that supports all formally tested platforms and omits Dual EC DRBG entirely. The earlier revision 2.0.6 also removed Dual EC DRBG, but was superseded only three days later by revision 2.0.7 which added new platforms and reinstated Dual EC DRBG. That happened because approval of the 2.0.6 revision was stuck in bureaucratic limbo for months, with final approval uncertain, during which time we had to proceed with testing new platforms on a code base that still included the Dual EC DRB implementation. As it happens 2.0.6 and the much newer revision supporting those new platforms, 2.0.7, were approved at almost the same time. 2.0.8 is now the preferred revision for all platforms for any new development. There is no need to upgrade any currently fielded revisions unless you feel removal of Dual EC DRBG warrants such an upgrade. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL-3.+ how to configure [random]?
"man config" for OpenSSL-3.0 and newer says that there can be "[random]" section in "openssl.cnf", where I can specify type of RNG, other things, and *seed*, and seed *properties*. Unfortunately, it did not bother to even list the possible/allowed values, let alone explain what they'd mean: Random Configuration The name random in the initialization section names the section containing the random number generater settings. Within the random section, the following names have meaning: random This is used to specify the random bit generator. For example: [random] random = CTR-DRBG The available random bit generators are: CTR-DRBG HASH-DRBG HMAC-DRBG . . . . . properties This sets the property query used when fetching the random bit generator and any underlying algorithms. seed This sets the randomness source that should be used. By default SEED-SRC will be used outside of the FIPS provider. The FIPS provider uses call backs to access the same randomness sources from outside the validated boundary. seed_properties This sets the property query used when fetching the randomness source. I want to configure this [random] to use CTR-DRBG, using RDRAND as "seed". Based on "openssl list -seeds", I guess "seed = rdrand" should be OK. What properties can I set, if any? How does this "[random]" relate to the RDRAND *engine* (see below)? $ openssl3 engine rdrand -t (rdrand) Intel RDRAND engine [ available ] Thanks! -- Regards, Uri Blumenthal Voice: (781) 981-1638 Secure Resilient Systems and Technologies Cell: (339) 223-5363 MIT Lincoln Laboratory 244 Wood Street, Lexington, MA 02420-9108 Web: https://www.ll.mit.edu/biographies/uri-blumenthal Root CA: https://www.ll.mit.edu/llrca2.pem There are two ways to design a system. One is to make is so simple there are obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies. - C. A. R. Hoare smime.p7s Description: S/MIME cryptographic signature
Re: OpenSSL 3: FIPS DRBG Tests
On 12/11/21 4:02 am, Kory Hamzeh wrote: I am writing the FIPS DRBG AVS per NIST SP800-90A. I have some questions. 1. Is the TEST-RAND ok for nist test? I am planning to basically follow the steps in test/acvp_test.c:drbg_test(), but the data is read in from a file rather than an in memory structure. This is one of the things it is intended for. You might consider writing a BIO-RAND that reads its input from a BIO or one that reads from a file. TEST-RAND is in memory only but the amount of data shouldn't be too large to handle. 2. Some of the test vectors provide you with a 2nd entropy value to use for the 2nd call to generate. Can I call EVP_RAND_set_prams() with a OSSL_RAND_PARAM_TEST_ENTROPY before the 2nd call to generate? Yes you can. You ought to to look at the function rand_test_run() in test/evp_test.c (as well as the code before and after). This is processing slightly munged CAVs data and does everything you should need. 3. And finally, our existing test, based on openssl-fips-2.0.5 called FIPS_drbg_new(). That function allows you to pass an EC curve NID in the upper 16 bits of the drbg type. Not sure how to do this in OpenSSL 3, however, I see no mention of EC curves in: https://csrc.nist.gov/csrc/media/projects/cryptographic-algorithm-validation-program/documents/drbg/drbgvs.pdf So it may be a moot issue. It's moot. None of the approved DRBGs use EC anymore. There was a bit of controversy a number of years ago about the Dual-EC DRBG: it's almost certainly back-doored by the US government. Pauli
Re: fingerprint does not match on FIPS_mode_set when FIPS + openssl is dynamically linked into build
What platform is the target system? cat /etc/*-release: RHEL Server 5.5 (Tikanga) uname -mrs: Linux 2.6.18-194.el5 x86_64 Build system specs are the same as these. After you build the validated module do this: make build_algvs This should build an fips_algvs binary in the test directory. Copy that to the target system and run: ./fips_algvs fips_test_suite post Built fips_algvs on build system and scp'd to target system as suggested. ./fips_algvs fips_test_suite post FIPS-mode test application FIPS 2.0 validated module 14 Mar 2012 DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK POST started Integrity test started Integrity test OK DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK DRBG AES-256-CTR test started DRBG AES-256-CTR test OK DRBG SHA256 test started DRBG SHA256 test OK DRBG HMAC-SHA256 test started DRBG HMAC-SHA256 test OK DRBG P-256 SHA256 test started DRBG P-256 SHA256 test OK X9.31 PRNG keylen=16 test started X9.31 PRNG keylen=16 test OK X9.31 PRNG keylen=24 test started X9.31 PRNG keylen=24 test OK X9.31 PRNG keylen=32 test started X9.31 PRNG keylen=32 test OK Digest SHA1 test started Digest SHA1 test OK Digest SHA1 test started Digest SHA1 test OK Digest SHA1 test started Digest SHA1 test OK HMAC SHA1 test started HMAC SHA1 test OK HMAC SHA224 test started HMAC SHA224 test OK HMAC SHA256 test started HMAC SHA256 test OK HMAC SHA384 test started HMAC SHA384 test OK HMAC SHA512 test started HMAC SHA512 test OK CMAC AES-128-CBC test started CMAC AES-128-CBC test OK CMAC AES-192-CBC test started CMAC AES-192-CBC test OK CMAC AES-256-CBC test started CMAC AES-256-CBC test OK CMAC DES-EDE3-CBC test started CMAC DES-EDE3-CBC test OK Cipher AES-128-ECB test started Cipher AES-128-ECB test OK CCM test started CCM test OK GCM test started GCM test OK XTS AES-128-XTS test started XTS AES-128-XTS test OK XTS AES-256-XTS test started XTS AES-256-XTS test OK Cipher DES-EDE3-ECB test started Cipher DES-EDE3-ECB test OK Cipher DES-EDE3-ECB test started Cipher DES-EDE3-ECB test OK Signature RSA test started Signature RSA test OK Signature ECDSA P-224 test started Signature ECDSA P-224 test OK Signature ECDSA K-233 test started Signature ECDSA K-233 test OK Signature DSA test started Signature DSA test OK ECDH P-224 test started ECDH P-224 test OK POST Success Power-up self test successful Thanks for looking at this. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Got FIPS routines:FIPS_drbg_init:selftest failure, how do I work around it?
On Wed, Mar 27, 2013, Bao, Robert wrote: I changed the default DRBG for FIPS to HMAC_SHA384 by following Dr. Henson's suggestion in another post titled FIPS Mode and Default DRBG (OpenSSL 1.0.x and FIPS 2.0 Module) I changed the OpenSSL compile flag OPENSSL_DRBG_DEFAULT_TYPE to point to NID_hmacWithSHA384. In run time however, the FIPS_mode_set(1) function returned error:2D073087:FIPS routines:FIPS_drbg_init:selftest failure. What did I do wrong? How to solve/work-around this problem? Ah, you also need to set the default flags to zero as they're set up to use the CTR DRBG. You can do this with: -DOPENSSL_DRBG_DEFAULT_FLAGS=0 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Dual_EC_DRBG
On Mon, Sep 23, 2013, yustein wrote: Hi, Does OpenSSL use this by default, if not where do a user choose which method to use for CSPRNG? The default DRBG for OpenSSL is 256 bit AES CTR_DRBG. The default can be changed by using the compile time flags: -DOPENSSL_DRBG_DEFAULT_TYPE=type -DOPENSSL_DRBG_DEFAULT_FLAG=flags The default DRBG type can also be set at runtime before any other operations are performed by calling: void RAND_set_fips_drbg_type(int type, int flags); Where type and flags have the same values as those indicated in the user guide (section 6.1.2). Future versions of OpenSSL will fail if an attempt is made to use the Dual EC DRBG. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Dual_EC_DRBG
Thanks a lot! :) Tony Sent from my iPhone On Sep 24, 2013, at 2:27 PM, Dr. Stephen Henson st...@openssl.org wrote: On Mon, Sep 23, 2013, yustein wrote: Hi, Does OpenSSL use this by default, if not where do a user choose which method to use for CSPRNG? The default DRBG for OpenSSL is 256 bit AES CTR_DRBG. The default can be changed by using the compile time flags: -DOPENSSL_DRBG_DEFAULT_TYPE=type -DOPENSSL_DRBG_DEFAULT_FLAG=flags The default DRBG type can also be set at runtime before any other operations are performed by calling: void RAND_set_fips_drbg_type(int type, int flags); Where type and flags have the same values as those indicated in the user guide (section 6.1.2). Future versions of OpenSSL will fail if an attempt is made to use the Dual EC DRBG. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME cryptographic signature
cross compiling OpenSSL with fips 2.0
I am trying to cross compile openssl with fips 2.0 on our target device. Our target platform is Linux 3.2.0 running on bubybox. Here is our configure: export MACHINE = armv71 export RELEASE = 3.2.0 export SYSTEM = Linux export ARCH = arm export CROSS_COMPILE = arm-linux-gnueabihf- export FIPS_SIG=$PWD/openssl-fips-2.0.5/util/incore export HOSTCC = gcc First, I compile fips 2.0.5 as following gunzip -c openssl-fips-2.0.5.tar.gz | tar xf - cd openssl-fips-2.0.5 ./configure no-asm make make install $PWD/../fips cd .. Then compile openssl 1.0.1f as following gunzip -c openssl-1.0.1f.tar.gz | tar xf - cd openssl-1.0.1f ./configure fips no-asm --with-fipsdir=$PWD/../fips make depend make cd .. After these, I compile the testing suite cd openssl-fips-2.0.5 make build_algvs Then I run on the target device ./fips-algvs fips_test_suite post Here is the output FIPS-mode test application FIPS 2.0.5 validated module 10 Apr 2013 DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK POST started Integrity test started ERROR:2D06B06F:lib=45,func=107,reason=111:file=fips.c:line=232 Integrity test Failed Incorrectly!! DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK DRBG AES-256-CTR test started DRBG AES-256-CTR test OK DRBG SHA256 test started DRBG SHA256 test OK DRBG HMAC-SHA256 test started DRBG HMAC-SHA256 test OK DRBG P-256 SHA256 test started DRBG P-256 SHA256 test OK X9.31 PRNG keylen=16 test started X9.31 PRNG keylen=16 test OK X9.31 PRNG keylen=24 test started X9.31 PRNG keylen=24 test OK X9.31 PRNG keylen=32 test started X9.31 PRNG keylen=32 test OK Digest SHA1 test started Digest SHA1 test OK Digest SHA1 test started Digest SHA1 test OK Digest SHA1 test started Digest SHA1 test OK HMAC SHA1 test started HMAC SHA1 test OK HMAC SHA224 test started HMAC SHA224 test OK HMAC SHA256 test started HMAC SHA256 test OK HMAC SHA384 test started HMAC SHA384 test OK HMAC SHA512 test started HMAC SHA512 test OK CMAC AES-128-CBC test started CMAC AES-128-CBC test OK CMAC AES-192-CBC test started CMAC AES-192-CBC test OK CMAC AES-256-CBC test started CMAC AES-256-CBC test OK CMAC DES-EDE3-CBC test started CMAC DES-EDE3-CBC test OK Cipher AES-128-ECB test started Cipher AES-128-ECB test OK CCM test started CCM test OK GCM test started GCM test OK XTS AES-128-XTS test started XTS AES-128-XTS test OK XTS AES-256-XTS test started XTS AES-256-XTS test OK Cipher DES-EDE3-ECB test started Cipher DES-EDE3-ECB test OK Cipher DES-EDE3-ECB test started Cipher DES-EDE3-ECB test OK Signature RSA test started Signature RSA test OK Signature ECDSA P-224 test started Signature ECDSA P-224 test OK Signature ECDSA K-233 test started Signature ECDSA K-233 test OK Signature DSA test started Signature DSA test OK ECDH P-224 test started ECDH P-224 test OK POST Failed Power-up self test failed I know it failed on fingerprint test(I already did all using root), Anybody know how to solve it. -- View this message in context: http://openssl.6102.n7.nabble.com/cross-compiling-OpenSSL-with-fips-2-0-tp48794.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: cross compiling OpenSSL with fips 2.0
On Mon, Mar 10, 2014, vicki2014 wrote: I am trying to cross compile openssl with fips 2.0 on our target device. Our target platform is Linux 3.2.0 running on bubybox. Here is our configure: export MACHINE = armv71 export RELEASE = 3.2.0 export SYSTEM = Linux export ARCH = arm export CROSS_COMPILE = arm-linux-gnueabihf- export FIPS_SIG=$PWD/openssl-fips-2.0.5/util/incore export HOSTCC = gcc First, I compile fips 2.0.5 as following gunzip -c openssl-fips-2.0.5.tar.gz | tar xf - cd openssl-fips-2.0.5 ./configure no-asm make make install $PWD/../fips cd .. Then compile openssl 1.0.1f as following gunzip -c openssl-1.0.1f.tar.gz | tar xf - cd openssl-1.0.1f ./configure fips no-asm --with-fipsdir=$PWD/../fips make depend make cd .. After these, I compile the testing suite cd openssl-fips-2.0.5 make build_algvs Then I run on the target device ./fips-algvs fips_test_suite post Here is the output FIPS-mode test application FIPS 2.0.5 validated module 10 Apr 2013 DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK POST started Integrity test started ERROR:2D06B06F:lib=45,func=107,reason=111:file=fips.c:line=232 Integrity test Failed Incorrectly!! DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK DRBG AES-256-CTR test started DRBG AES-256-CTR test OK DRBG SHA256 test started DRBG SHA256 test OK DRBG HMAC-SHA256 test started DRBG HMAC-SHA256 test OK DRBG P-256 SHA256 test started DRBG P-256 SHA256 test OK X9.31 PRNG keylen=16 test started X9.31 PRNG keylen=16 test OK X9.31 PRNG keylen=24 test started X9.31 PRNG keylen=24 test OK X9.31 PRNG keylen=32 test started X9.31 PRNG keylen=32 test OK Digest SHA1 test started Digest SHA1 test OK Digest SHA1 test started Digest SHA1 test OK Digest SHA1 test started Digest SHA1 test OK HMAC SHA1 test started HMAC SHA1 test OK HMAC SHA224 test started HMAC SHA224 test OK HMAC SHA256 test started HMAC SHA256 test OK HMAC SHA384 test started HMAC SHA384 test OK HMAC SHA512 test started HMAC SHA512 test OK CMAC AES-128-CBC test started CMAC AES-128-CBC test OK CMAC AES-192-CBC test started CMAC AES-192-CBC test OK CMAC AES-256-CBC test started CMAC AES-256-CBC test OK CMAC DES-EDE3-CBC test started CMAC DES-EDE3-CBC test OK Cipher AES-128-ECB test started Cipher AES-128-ECB test OK CCM test started CCM test OK GCM test started GCM test OK XTS AES-128-XTS test started XTS AES-128-XTS test OK XTS AES-256-XTS test started XTS AES-256-XTS test OK Cipher DES-EDE3-ECB test started Cipher DES-EDE3-ECB test OK Cipher DES-EDE3-ECB test started Cipher DES-EDE3-ECB test OK Signature RSA test started Signature RSA test OK Signature ECDSA P-224 test started Signature ECDSA P-224 test OK Signature ECDSA K-233 test started Signature ECDSA K-233 test OK Signature DSA test started Signature DSA test OK ECDH P-224 test started ECDH P-224 test OK POST Failed Power-up self test failed I know it failed on fingerprint test(I already did all using root), Anybody know how to solve it. There are several possible causes. One is that incore is not calculating the correct signature. One workaround for this is to create your own version of incore which copies the target to the device, runs it and then returns the correct signature. This is how native compilation works. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Dual_EC_DRBG
Thanks :) Sent from my iPhone On Sep 24, 2013, at 4:28 PM, Steve Marquess-3 [via OpenSSL] ml-node+s6102n4664...@n7.nabble.com wrote: On 09/24/2013 07:27 AM, Dr. Stephen Henson wrote: ... Future versions of OpenSSL will fail if an attempt is made to use the Dual EC DRBG. Note we're also looking into removing Dual EC DRBG from the OpenSSL FIPS Object Module, a more difficult proposition as there are strict restrictions on changes to FIPS 140-2 validated modules even to address security issues. For the typical user of the FIPS module accessing it via the FIPS capable OpenSSL the presence or absence of Dual EC DRBG in the FIPS module itself will be moot once it disappears from OpenSSL proper. But, in a few cases the FIPS module is used directly. Incidentally, I was the one who advocated the implementation of that DRBG, along with the other three in SP800-90, on the grounds that a) it was after all an official standard, b) OpenSSL already implements some weak algorithms, and c) the deficiencies were so well known that surely no one would be stupid enough to actually use it for any serious real world applications. I was profoundly wrong about that. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct [hidden email] [hidden email] gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing List[hidden email] Automated List Manager [hidden email] If you reply to this email, your message will be added to the discussion below: http://openssl.6102.n7.nabble.com/Dual-EC-DRBG-tp46628p46642.html To unsubscribe from Dual_EC_DRBG, click here. NAML smime.p7s (3K) http://openssl.6102.n7.nabble.com/attachment/46643/0/smime.p7s -- View this message in context: http://openssl.6102.n7.nabble.com/Dual-EC-DRBG-tp46628p46643.html Sent from the OpenSSL - User mailing list archive at Nabble.com.
Got FIPS routines:FIPS_drbg_init:selftest failure, how do I work around it?
I changed the default DRBG for FIPS to HMAC_SHA384 by following Dr. Henson's suggestion in another post titled FIPS Mode and Default DRBG (OpenSSL 1.0.x and FIPS 2.0 Module) I changed the OpenSSL compile flag OPENSSL_DRBG_DEFAULT_TYPE to point to NID_hmacWithSHA384. In run time however, the FIPS_mode_set(1) function returned error:2D073087:FIPS routines:FIPS_drbg_init:selftest failure. What did I do wrong? How to solve/work-around this problem? My OpenSSL version is 1.0.1c, and OpenSSL/FIPS version is 2.0.2. Thanks a lot. Robert Bao Software House Tyco International
Re: Consequences to draw from the latest Snowden revelations?
On 07 Sep 2013, at 11:26 PM, Steve Marquess marqu...@opensslfoundation.com wrote: Note that Dual EC DRBG is *NOT* used by default and a calling application must specifically and deliberately enable it; that cannot be done accidentally. Any application which does so will hopefully be fully aware of the consequences (and probably must do so for policy reasons). Is the Dual EC DRBG used in any hardware crypto implementations, and if so, how would we avoid using those hardware implementations with certainty in OpenSSL? I'm thinking specifically of the Intel one described here: http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator Regards, Graham -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CAVP/DRBG Results with multiple block lengths
On Tue, Apr 01, 2014, John Craft wrote: I am tasked with running CAVP test vectors for OpenSSL. I have encountered an issue with DRBG and am wondering if anyone has advice. Try the fips_drbgvs.c source from the OpenSSL-fips-2_0-dev branch. This determines the required output length by pasring the [ReturnedBitsLen line, if any. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RAND_bytes() and NIST SP 800-90 DRBG: with latest FIPS-capable OpenSSL 1.0.1
Hello, Does RAND_bytes() now defaults to the full implementation of NIST SP 800-90 DRBG, while in FIPS mode with the latest FIPS-capable OpenSSL 1.0.1? Per code inspection, that is what it looks like. But just wanted to double check to be 100% certain. If that is the case, is the continuous PRNG test done only in the fips_get_entropy() call in fips/rand/fips_drbg_lib.c? Also, what are sources of entropy and how much entropy is it gathered for the RNG's use? And lastly, is fips_get_entropy() called only when RAND_seed() or FIPS_mode_set() is called? In essence, I I am trying to understand exactly when is the continuous PRNG test is called. Thanks! Bill __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
[openssl-users] AES-CTR-256 test suite for FIPS
Hi All, We are using DRBG using AES-CTR-256 in FIPS mode. I could find test suite/file that takes CAVP test request and generating the response for DRBG using AES-CTR-256. However I am not finding any test suite/file that validates AES-CTR 128/192/256 bits. Please can any one let me know while test suite/file to validate AES-CTR. Regards Jayalakshmi -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RNG behavior by default
I agree with Kurt, except for one point: > The RAND_bytes and RAND_status manpages can clearly be improved. Both manpages got an update during the DRBG rewrite (by me) and I don't see any contradiction. You bring it to the point yourself: > So _IF_ it is seeded it is seeded... It is true that the DRBG will automatically seed, but it is equally true that it can still end up in an unseeded (error) state, if no suitable entropy source is available. And since this can also happen during reseeding (which in particular is enforced after a fork), it is always necessary to check the return value of the RAND_bytes() function. Because in the error state, the buffer is not filled at all. Matthias -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Flaw in Dual EC DRBG (no, not that one)
I have previously pointed this out as a bug in the FIPS spec. The need to prevent matching pairs in random numbers by 4.8.2 in FIPS 140-2 reduces the entropy. The requirement in 4.8.2 applies to all SP800-90 DRBGs, not just the Dual EC DRBG. I submitted this as part of my comments to the re-opened SP800-90 comment period. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is an unusual bug report for an unusual situation. I'm using it as an opportunity to point out some considerations that have not been widely reported. Summary: - --- Stephen Checkoway and Matt Green of the Johns Hopkins University Information Security Institute discovered a fatal bug in the Dual EC DRBG implemention in the OpenSSL FIPS Object Module v2.0. This bug is fatal in the sense that it prevents all use of the Dual EC DRBG algorithm. Note the bug is present in the Dual EC DRBG only, no other DRBG types are affected. The nature of the bug shows that no one has been using the OpenSSL Dual EC DRBG. Given the current status of Dual EC DRBG (now disowned[1] by the NIST CMVP[2] and pretty much toxic for any purpose) we do not plan to correct the bug. A FIPS 140-2 validated module cannot be changed without considerable expense and effort, and we have recently commenced that process of entirely removing the Dual EC DRBG code from the formally validated module. What is the bug? - --- When a PRNG is in free running mode it has to continuously check that each block of output doesn't match the previous one (the so called continuous PRNG test). If there is no previous block (as is the case on the very first call) then a block has to be generated, stored as the previous block and discarded. The output of the PRNG that the application sees is the **next* *block which is now compared with the previous block. It's this discarding part where the bug occurs: when the discard is done the code places the output into a buffer and updates the Dual EC DRBG state. When the discard occurs the data must not be output and the Dual EC DRBG state must be updated, but that state update isn't done. In the case of no additional input this has no effect, but additional input is used by the FIPS capable OpenSSL. Note that additional input does *not* effectively defeat the backdoor vulnerability[3]. Will it be fixed? - We have no plans to fix this bug, as NIST has disowned Dual EC DRBG in an official NIST Recommendation (http://csrc.nist.gov/publications/nistbul/itlbul2013_09_supplemental.pdf) and use of Dual EC DRBG is already disabled in upcoming OpenSSL releases. Even if we wanted to fix it our options are severely constrained by the fact that the CMVP process forbids modifications of any kind (even to address severe vulnerabilities) without the substantial time and expense of formal retesting and review. Is there a patch? - Of course: diff --git a/fips/rand/fips_drbg_ec.c b/fips/rand/fips_drbg_ec.c index 6be6534..270cfbb 100644 - --- a/fips/rand/fips_drbg_ec.c +++ b/fips/rand/fips_drbg_ec.c @@ -328,6 +328,7 @@ static int drbg_ec_generate(DRBG_CTX *dctx, if (!bn2binpad(dctx-lb, dctx-blocklength, r)) goto err; dctx-lb_valid = 1; +t = s; continue; } if (outlen dctx-blocklength) This patch is of academic interest only as *any* modification to the official FIPS module source code distribution means that the result isn't validated and is not suitable for any context requiring a FIPS 140-2 validated module. The OpenSSL FIPS module is commonly used as the basis for rebranded proprietary validations (we call these private label validations). Any such private label validations will have this same bug, and thus an assurance that Dual EC DRBG is not being used, *unless* the vendor detected and corrected the bug beforehand without notifying us. Or removed the additional input supplied by the FIPS capable OpenSSL, which would eliminate fork protection (we have also determined that a workaround in the FIPS capable OpenSSL that retains fork protection is possible, but we don't plan to implement it). How can I reproduce the bug? - --- First enable the Dual EC DRBG as default in the FIPS capable OpenSSL 1.0.1: ./config fips -DOPENSSL_DRBG_DEFAULT_TYPE=0x19f02a0 \ -DOPENSSL_DRBG_DEFAULT_FLAGS=0 -DOPENSSL_ALLOW_DUAL_EC_DRBG Note this rather complex incantation[4] demonstrates that one cannot accidentally enable the Dual EC DRBG as the default. The bug is then manifested by: OPENSSL_FIPS=1 apps/openssl sha1 README which will exhibit Dual EC DRBG stuck errors. Apply the above patch to the FIPS module, rebuild and reinstall the module, recompile the FIPS capable OpenSSL and the bug will no longer be present. Why did we implement Dual EC DRBG in the first place
Re: error retrieving entropy
Hi Would you know if there are SP 800-90 DRBG replacement for FIPS_rand_set_key and FIPS_rand_set_dt? thanks much. -- View this message in context: http://openssl.6102.n7.nabble.com/error-retrieving-entropy-tp44435p44510.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Consequences to draw from the latest Snowden revelations?
On 9/8/2013 2:13 AM, Graham Leggett wrote: On 07 Sep 2013, at 11:26 PM, Steve Marquess marqu...@opensslfoundation.com wrote: Note that Dual EC DRBG is *NOT* used by default and a calling application must specifically and deliberately enable it; that cannot be done accidentally. Any application which does so will hopefully be fully aware of the consequences (and probably must do so for policy reasons). Is the Dual EC DRBG used in any hardware crypto implementations, and if so, how would we avoid using those hardware implementations with certainty in OpenSSL? I'm thinking specifically of the Intel one described here: http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator That new Intel design sounds suspiciously like they are feeding their high quality hardware random through a 256 bit EC DRBG before allowing any user code to see it, so if that EC DRBG used is compromised, so are all the random bits. Besides, I gave up using Intel-promoted hardware crypto when they removed the firmware hub RNG just after convincing everybody to add software support for it. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Dual_EC_DRBG
Hi, Does OpenSSL use this by default, if not where do a user choose which method to use for CSPRNG? Thanks, Tony -- View this message in context: http://openssl.6102.n7.nabble.com/Dual-EC-DRBG-tp46628.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Dual_EC_DRBG
On 09/24/2013 07:27 AM, Dr. Stephen Henson wrote: ... Future versions of OpenSSL will fail if an attempt is made to use the Dual EC DRBG. Note we're also looking into removing Dual EC DRBG from the OpenSSL FIPS Object Module, a more difficult proposition as there are strict restrictions on changes to FIPS 140-2 validated modules even to address security issues. For the typical user of the FIPS module accessing it via the FIPS capable OpenSSL the presence or absence of Dual EC DRBG in the FIPS module itself will be moot once it disappears from OpenSSL proper. But, in a few cases the FIPS module is used directly. Incidentally, I was the one who advocated the implementation of that DRBG, along with the other three in SP800-90, on the grounds that a) it was after all an official standard, b) OpenSSL already implements some weak algorithms, and c) the deficiencies were so well known that surely no one would be stupid enough to actually use it for any serious real world applications. I was profoundly wrong about that. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
CAVP/DRBG Results with multiple block lengths
I am tasked with running CAVP test vectors for OpenSSL. I have encountered an issue with DRBG and am wondering if anyone has advice. When OpenSSL was originally validated, the DRBG test only required 1 blocksize of output. Now, the default length is 4 blocks unless otherwise requested. I have modified the drbgvs code as follows: r = FIPS_drbg_generate(dctx, randout, randoutlen, 1, adin, adinlen); to r = FIPS_drbg_generate(dctx, randout, numBlocks*blockSize, 1, adin, adinlen); where blockSize is set to the same value as randoutlen, i.e. FIPS_drbg_get_blocklength(dctx); I'm using the DRBG vectors from the CAVP website. The Hash vectors work correctly (excepting SHA-512T, of course), but none of the others do. Here's one test case from HMAC and the results: [SHA-1] [PredictionResistance = True] [EntropyInputLen = 128] [NonceLen = 64] [PersonalizationStringLen = 0] [AdditionalInputLen = 0] [ReturnedBitsLen = 640] COUNT = 0 EntropyInput = a0c9ab58f1e2e5a4de3ebd4ff73e9c5b Nonce = 64efd8ca028cf811 PersonalizationString = AdditionalInput = EntropyInputPR = 48a584fe69ab5aee42aa4d42176099d4 AdditionalInput = EntropyInputPR = 5e1397dc404d86a37bf55954756951e4 ReturnedBits = 17f3656c7e328817dee7ee36d588d72f14514daa 30f71ea20a9687501f4471976f302b636829a6fc 4706b7782fea20d768179d670ccc2e618f1d9727 1128aab2756fe079f3ed92e805515b481f20de2b Results should be: ReturnedBits = 9a00a2d00ed59bfe31ecb1399b608148d1969d25 0d3c1e94101098129325cab8fccc2d54731970c0 107aa4892519955e4bc6001d7f4e6a2bf8a301ab 46055c09a67188f1a740eef3e15c029b44af0344 I would expect that at least the first block length would be correct, but here all bytes are wrong. All results for all test for HMAC, CTR, and DualEC are wrong, but all results for Hash are correct. Can anyone shed some light on why these results are coming back wrong, and how I might remediate them? Is it simply impossible to return correct results when BS1? Thanks, John __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: test vectors for CTR DRBG
Jiri Hladky-2 wrote: Hello, I'm looking for the test vectors for CTR DRBG random number generator. I got test vectors from http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip which contains CTR_DRBG.rsp file. However, I'm looking for the following scenario which is not covered right now: [AES-128 no df] [PredictionResistance = False] [EntropyInputLen = 256] [NonceLen = 0] [PersonalizationStringLen = 0] [AdditionalInputLen = 0] Can anybody please provide such testing vectors? Thanks a lot! Jiri Actually, you can use vectors from the following scenario : [AES-128 no df] [PredictionResistance = False] [EntropyInputLen = 256] [NonceLen = 64] [PersonalizationStringLen = 0] [AdditionalInputLen = 0] Here, it says that there is a nonce of length 64, but it is not used as there is no nonce used when DF is not used... So even though this scenario provides a nonce value, it is never used. Trust me I tested it myself ! (you can also verify in SP800-90 that no nonce is used when no df..) Cheers ! Julien -- View this message in context: http://old.nabble.com/test-vectors-for-CTR-DRBG-tp32446997p32683724.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: test vectors for CTR DRBG
Hi Julien, thanks for the hint, I'm going to try it! Sorry for the long delay in response, I was quite sometime off-line and now I'm going through all the e-mails... Thanks! Jirka On Wed, Oct 19, 2011 at 7:06 PM, nimou rild...@gmail.com wrote: Jiri Hladky-2 wrote: Hello, I'm looking for the test vectors for CTR DRBG random number generator. I got test vectors from http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip which contains CTR_DRBG.rsp file. However, I'm looking for the following scenario which is not covered right now: [AES-128 no df] [PredictionResistance = False] [EntropyInputLen = 256] [NonceLen = 0] [PersonalizationStringLen = 0] [AdditionalInputLen = 0] Can anybody please provide such testing vectors? Thanks a lot! Jiri Actually, you can use vectors from the following scenario : [AES-128 no df] [PredictionResistance = False] [EntropyInputLen = 256] [NonceLen = 64] [PersonalizationStringLen = 0] [AdditionalInputLen = 0] Here, it says that there is a nonce of length 64, but it is not used as there is no nonce used when DF is not used... So even though this scenario provides a nonce value, it is never used. Trust me I tested it myself ! (you can also verify in SP800-90 that no nonce is used when no df..) Cheers ! Julien -- View this message in context: http://old.nabble.com/test-vectors-for-CTR-DRBG-tp32446997p32683724.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] SP800-90 DRBG in OpenSSL FIPS 140 for SP800-90A?
On 03/21/2015 02:48 PM, xxiao8 wrote: At the moment OpenSSL FIPS validation supports ANSI X9.31 with AES128 for RNG, however it will be outdated in 2015. Another alternative RNG in OpenSSL FIPS is SP800-90 DRBG, however the new requirement is to use DRBG per SP800-90A. Are the DRBGs in SP800-90/OpenSSL-FIPS-2.0.9 the same as what SP800-90A requires? Otherwise how can OpenSSL 2.0 FIPS be used in any new validations? The OpenSSL FIPS Object Module implements all three extant DRBGs (Dual EC DRBG has been removed). The DRBGs are noted in the Security Policy document: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf which is worth referencing for any does the OpenSSL FIPS Object Module have X questions. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?
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 ?
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: fingerprint does not match on FIPS_mode_set when FIPS + openssl is dynamically linked into build
On Fri, Jul 27, 2012, Cassie Helms wrote: Cassie Helms cassie.helms@... writes: Built fips_algvs on build system and scp'd to target system as suggested. Hmm. I incorporated building fips_algvs into my build system and ran it from the rpm install on the target machine. I get different results now -- can anyone point to what this might indicate, coupled with the fips fingerprint error? # fips_algvs fips_test_suite post FIPS-mode test application FIPS 2.0 validated module 14 Mar 2012 DRBG AES-256-CTR DF test started DRBG AES-256-CTR DF test OK POST started Integrity test started ERROR:2D06B06F:lib=45,func=107,reason=111:file=fips.c:line=229 Integrity test Failed Incorrectly!! Well that error indicates the fingerprint error. The question is what is different about the two build processes? 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] FIPS: Which DRBG ?
On 03/23/2015 02:36 PM, xxiao8 wrote: The key issue still remains, are the validated SP800-90 DRBGs the _same_ as SP800-90A's DRBGs? If yes then we can probably use Openssl-FIPS with SP800-90A, otherwise OpenSSL-FIPS 2.0.9 probably can no longer be used for any new validations? At the time that validation was obtained the four (at the time) DRBGs were specified by SP800-90. That document was subsequently reissued in several pieces; the current SP800-90A now contains the specifications for the three surviving DRBGs (the fatally tainted Dual EC DRBG having been removed from the formal standards and also from the OpenSSL FIPS Object Module). Now the code for the OpenSSL FIPS module can no longer be used as-is for new private label or copycat validations, but that's for different reasons and not because of the DRBGs. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fips CTR_DRBG
On Thu, Feb 26, 2015, Piotr ??obacz wrote: Hello, i have a question about FIPS CTR_DRBG. I have managed to compile openssl with fips and everything works fine. The method FIPS_mode returns me 1 so i am in FIPS mode, but what is my problem i dunno how to use properly FIPS_drbg api. If you simply want to use the DRBG in CTR mode then you don't need to do anything special: in FIPS mode the DRBG in CTR mode with a 256 bit AES key is the default and you can just use the normal RAND APIs. Do not use the self test or algorithm test code in applications: you need to set up proper entropy gathering callbacks and the test code contains deterministic examples which would have zero security in a real application. That's what the RAND API will do by default. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS: Which DRBG ?
From: Steve Marquess marqu...@openssl.com Date: 03/24/15 09:22 At the time that validation was obtained the four (at the time) DRBGs were specified by SP800-90. That document was subsequently reissued in several pieces; the current SP800-90A now contains the specifications for the three surviving DRBGs (the fatally tainted Dual EC DRBG having been removed from the formal standards and also from the OpenSSL FIPS Object Module). If it concerns only the removal of the Dual EC, then it should be OK, technically. Not on paper. Now the code for the OpenSSL FIPS module can no longer be used as-is for new private label or copycat validations, but that's for different reasons and not because of the DRBGs. I've read the User Guide bit on private label validations. In the case of a product that consists of a dedicated unit, what would be the best approach ? So far I have considered using the OpenSSL FIPS module as is, in the hope that its FIPS validation would save costs at the testing lab. Is this still feasible ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: What is the underlying algorithm in RAND_bytes() function?
Can you help me with changing the default MD from SHA1 to SHA256(for Hash DRBG)? I could not find proper resource. -- View this message in context: http://openssl.6102.n7.nabble.com/What-is-the-underlying-algorithm-in-RAND-bytes-function-tp50089p50122.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Fips CTR_DRBG
On Fri, Feb 27, 2015, Piotr ??obacz wrote: I can do mutch more i can give the source code: dctx = FIPS_drbg_new(NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF); Try including the flag DRBG_FLAG_TEST: the DRBG needs to be in test mode otherwise the continuous PRNG test discards the first block generated. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Query on engine support in OpenSSL 1.0.2h
Hi All, We currently use OpenSSL 1.0.2h, we are in the process of upgrading to OpenSSL 1.1.1. To address some legacy functionalities we are planning to write engines for OpenSSL 1.0.2h offload crypto operation to external components. We have few queries regarding the same 1. Can we offload all crypto operations (Digest, Encryption/decryption, RSA, ECDSA, DRBG etc) using Engines in OpenSSL 1.0.2h 2. If not, is it must to upgrade to OpenSSL 1.1.1 to achieve the same? Regards, Jayalakshmi
RE: Got FIPS routines:FIPS_drbg_init:selftest failure, how do I work around it?
That worked! Thanks a lot for your quick help. Robert -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Thursday, March 28, 2013 10:11 AM To: openssl-users@openssl.org Subject: Re: Got FIPS routines:FIPS_drbg_init:selftest failure, how do I work around it? On Wed, Mar 27, 2013, Bao, Robert wrote: I changed the default DRBG for FIPS to HMAC_SHA384 by following Dr. Henson's suggestion in another post titled FIPS Mode and Default DRBG (OpenSSL 1.0.x and FIPS 2.0 Module) I changed the OpenSSL compile flag OPENSSL_DRBG_DEFAULT_TYPE to point to NID_hmacWithSHA384. In run time however, the FIPS_mode_set(1) function returned error:2D073087:FIPS routines:FIPS_drbg_init:selftest failure. What did I do wrong? How to solve/work-around this problem? Ah, you also need to set the default flags to zero as they're set up to use the CTR DRBG. You can do this with: -DOPENSSL_DRBG_DEFAULT_FLAGS=0 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] regarding openssl and openssl fips
On 08/24/2016 09:31 AM, Test ssl wrote: > Hi, > > I am having a product which is right now using openssl1.0.1s and > opensslfips 2.0.1 > > I am upgrading to openssl1.0.2h, is it OK to still be at openssfips > 2.0.1 or do i need to upgrade the opensslfips too to 2.0.12? > > Regards, > > Yes, it's fine to stay at 2.0.1 if that's working for you now. With one singular exception, we're not allowed to implement improvements or bug fixes in a validated cryptographic module, so the later revisions of the OpenSSL FIPS module (now up to 2.0.13) are not "better" in any real-world sense (i.e. better performance, security vulnerability mitigations, etc.). The permitted mods are for platform portability and have to implemented in a way that does not impact any previously tested platforms. The exception is the complete removal of Dual EC DRBG as of 2.0.6 (and again for 2.0.8, long story). The Dual EC DRBG was disabled all along, but its complete removal was arguably a vulnerability mitigation. I think that was only allowed (after much delay) as a special case exception due to the notoriety of that algorithm. If not having a dormant Dual EC DRBG matters to you then upgrade to any revision 2.0.8 or later. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RNG behavior by default
> So my concerns are:
> 1. Whether I really can count on getting a high-entropy PRNG across these
> various platforms, without any explicit initialization.
Yes, for the mentioned platforms, the default configuration is
`--with-rand-seed=os`, which means the DRBG automatically seeds
and reseeds using os entropy sources.
2. If something goes wrong with PRNG initialization, that it will fail hard
rather than fall back to something less secure. And if so how I detect such a
failure.
If the (re-)seeding fails, the DRBG enters an error state. When you try to
generate random bytes it will detect the error state and try
automatically to heal the error state by reinstantiating. But if reseeding
fails, it will return and error code and not generate any pseudo random bytes.
Citing from the manual pages:
OpenSSL comes with a default implementation of the RAND API which is
based on the
deterministic random bit generator (DRBG) model as described in [NIST
SP 800-90A Rev. 1].
The default random generator will initialize automatically on first use
and will be fully functional
without having to be initialized ('seeded') explicitly. It seeds and
reseeds itself automatically using
trusted random sources provided by the operating system.
As a normal application developer, you do not have to worry about any
details, just use RAND_bytes(3)
to obtain random data. Having said that, there is one important rule to
obey: Always check the error
return value of RAND_bytes(3) and do not take randomness for granted.
https://www.openssl.org/docs/man1.1.1/man7/RAND.html
(See also https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html)
Matthias
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode uses /dev/urandom ?
Well... I'm just trying, for the test, to do something like: debian:~/openssl# strace -xe trace=file,read,write,close /usr/local/ssl/bin/openssl rand 10 [...] open(/dev/urandom, O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 read(3, \xa9\xea\xf3\x6e\x08\x14\xe7\xeb\x11\x9c\x72\x64\x69\x54\x0d\x96\x43\x34\x68\x25\xe3\x45\x8b\xe8\xe6\x36\xde\x9b\x33\x3a\x6a\xe2, 32) = 32 close(3)= 0 I know that it will have poor performance, and in fact I don't want to do this... but we're going to pass SP800 56b and they are asking us to use blocking to be sure that the entropy generated before the openssl seed is enough (256 entropy bits). My understanding of how OpenSSL seeds DRBGs is as follows: When initialization function is called, first the non-approved hash-based DRBG that is part of the baseline library is seeded. This DRBG is seeded according to library's settings (in e_os.h DEVRANDOM), and it defaults to /dev/urandom. After that approved FIPS-mode DRBG with 256-bit AES-CTR is seeded by calling the bytes() method. This way, output of the first non-approved DRBG is used to seed FIPS-mode DRBG. This is why module settings (e_os.h DEVRANDOM) are ignored. So, I'm not sure if I'm thinking it fine, or if I could change e_os.h to do that and still being FIPS certified, or... Alberto. 2015-03-11 21:10 GMT+01:00 Tom Francis thomas.francis...@pobox.com: On Mar 11, 2015, at 11:40 AM, Alberto Roman Linacero aro...@alienvault.com wrote: Dear all, I'm doing an strace to the FIPS validated version of openssl, and I'm seeing that is uses /dev/urandom. I thought that the FIPS validated module always use /dev/random, isn't this the case, or am I doing something wrong?. If it uses /dev/urandom, is it possible/advisable to change it to /dev/random (how?), and still the module being FIPS validated? It would depend on what code is reading from /dev/urandom. If it’s the FIPS Object Module that’s doing the reading, then no, absolutely not. If it’s the FIPS-capable OpenSSL that reads from /dev/urandom, you can probably change it. But I’m curious as to why you would want to do this. Most systems with /dev/random and /dev/urandom are similar to Linux, in that /dev/urandom is the preferred source for “random data”, including when seeding a PRNG (which is how it’s used by OpenSSL). And because /dev/random can block, you might have ridiculously poor performance (and worse, it’ll be unpredictably poor performance, i.e. sometimes it’ll work great, and other times it’ll be horrible, and you never which you’ll get). This page, http://www.2uo.de/myths-about-urandom/ , is specific to Linux, but at a high-level, It’s also true for AIX, HP-UX, Solaris, FreeBSD, and NetBSD (OpenBSD is more complex). I’m not about other UNIX-like systems, as I stopped using those before any of them ever provided such devices. :) TOM Thanks for your help in advance and best regards, Alberto. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Alberto Román Engineering team http://www.alienvault.com Mobile: +34 605804179 Phone: + 91 5151344 Email: aro...@alienvault.com ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: OpenSSL-3.+ how to configure [random]?
Currently there is exactly one seed source that is usable in OpenSSL
3.0: "SEED-SRC". It is documented in EVP_RAND-SEED-SRC. The reason the
seed source can be set is to allow you to use a third party provider
than includes one.
If you want to force RDRAND as the only seeding source, this needs to be
done at configuration time with the --with-rand-seed configuration
option. Note that this will enable RDSEED in preference to RDRAND but
will use RDRAND if RDSEED isn't available.
I assume that you meant openssl info -seeds not openssl list -seeds.
This lists the seed sources that were configured at build time.
There is no relationship between the RDRAND engine and the seed
sources. Well, they both use the same machine instruction to get the
seed material but it's called from completely different places.
Yes, the man pages could be more informative and user friendly :(
Pauli
On 10/11/21 12:35 pm, Blumenthal, Uri - 0553 - MITLL wrote:
"man config" for OpenSSL-3.0 and newer says that there can be "[random]" section in
"openssl.cnf", where I can specify type of RNG, other things, and *seed*, and seed *properties*.
Unfortunately, it did not bother to even list the possible/allowed values, let
alone explain what they'd mean:
Random Configuration
The name random in the initialization section names the section
containing the random number
generater settings.
Within the random section, the following names have meaning:
random
This is used to specify the random bit generator. For example:
[random]
random = CTR-DRBG
The available random bit generators are:
CTR-DRBG
HASH-DRBG
HMAC-DRBG
. . . . .
properties
This sets the property query used when fetching the random bit
generator and any
underlying algorithms.
seed
This sets the randomness source that should be used. By default
SEED-SRC will be used
outside of the FIPS provider. The FIPS provider uses call backs to
access the same
randomness sources from outside the validated boundary.
seed_properties
This sets the property query used when fetching the randomness
source.
I want to configure this [random] to use CTR-DRBG, using RDRAND as "seed". Based on "openssl list
-seeds", I guess "seed = rdrand" should be OK. What properties can I set, if any? How does this
"[random]" relate to the RDRAND *engine* (see below)?
$ openssl3 engine rdrand -t
(rdrand) Intel RDRAND engine
[ available ]
Thanks!
--
Regards,
Uri Blumenthal Voice: (781) 981-1638
Secure Resilient Systems and Technologies Cell: (339) 223-5363
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA 02420-9108
Web: https://www.ll.mit.edu/biographies/uri-blumenthal
Root CA: https://www.ll.mit.edu/llrca2.pem
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
- C. A. R. Hoare
Re: FIPS-capable OpenSSL that works on Windows NT
On Oct 24, 2011, at 1:01 AM, Bill Durant wrote: On Oct 5, 2011, at 12:15 PM, Dr. Stephen Henson wrote: On Wed, Oct 05, 2011, Bill Durant wrote: On Oct 5, 2011, at 8:08 AM, Dr. Stephen Henson wrote: On Tue, Oct 04, 2011, William A. Rowe Jr. wrote: On 10/4/2011 10:45 PM, Bill Durant wrote: Does anyone know how to produce a FIPS-capable OpenSSL that works on Windows NT? It's likely not possible... But when I run it under Windows NT, I get the following run-time error: The procedure entry point Module32NextW could not be located in the dynamic link library KERNEL32.dll If you use the equivalent of nm against the fipscanister.lib, I'd expect you'll find the binding there. I see no reason the team would accommodate this in OpenSSL/FIPS 2.0, though. Support for Windows NT 4.xx ended on December 31, 2004. Support for Windows 2000 ended on July 13, 2010. So updating security or cryptographic software validation for such systems is something of an oxymoron. I'd suggest the OP try to build the 2.0 test module and run fips_test_suite on NT as it may work. A lot of the platform specific code has been removed from the 2.0 module design. Thank you everyone for the comments so far. What is the 2.0 test module? Does it mean to build openssl-fips-1.2.tar.gz? For the upcoming 2.0 validation test snapshots are available. You can see them at: ftp://ftp.openssl.org/snapshot/ Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org Hello Steve: I downloaded ftp://openssl.org/snapshot/openssl-fips-2.0-test-20111023.tar.gz and http://openssl.org/source/openssl-0.9.8r.tar.gz. I am getting the following compile errors. Any ideas on what I am doing wrong? C:\ cd openssl-fips-2.0-test-20111023 C:\ ms\do_fips no-asm ... ... *** FIPS BUILD SUCCESS* *** C:\ cd ..\openssl-0.9.8r C:\ perl Configure VC-WIN32 fips --with-fipslibdir=..\openssl-fips-2.0-test-20111023\out32dll --prefix=..\openssl-0.9.8r-fips-static no-idea no-mdc2 no-rc5 no-asm ... ... C:\ ms\do_nasm ... ... C:\ nmake -f ms\nt.mak Generating x86 for NASM assember Bignum AES ... ... Copying: ./ssl/dtls1.h to inc32/openssl/dtls1.hperl util/copy.pl .\ssl\kssl.h inc32\openssl\kssl.hCopying: ./ssl/kssl.h to inc32/openssl/kssl.hcl /Fotmp32\fips_standalone_sha1.obj -Iinc32 -Itmp32 /MT /Ox /O2 /Ob2 /W3 /W X /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE /Fdout32 -DOPENSSL_NO_IDEA -DOPENSSL_NO_CAMELLIA -DOPENSSL_NO_SEED -DOPENSSL_NO_RC5 -DOPENSSL _NO_MDC2 -DOPENSSL_NO_CMS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_KRB5 -DOPENSSL_FIPS -DOPENSSL_NO_DYNAMIC_ENGINE /Zl -c .\fips\sha\fips_standalon e_sha1.cfips_standalone_sha1.c link /nologo /subsystem:console /opt:ref /out:out32\fips_standalone_sha1.exe @C:\Users\bdurant\AppData\Local\Temp\nm257.tmp fips_standalone_sha1.obj : error LNK2019: unresolved external symbol _SHA1_Final referenced in function _hmac_init fips_standalone_sha1.obj : error LNK2019: unresolved external symbol _SHA1_Update referenced in function _hmac_init fips_standalone_sha1.obj : error LNK2019: unresolved external symbol _SHA1_Init referenced in function _hmac_init fips_standalone_sha1.obj : error LNK2019: unresolved external symbol __chkstk referenced in function _hmac_init fips_standalone_sha1.obj : error LNK2019: unresolved external symbol _fwrite referenced in function _main fips_standalone_sha1.obj : error LNK2019: unresolved external symbol _perror referenced in function _main fips_standalone_sha1.obj : error LNK2019: unresolved external symbol _printf referenced in function _main fips_standalone_sha1.obj : error LNK2019: unresolved external symbol _fread referenced in function _main fips_standalone_sha1.obj : error LNK2019: unresolved external symbol _fopen referenced in function _main fips_standalone_sha1.obj : error LNK2019: unresolved external symbol _exit refer enced in function _main fips_standalone_sha1.obj : error LNK2019: unresolved external symbol _fprintf re ferenced in function _main fips_standalone_sha1.obj : error LNK2019: unresolved external symbol __iob refer enced in function _mainLINK : error LNK2001: unresolved external symbol _mainCRTStartup out32\fips_standalone_sha1.exe : fatal error LNK1120: 13 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. Thanks, Bill And BTW, fips_test_suite.exe works fine on Windows NT after copying msvrc71.dll. C:\ fips_test_suite.exe ... ... DRBG P-521 SHA512 test started DRBG P-521 SHA512 test OK DRBG P-521 SHA512 test started DRBG P-521 SHA512 test OK
Re: [openssl-users] RNG behavior by default
On Sat, Jan 05, 2019 at 08:33:18PM +0100, Steffen Nurpmeso wrote: > > (I am also really interested and will look into OpenSSL to see if > the abort() that seems to happen if the initial seed fails is in > a linker-resolved constructor, and if not, why later failures do > not also abort. We do not call abort(). A function like RAND_bytes() or RAND_status() will just return an error. > Yes, while i am going, the full truth is that > i do not like it, i do not like that possibly a constructor call > is made for something that is possibly not needed, if it is done > like that, that someone simply aborts because of a some internal > PRNG, especially so if it is not in a constructor call and if > errors can and are expected to be handled by PRNG users anyway, RAND_bytes() has always documented that it can fail. Most function calls can return errors for various reasons. Not checking for such errors is in my opinion a bad style. > i do not like that the stuff is instantiated in all threads It's only created in each thread that tries to the RNG. I'm not sure what exactly your problem with it is. Either we need a global lock, or we need an RNG per thread. We went with the per thread RNG. We have a master DRBG that you can get with RAND_DRBG_get0_master(). I recommend that you do not use it. It requires that you take an external lock to use it. Internally we lock it, but there is no way for you to use the same lock. > which > in addition requires forks handlers to be installed all over the > place. OpenSSL adds it's own fork handler now. You should not need to do anything on fork related to OpenSSL. > the Linux kernel that drives > the world from smallest to hugest has one internal entropy pool > that feeds two public pools, whereas i the lucent little hobby > server from user space get an armada of these. Wow. Linux has a master pool, and a pool per core for the very same reason as we also have a master DRBG and per thread DRBG. Kurt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RNG behavior by default
I know that iOS (which was listed) has a good randomness source
(SecRandomCopyBytes
<https://developer.apple.com/documentation/security/1399291-secrandomcopybytes>)
but I don’t think OpenSSL uses it yet.
I’m not sure about the quality of Android’s sources, but would expect them to
be decent.
Pauli
> On 4 Jan 2019, at 10:46 pm, Dr. Matthias St. Pierre
> wrote:
>
>> So my concerns are:
>> 1. Whether I really can count on getting a high-entropy PRNG across these
>> various platforms, without any explicit initialization.
>
> Yes, for the mentioned platforms, the default configuration is
> `--with-rand-seed=os`, which means the DRBG automatically seeds
> and reseeds using os entropy sources.
>
> 2. If something goes wrong with PRNG initialization, that it will fail hard
> rather than fall back to something less secure. And if so how I detect such a
> failure.
>
> If the (re-)seeding fails, the DRBG enters an error state. When you try to
> generate random bytes it will detect the error state and try
> automatically to heal the error state by reinstantiating. But if reseeding
> fails, it will return and error code and not generate any pseudo random bytes.
>
> Citing from the manual pages:
>
> OpenSSL comes with a default implementation of the RAND API which is
> based on the
> deterministic random bit generator (DRBG) model as described in [NIST
> SP 800-90A Rev. 1].
> The default random generator will initialize automatically on first use
> and will be fully functional
> without having to be initialized ('seeded') explicitly. It seeds and
> reseeds itself automatically using
> trusted random sources provided by the operating system.
>
> As a normal application developer, you do not have to worry about any
> details, just use RAND_bytes(3)
> to obtain random data. Having said that, there is one important rule to
> obey: Always check the error
> return value of RAND_bytes(3) and do not take randomness for granted.
>
> https://www.openssl.org/docs/man1.1.1/man7/RAND.html
>
> (See also https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html)
>
> Matthias
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
RE: openssl-users Digest, Vol 77, Issue 6
> It isn't possible to do what you are wanting. RAND_METHOD replaces the RNG
> everywhere. It cannot be done on a per thread process.
Well, technically it *is* possible. However, I'm still in doubt whether it is
really necessary and should be done.
The following example assumes you are compiling for linux (or another unix-ish
os) and using pthreads:
Assume that you recorded the thread id of your thread T1 (which you obtained
from pthread_create())
in the static variable 'tid1'. Then you could take the code from [1] and modify
it as follows:
```
static int my_rand_bytes(unsigned char *out, int count)
{
int ret;
if (pthread_equal(pthread_self(), tid1) {
// ... call your special RNG here
} else {
RAND_DRBG *drbg = RAND_DRBG_get0_public();
if (drbg == NULL)
return 0;
ret = RAND_DRBG_bytes(drbg, out, count);
}
return ret;
}
```
This is just a rough sketch, note that there are more RAND_METHODs to be
considered [2].
Matthias
[1]
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L958-L970
[2]
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L1146-L1153
From: openssl-users On Behalf Of Dr Paul
Dale
Sent: Monday, April 5, 2021 3:18 AM
To: openssl-users@openssl.org
Subject: Re: openssl-users Digest, Vol 77, Issue 6
Vishwanath,
It isn't possible to do what you are wanting. RAND_METHOD replaces the RNG
everywhere. It cannot be done on a per thread process.
Pauli
On 4/4/21 9:55 pm, Vishwanath Mahajanshetty wrote:
Hi Paul,
Thanks for your response. I understand the concern for good random numbers; but
in this scenario when second thread calls SSL_CTX_new it is waiting forever in
RAND_priv_bytes(). Looks like entropy functions defined by first (bind) thread
are very specific for its own use case and can't be used by other treads.
So I am thinking of using default OpenSSL RAND_METHOD for second thread and
keep first thread (bind) to use its own random number generators.
Please let me know how can I make one thread use default RAND_METHOD and keep
other thread to use its own method. I have gone through RAND_bytes() and
drbg_bytes() but not getting enough idea. It would be really helpful if you
point out APIs which help me to achieve this requirement.
Thank You,
Vishwanath M
smime.p7s
Description: S/MIME cryptographic signature
How to link user application with FIPS-2
Hello, I would like to use CTR DRBG random number generator. It's part of the FIPS-2. I have downloaded the CVS tree and found fips_rand.h which defines functions I would like to use: FIPS_drbg_init FIPS_drbg_instantiate FIPS_drbg_generate FIPS_drbg_reseed However, I'm not able to link these functions with my application. I have compiled openssl using sources from CVS ./config make make check make install but in the installation directory I'm missing fips_rand.h I have also checked the functions which are ready in openssl library but the functions above are missing there. can you please give me a hint how to compile FIPS-2 and link it with my application? Thanks a lot! Jiri
Two new versions of the OpenSSL FIPS Object Module v2.0: 2.0.6 and 2.0.7
If you don't know or care what FIPS 140-2 is then count yourself lucky and skip this message. For those who do, and masochists, brace yourselves and read on. Back in January we submitted a formal request to the FIPS 140-2 cryptographic module validation bureaucracy to remove Dual EC DRBG from the OpenSSL FIPS Object Module v2.0 (validation certificate #1747). That prospective revision, 2.0.6, languished for months. We weren't particularly surprised because expert opinion was divided on our chances of success. One accredited test lab was absolutely positively certain it would never ever be permitted (such cryptographically significant changes are highly discouraged, to put it mildly). Another lab was willing to give it a shot, though with no guarantee of success. So we decided to gamble some of our own funds to try. Months later we submitted a routine platform portability update, 2.0.7. Since the fate of 2.0.6 was unknown we tested those new platforms with code that still included the Dual EC DRBG implementation, as otherwise we ran the risk of having to completely redo that submission if 2.0.6 was rejected (or never approved). As it happens both 2.0.6 and 2.0.7 were approved in the span of a single week. That leaves us with the very odd result that Dual EC DRBG is removed in 2.0.6 and then restored in 2.0.7. We presumably will be allowed to remove it again in a future 2.0.8, but since change letter modifications cost money we'll wait until a funded opportunity for a 2.0.8 revision presents itself. In the meantime, if you don't care about Dual EC DRBG and don't require one of the platforms[*] added by 2.0.7, do nothing. If you want a Dual EC-less FIPS module and don't use one of those new platforms, use 2.0.6. If you do want a Dual EC-less FIPS module and also require one of those new platforms, you're out of luck at least for now. As always, if you aren't specifically *required* to use FIPS 140-2 validated cryptography then don't; use the latest version of the regular OpenSSL which will have all current vulnerability and bug fixes, performance enhancements, and platform support. -Steve M. [*] Those would be platforms number 81 through 91 in Table 2 of the Security Policy document at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf, except that URL on the NIST CMVP web site still points to the 2.0.6 revision of that document. That error has been reported and should be corrected in a few days. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
[openssl-users] FIPS, continuous tests, and error reporting
Hello, I have some questions regarding table '6b - Conditional Tests' of the 2.0.7 Security Policy. It is mentioned that there are continuous tests for stuck fault. Is the meaning of 'continuous' a the matter of frequency ? Or are these continuous tests ran each time an algorithm is used ? The document mentions: In the event of a DRBG self-test failure the calling application must... - how is the result communicated to the application ? For that matter and in a general sense, so far I've seen that many encryption methods do not return any error code. How does error reporting generally works ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] conversion of RAND_bytes to rand in fips apporved way
Hi, we have linked FIPS compliant openssl version against our applications. Now few applications are using libc rand function. For FIPS compliance, applications have to call approved SP 800-90A DRBG implementation. I was planning to replace libc rand with RAND_bytes for the same. But rand() returns max value of 32767 . Is there a recomended way to convert RAND_bytes to libc rand() something like this? unsigned char buf[2]; RAND_bytes(buf,2) int *rndp = malloc(4); memcpy(rndp,buf,2); return (unsigned) ((*rndp) % 32768) Please suggest . Is there a way to give number of bits instead of bytes to RAND_bytes? Regards, -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: FIPS_rand_set_key and FIPS_rand_seed
On Thu, Apr 18, 2013, no_spam...@yahoo.com wrote: Second try... The FIPS_rand_set_key and FIPS_rand_seed functions in 0.9.8 appear to have been removed in newer OpenSSL FIPS Object Module v2.0. Those functions relate to the old X9.31 PRNG which isn't the default any more for the 2.0 module. The default is the SP800-90 DRBG. Are there replacements? Or are they not needed anymore? If an application is in FIPS mode (i.e. the OpenSSL FIPS Object Module is in FIPS mode), can the application fork without having to reset the FIPS rand state? Yes fork protection is included in the 2.0 module. In fact it was also in the 1.2.x module, you only needed to worry about fork for the 1.1 module. I see an interface called FIPS_x931_set_key, but I want to use an RBG that is compliant with SP 800-90 - which I believe the OpenSSL FIPS Object Module v2.0 supports. In FIPS mode the default RAND method uses the SP800-90 DRBG so you use it automatically. When does one use the RAND_init_fips function? You don't normally need to call that at all: it is handled automaticaly when you enter FIPS mode. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL FIPS Object Module 2.0 update
This is the promised update to my message of February 4. As before, if you don't know what FIPS 140-2 is then ignore this and count yourself lucky. Effective Jan 1 some new FIPS 140-2 validation requirements were introduced that failed to take into consideration the impact on change letter updates to existing validations. As a consequence we have been unable to proceed with the addition of platforms to the #1747 validation, aka the OpenSSL FIPS Object Module 2.0. I am pleased to report that after three months the CMVP has finally issued the guidance that allows us to proceed with change letter updates to the #1747 validation. We currently have eleven platforms in-house and are working the formal testing process for those as expeditiously as possible. Those will appear as revision 2.0.7. On January 20 we submitted the formal paperwork for approval of revision 2.0.6 to the OpenSSL FIPS Object Module 2.0 to completely remove the Dual EC DRBG implementation. I am informed that submission is under review but have no idea if or when approval can be expected, so the revision 2.0.7 testing is proceeding with the Dual EC DRBG code in place. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] openssl errors with 1.0.2h in a running application
Using openssl 1.0.2h with FIPS , we get the following two errors intermittently 2D07107B:FIPS routines:FIPS_drbg_generate:in error state error code: 0x2d071086 fips_drbg_lib.c line 391. (FIPS Self test failed, DRBG) This hits the application midway. After having established a TLS session, and having received and transmitted decent number of bytes, the connection gets broken and then on trying to connect again we get the above error and the library never recovers.. One has to restart the application. Any clues to where we should be looking Thanks From: Jayant Jain Sent: Friday, October 14, 2016 12:35:36 PM To: openssl-users@openssl.org Cc: Jayant Jain Subject: openssl errors with 1.0.2h in a running application Using openssl 1.0.2h with FIPS , we get the following two errors intermittently 2D07107B:FIPS routines:FIPS_drbg_generate:in error state error code: 0x2d071086 fips_drbg_lib.c line 391. (FIPS Self test failed, DRBG) This hits the application midway. After having established a TLS session, and having received and transmitted decent number of bytes, the connection gets broken and then on trying to connect again we get the above error and the library never recovers.. One has to restart the application. Any clues to where we should be looking Thanks -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RNG behavior by default
Dr. Matthias St. Pierre wrote in : |I agree with Kurt, except for one point: | |> The RAND_bytes and RAND_status manpages can clearly be improved. | |Both manpages got an update during the DRBG rewrite (by me) and I don't |see any contradiction. You bring it to the point yourself: I had a superficial look yesterday, but i think i have to reread them in total, anyway. |> So _IF_ it is seeded it is seeded... | |It is true that the DRBG will automatically seed, but it is equally true |that it can still end up in an unseeded (error) state, if no suitable \ |entropy |source is available. And since this can also happen during reseeding (which |in particular is enforced after a fork), it is always necessary to \ |check the return |value of the RAND_bytes() function. Because in the error state, the \ |buffer is not |filled at all. That is really bad. Of course you had to do it like this, and you surely have looked around to see what servers and other software which use OpenSSL do with the PRNG after forking (i.e., whether they reiterate the [RAND_file_name(),] RAND_load_file(), [:[RAND_add(),] RAND_status()], [RAND_write_file()] dance as documented, or not). I think i will move away from RAND_ then, nonetheless, and at least for the things i have control of. But i will definitely reread the manual now. Thanks for your answer. Ciao and a nice weekend from Germany, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode uses /dev/urandom ?
You don't even need to modify e_os.h. You can just pass in a new value for DEVRANDOM using the gcc -D compiler option. For instance, maybe you have a hardware device mapped to a Linux device file called /dev/entropy1. You can override DEVRANDOM to use this device without modifying any OpenSSL code. On 03/12/2015 12:06 PM, Alberto Roman Linacero wrote: Well... I'm just trying, for the test, to do something like: debian:~/openssl# strace -xe trace=file,read,write,close /usr/local/ssl/bin/openssl rand 10 [...] open(/dev/urandom, O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 read(3, \xa9\xea\xf3\x6e\x08\x14\xe7\xeb\x11\x9c\x72\x64\x69\x54\x0d\x96\x43\x34\x68\x25\xe3\x45\x8b\xe8\xe6\x36\xde\x9b\x33\x3a\x6a\xe2, 32) = 32 close(3)= 0 I know that it will have poor performance, and in fact I don't want to do this... but we're going to pass SP800 56b and they are asking us to use blocking to be sure that the entropy generated before the openssl seed is enough (256 entropy bits). My understanding of how OpenSSL seeds DRBGs is as follows: When initialization function is called, first the non-approved hash-based DRBG that is part of the baseline library is seeded. This DRBG is seeded according to library's settings (in e_os.h DEVRANDOM), and it defaults to /dev/urandom. After that approved FIPS-mode DRBG with 256-bit AES-CTR is seeded by calling the bytes() method. This way, output of the first non-approved DRBG is used to seed FIPS-mode DRBG. This is why module settings (e_os.h DEVRANDOM) are ignored. So, I'm not sure if I'm thinking it fine, or if I could change e_os.h to do that and still being FIPS certified, or... Alberto. 2015-03-11 21:10 GMT+01:00 Tom Francis thomas.francis...@pobox.com: On Mar 11, 2015, at 11:40 AM, Alberto Roman Linacero aro...@alienvault.com wrote: Dear all, I'm doing an strace to the FIPS validated version of openssl, and I'm seeing that is uses /dev/urandom. I thought that the FIPS validated module always use /dev/random, isn't this the case, or am I doing something wrong?. If it uses /dev/urandom, is it possible/advisable to change it to /dev/random (how?), and still the module being FIPS validated? It would depend on what code is reading from /dev/urandom. If it’s the FIPS Object Module that’s doing the reading, then no, absolutely not. If it’s the FIPS-capable OpenSSL that reads from /dev/urandom, you can probably change it. But I’m curious as to why you would want to do this. Most systems with /dev/random and /dev/urandom are similar to Linux, in that /dev/urandom is the preferred source for “random data”, including when seeding a PRNG (which is how it’s used by OpenSSL). And because /dev/random can block, you might have ridiculously poor performance (and worse, it’ll be unpredictably poor performance, i.e. sometimes it’ll work great, and other times it’ll be horrible, and you never which you’ll get). This page, http://www.2uo.de/myths-about-urandom/ , is specific to Linux, but at a high-level, It’s also true for AIX, HP-UX, Solaris, FreeBSD, and NetBSD (OpenBSD is more complex). I’m not about other UNIX-like systems, as I stopped using those before any of them ever provided such devices. :) TOM Thanks for your help in advance and best regards, Alberto. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: OpenSSL-3.+ how to configure [random]?
On 11/9/21, 22:23, "Dr Paul Dale" wrote:
>Currently I've no idea and can't reproduce locally :(
Maybe you'd know how to force the "-engine rdrand" path through "openssl.cnf"?
>A rogue configuration file could cause the DRBGs/seeds to fail. Do you
>have seed=rdrand line in the random section? That will cause the
>seeding source to fail to load at all.
No, I don't - and providing empty config causes the same result:
$ OPENSSL_CONF=/dev/null openssl3 rand -hex 4
$ OPENSSL_CONF=/dev/null openssl3 rand -engine rdrand -hex 4
Engine "rdrand" set.
61f1666d
$
Pauli
On 10/11/21 1:10 pm, Blumenthal, Uri - 0553 - MITLL wrote:
> Thank you!
>
> I'm trying to:
>
> a. understand why something like "openssl-3 rand -hex 4" does not work
(returns empty string), but "openssl-3 rand -engine rdrand -hex 4" works fine,
and gives me my random bytes - here's an illustration
>
> $ openssl3 version
> OpenSSL 3.1.0-dev (Library: OpenSSL 3.1.0-dev )
> $ openssl3 info -seeds
> rdrand ( rdseed rdrand ) os-specific
> $ openssl3 rand -hex 4
> $ openssl3 rand -engine rdrand -hex 4
> Engine "rdrand" set.
> d9b8f268
>
> and
>
> b. somehow force RDRAND engine to be loaded and initialized by default,
so I don't have to include "-engine rdrand" in every invocation, especially
since I often need to specify other engines (like "pkcs11").
>
> Here's my config, in case you spot something wrong with it (and yes, it
includes "rdcpu"):
>
> ./config --prefix=${OPENSSL_DIR} --debug --openssldir=${OPENSSL_DIR}/etc
--with-rand-seed=rdcpu,os enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5
enable-rmd160 enable-weak-ssl-ciphers zlib-dynamic enable-ssl-trace
enable-trace threads enable-buildtest-c++
>
> Thanks
> --
> Regards,
> Uri
>
> There are two ways to design a system. One is to make is so simple there
are obviously no deficiencies.
> The other is to make it so complex there are no obvious deficiencies.
>
- C. A. R. Hoare
>
>
> On 11/9/21, 21:49, "openssl-users on behalf of Dr Paul Dale"
wrote:
>
> Currently there is exactly one seed source that is usable in OpenSSL
> 3.0: "SEED-SRC". It is documented in EVP_RAND-SEED-SRC. The reason
the
> seed source can be set is to allow you to use a third party provider
> than includes one.
>
> If you want to force RDRAND as the only seeding source, this needs
to be
> done at configuration time with the --with-rand-seed configuration
> option. Note that this will enable RDSEED in preference to RDRAND
but
> will use RDRAND if RDSEED isn't available.
>
> I assume that you meant openssl info -seeds not openssl list -seeds.
> This lists the seed sources that were configured at build time.
>
>
> There is no relationship between the RDRAND engine and the seed
> sources. Well, they both use the same machine instruction to get the
> seed material but it's called from completely different places.
>
>
> Yes, the man pages could be more informative and user friendly :(
>
>
> Pauli
>
> On 10/11/21 12:35 pm, Blumenthal, Uri - 0553 - MITLL wrote:
> > "man config" for OpenSSL-3.0 and newer says that there can be
"[random]" section in "openssl.cnf", where I can specify type of RNG, other
things, and *seed*, and seed *properties*.
> >
> > Unfortunately, it did not bother to even list the possible/allowed
values, let alone explain what they'd mean:
> >
> > Random Configuration
> > The name random in the initialization section names the
section containing the random number
> > generater settings.
> >
> > Within the random section, the following names have
meaning:
> >
> > random
> > This is used to specify the random bit generator. For
example:
> >
> > [random]
> > random = CTR-DRBG
> >
> > The available random bit generators are:
> >
> > CTR-DRBG
> > HASH-DRBG
> >
Re: OpenSSL-3.+ how to configure [random]?
There is documentation: https://www.openssl.org/docs/man3.0/man5/config.html
I don't think the rdrand engine takes any extras.
Pauli
On 10/11/21 1:38 pm, Blumenthal, Uri - 0553 - MITLL wrote:
On 11/9/21, 22:23, "Dr Paul Dale" wrote:
Currently I've no idea and can't reproduce locally :(
Maybe you'd know how to force the "-engine rdrand" path through "openssl.cnf"?
A rogue configuration file could cause the DRBGs/seeds to fail. Do you
have seed=rdrand line in the random section? That will cause the
seeding source to fail to load at all.
No, I don't - and providing empty config causes the same result:
$ OPENSSL_CONF=/dev/null openssl3 rand -hex 4
$ OPENSSL_CONF=/dev/null openssl3 rand -engine rdrand -hex 4
Engine "rdrand" set.
61f1666d
$
Pauli
On 10/11/21 1:10 pm, Blumenthal, Uri - 0553 - MITLL wrote:
> Thank you!
>
> I'm trying to:
>
> a. understand why something like "openssl-3 rand -hex 4" does not work (returns
empty string), but "openssl-3 rand -engine rdrand -hex 4" works fine, and gives me my random
bytes - here's an illustration
>
> $ openssl3 version
> OpenSSL 3.1.0-dev (Library: OpenSSL 3.1.0-dev )
> $ openssl3 info -seeds
> rdrand ( rdseed rdrand ) os-specific
> $ openssl3 rand -hex 4
> $ openssl3 rand -engine rdrand -hex 4
> Engine "rdrand" set.
> d9b8f268
>
> and
>
> b. somehow force RDRAND engine to be loaded and initialized by default, so I don't have to
include "-engine rdrand" in every invocation, especially since I often need to specify other
engines (like "pkcs11").
>
> Here's my config, in case you spot something wrong with it (and yes, it includes
"rdcpu"):
>
> ./config --prefix=${OPENSSL_DIR} --debug --openssldir=${OPENSSL_DIR}/etc
--with-rand-seed=rdcpu,os enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5
enable-rmd160 enable-weak-ssl-ciphers zlib-dynamic enable-ssl-trace enable-trace
threads enable-buildtest-c++
>
> Thanks
> --
> Regards,
> Uri
>
> There are two ways to design a system. One is to make is so simple there
are obviously no deficiencies.
> The other is to make it so complex there are no obvious deficiencies.
>
- C. A. R. Hoare
>
>
> On 11/9/21, 21:49, "openssl-users on behalf of Dr Paul Dale"
wrote:
>
> Currently there is exactly one seed source that is usable in OpenSSL
> 3.0: "SEED-SRC". It is documented in EVP_RAND-SEED-SRC. The
reason the
> seed source can be set is to allow you to use a third party provider
> than includes one.
>
> If you want to force RDRAND as the only seeding source, this needs
to be
> done at configuration time with the --with-rand-seed configuration
> option. Note that this will enable RDSEED in preference to RDRAND
but
> will use RDRAND if RDSEED isn't available.
>
> I assume that you meant openssl info -seeds not openssl list -seeds.
> This lists the seed sources that were configured at build time.
>
>
> There is no relationship between the RDRAND engine and the seed
> sources. Well, they both use the same machine instruction to get
the
> seed material but it's called from completely different places.
>
>
> Yes, the man pages could be more informative and user friendly :(
>
>
> Pauli
>
> On 10/11/21 12:35 pm, Blumenthal, Uri - 0553 - MITLL wrote:
> > "man config" for OpenSSL-3.0 and newer says that there can be "[random]"
section in "openssl.cnf", where I can specify type of RNG, other things, and *seed*, and seed
*properties*.
> >
> > Unfortunately, it did not bother to even list the
possible/allowed values, let alone explain what they'd mean:
> >
> > Random Configuration
> > The name random in the initialization section names the
section containing the random number
> > generater settings.
> >
> > Within the random section, the following names have
meaning:
> >
> > random
> > This is used to specify the random bit generator.
For example:
> >
> > [random]
Re: OpenSSL-3.+ how to configure [random]?
Thank you!
I'm trying to:
a. understand why something like "openssl-3 rand -hex 4" does not work (returns
empty string), but "openssl-3 rand -engine rdrand -hex 4" works fine, and gives
me my random bytes - here's an illustration
$ openssl3 version
OpenSSL 3.1.0-dev (Library: OpenSSL 3.1.0-dev )
$ openssl3 info -seeds
rdrand ( rdseed rdrand ) os-specific
$ openssl3 rand -hex 4
$ openssl3 rand -engine rdrand -hex 4
Engine "rdrand" set.
d9b8f268
and
b. somehow force RDRAND engine to be loaded and initialized by default, so I
don't have to include "-engine rdrand" in every invocation, especially since I
often need to specify other engines (like "pkcs11").
Here's my config, in case you spot something wrong with it (and yes, it
includes "rdcpu"):
./config --prefix=${OPENSSL_DIR} --debug --openssldir=${OPENSSL_DIR}/etc
--with-rand-seed=rdcpu,os enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5
enable-rmd160 enable-weak-ssl-ciphers zlib-dynamic enable-ssl-trace
enable-trace threads enable-buildtest-c++
Thanks
--
Regards,
Uri
There are two ways to design a system. One is to make is so simple there are
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
- C. A. R. Hoare
On 11/9/21, 21:49, "openssl-users on behalf of Dr Paul Dale"
wrote:
Currently there is exactly one seed source that is usable in OpenSSL
3.0: "SEED-SRC". It is documented in EVP_RAND-SEED-SRC. The reason the
seed source can be set is to allow you to use a third party provider
than includes one.
If you want to force RDRAND as the only seeding source, this needs to be
done at configuration time with the --with-rand-seed configuration
option. Note that this will enable RDSEED in preference to RDRAND but
will use RDRAND if RDSEED isn't available.
I assume that you meant openssl info -seeds not openssl list -seeds.
This lists the seed sources that were configured at build time.
There is no relationship between the RDRAND engine and the seed
sources. Well, they both use the same machine instruction to get the
seed material but it's called from completely different places.
Yes, the man pages could be more informative and user friendly :(
Pauli
On 10/11/21 12:35 pm, Blumenthal, Uri - 0553 - MITLL wrote:
> "man config" for OpenSSL-3.0 and newer says that there can be "[random]"
section in "openssl.cnf", where I can specify type of RNG, other things, and
*seed*, and seed *properties*.
>
> Unfortunately, it did not bother to even list the possible/allowed
values, let alone explain what they'd mean:
>
> Random Configuration
> The name random in the initialization section names the section
containing the random number
> generater settings.
>
> Within the random section, the following names have meaning:
>
> random
> This is used to specify the random bit generator. For
example:
>
> [random]
> random = CTR-DRBG
>
> The available random bit generators are:
>
> CTR-DRBG
> HASH-DRBG
> HMAC-DRBG
> . . . . .
> properties
> This sets the property query used when fetching the random
bit generator and any
> underlying algorithms.
>
> seed
> This sets the randomness source that should be used. By
default SEED-SRC will be used
> outside of the FIPS provider. The FIPS provider uses call
backs to access the same
> randomness sources from outside the validated boundary.
>
> seed_properties
> This sets the property query used when fetching the
randomness source.
>
> I want to configure this [random] to use CTR-DRBG, using RDRAND as
"seed". Based on "openssl list -seeds", I guess "seed = rdrand" should be OK.
What properties can I set, if any? How does this "[random]" relate to the
RDRAND *engine* (see below)?
>
> $ openssl3 engine rdrand -t
> (rdrand) Intel RDRAND engine
> [ available ]
>
>
> Thanks!
> --
> Regards,
> Uri Blumenthal Voice: (781) 981-1638
> Secure Resilient Systems and Technologies Cell: (339) 223-5363
> MIT Lincoln Laboratory
> 244 Wood Street, Lexington, MA 02420-9108
>
> We
Re: OpenSSL-3.+ how to configure [random]?
Currently I've no idea and can't reproduce locally :(
A rogue configuration file could cause the DRBGs/seeds to fail. Do you
have seed=rdrand line in the random section? That will cause the
seeding source to fail to load at all.
Pauli
On 10/11/21 1:10 pm, Blumenthal, Uri - 0553 - MITLL wrote:
Thank you!
I'm trying to:
a. understand why something like "openssl-3 rand -hex 4" does not work (returns empty
string), but "openssl-3 rand -engine rdrand -hex 4" works fine, and gives me my random
bytes - here's an illustration
$ openssl3 version
OpenSSL 3.1.0-dev (Library: OpenSSL 3.1.0-dev )
$ openssl3 info -seeds
rdrand ( rdseed rdrand ) os-specific
$ openssl3 rand -hex 4
$ openssl3 rand -engine rdrand -hex 4
Engine "rdrand" set.
d9b8f268
and
b. somehow force RDRAND engine to be loaded and initialized by default, so I don't have to include
"-engine rdrand" in every invocation, especially since I often need to specify other
engines (like "pkcs11").
Here's my config, in case you spot something wrong with it (and yes, it includes
"rdcpu"):
./config --prefix=${OPENSSL_DIR} --debug --openssldir=${OPENSSL_DIR}/etc
--with-rand-seed=rdcpu,os enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5
enable-rmd160 enable-weak-ssl-ciphers zlib-dynamic enable-ssl-trace
enable-trace threads enable-buildtest-c++
Thanks
--
Regards,
Uri
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
- C. A. R. Hoare
On 11/9/21, 21:49, "openssl-users on behalf of Dr Paul Dale"
wrote:
Currently there is exactly one seed source that is usable in OpenSSL
3.0: "SEED-SRC". It is documented in EVP_RAND-SEED-SRC. The reason the
seed source can be set is to allow you to use a third party provider
than includes one.
If you want to force RDRAND as the only seeding source, this needs to be
done at configuration time with the --with-rand-seed configuration
option. Note that this will enable RDSEED in preference to RDRAND but
will use RDRAND if RDSEED isn't available.
I assume that you meant openssl info -seeds not openssl list -seeds.
This lists the seed sources that were configured at build time.
There is no relationship between the RDRAND engine and the seed
sources. Well, they both use the same machine instruction to get the
seed material but it's called from completely different places.
Yes, the man pages could be more informative and user friendly :(
Pauli
On 10/11/21 12:35 pm, Blumenthal, Uri - 0553 - MITLL wrote:
> "man config" for OpenSSL-3.0 and newer says that there can be "[random]" section
in "openssl.cnf", where I can specify type of RNG, other things, and *seed*, and seed *properties*.
>
> Unfortunately, it did not bother to even list the possible/allowed
values, let alone explain what they'd mean:
>
> Random Configuration
> The name random in the initialization section names the section
containing the random number
> generater settings.
>
> Within the random section, the following names have meaning:
>
> random
> This is used to specify the random bit generator. For
example:
>
> [random]
> random = CTR-DRBG
>
> The available random bit generators are:
>
> CTR-DRBG
> HASH-DRBG
> HMAC-DRBG
> . . . . .
> properties
> This sets the property query used when fetching the random
bit generator and any
> underlying algorithms.
>
> seed
> This sets the randomness source that should be used. By
default SEED-SRC will be used
> outside of the FIPS provider. The FIPS provider uses call
backs to access the same
> randomness sources from outside the validated boundary.
>
> seed_properties
> This sets the property query used when fetching the
randomness source.
>
> I want to configure this [random] to use CTR-DRBG, using RDRAND as "seed". Based on "openssl list
-seeds", I guess "seed = rdrand" should be OK. What properties can I set, if any? How does this
"[random]" relate to the RDRAND *engine* (see below)?
>
> $ openssl3 engine rdrand -t
> (rdrand) Intel RDRAND engine
> [ available ]
Openssl 3.0 fipsinstall fails in yocto linux environment
I've successfully built and installed openssl 3.0 and the fips.so module in my yocto build environment. My goal is to make the FIPs module the default provider for all applications so I modified my openssl.cnf file to match the docs like the following. config_diagnostics = 1 openssl_conf = openssl_init .include /usr/lib/ssl-3/fipsmodule.cnf [openssl_init] providers = provider_sect [provider_sect] fips = fips_sect base = base_sect [base_sect] activate = 1 After boot, I check the installed providers with "openssl list -providers" and see only the base provider. I then try to install the FIPS module with the following. openssl fipsinstall -module /usr/lib/ossl-modules/fips.so -out /usr/lib/ssl-3/fipsmodule.cnf and I get the error output: Unable to get MAC of type HMAC INSTALL FAILED 1020F876:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:../openssl-3.0.0/crypto/evp/evp _fetch.c:346:Global default library context, Algorithm (HMAC : 0), Properties () When I replace the base provider with the default provider, leaving the fips module like the following config_diagnostics = 1 openssl_conf = openssl_init .include /usr/lib/ssl-3/fipsmodule.cnf [openssl_init] providers = provider_sect [provider_sect] default = default_sect fips = fips_sect [default_sect] activate = 1 I see only the default provider installed after I boot and when I try to manually install the FIPS module with the above command I get the following. Failed to load FIPS module INSTALL FAILED 1080F176:error:1C8000D4:Provider routines:SELF_TEST_post:invalid state:../openssl-3.0.0/providers/fips/self_test.c:261: 1080F176:error:1C8000D8:Provider routines:OSSL_provider_init_int:self test post failure:../openssl-3.0.0/providers/fips/fipsprov.c:706: 1080F176:error:078C0105:common libcrypto routines:provider_init:init fail:../openssl-3.0.0/crypto/provider_core.c:903:name=fips >From this state, if I copy the ossl-modules directory to a different location like /usr/lib/ssl-3/ and try to manually install the FIPS module with openssl fipsinstall -module /usr/lib/ssl-3/ossl-modules/fips.so -out /usr/lib/ssl-3/fipsmodule.cnf it successful installs with the following output and I see both the fips and default providers installed. HMAC : (Module_Integrity) : Pass SHA1 : (KAT_Digest) : Pass SHA2 : (KAT_Digest) : Pass SHA3 : (KAT_Digest) : Pass TDES : (KAT_Cipher) : Pass AES_GCM : (KAT_Cipher) : Pass AES_ECB_Decrypt : (KAT_Cipher) : Pass RSA : (KAT_Signature) : RNG : (Continuous_RNG_Test) : Pass Pass ECDSA : (PCT_Signature) : Pass ECDSA : (PCT_Signature) : Pass DSA : (PCT_Signature) : Pass TLS13_KDF_EXTRACT : (KAT_KDF) : Pass TLS13_KDF_EXPAND : (KAT_KDF) : Pass TLS12_PRF : (KAT_KDF) : Pass PBKDF2 : (KAT_KDF) : Pass SSHKDF : (KAT_KDF) : Pass KBKDF : (KAT_KDF) : Pass HKDF : (KAT_KDF) : Pass SSKDF : (KAT_KDF) : Pass X963KDF : (KAT_KDF) : Pass X942KDF : (KAT_KDF) : Pass HASH : (DRBG) : Pass CTR : (DRBG) : Pass HMAC : (DRBG) : Pass DH : (KAT_KA) : Pass ECDH : (KAT_KA) : Pass RSA_Encrypt : (KAT_AsymmetricCipher) : Pass RSA_Decrypt : (KAT_AsymmetricCipher) : Pass RSA_Decrypt : (KAT_AsymmetricCipher) : Pass INSTALL PASSED I need to get the FIPS module to install without needing the default provider. It seems like the FIPS module is trying to install and getting stuck in a bad state, but I could use some help debugging this. Thanks for any help you can provide. Susan
Re: Openssl 3.0 fipsinstall fails in yocto linux environment
Hi Susan, How did you run Configure? Are you cross compiling? Be default, OpenSSL 3.0.0 builds for /usr/local. Your MUST install it there or use a Configure option if you want to install it somewhere else. Kory > On Nov 9, 2021, at 2:21 PM, Susan Tremel wrote: > > I’ve successfully built and installed openssl 3.0 and the fips.so module in > my yocto build environment. My goal is to make the FIPs module the default > provider for all applications so I modified my openssl.cnf file to match the > docs like the following. > > config_diagnostics = 1 > openssl_conf = openssl_init > > .include /usr/lib/ssl-3/fipsmodule.cnf > > [openssl_init] > providers = provider_sect > > [provider_sect] > fips = fips_sect > base = base_sect > > [base_sect] > activate = 1 > > After boot, I check the installed providers with “openssl list –providers” > and see only the base provider. I then try to install the FIPS module with > the following. > > openssl fipsinstall –module /usr/lib/ossl-modules/fips.so –out > /usr/lib/ssl-3/fipsmodule.cnf > > and I get the error output: > Unable to get MAC of type HMAC > INSTALL FAILED > 1020F876:error:0308010C:digital envelope > routines:inner_evp_generic_fetch:unsupported:../openssl-3.0.0/crypto/evp/evp_fetch.c:346:Global > default library context, Algorithm (HMAC : 0), Properties () > > When I replace the base provider with the default provider, leaving the fips > module like the following > > config_diagnostics = 1 > openssl_conf = openssl_init > > .include /usr/lib/ssl-3/fipsmodule.cnf > > [openssl_init] > providers = provider_sect > > [provider_sect] > default = default_sect > fips = fips_sect > > [default_sect] > activate = 1 > > I see only the default provider installed after I boot and when I try to > manually install the FIPS module with the above command I get the following. > Failed to load FIPS module > INSTALL FAILED > 1080F176:error:1C8000D4:Provider routines:SELF_TEST_post:invalid > state:../openssl-3.0.0/providers/fips/self_test.c:261: > 1080F176:error:1C8000D8:Provider routines:OSSL_provider_init_int:self test > post failure:../openssl-3.0.0/providers/fips/fipsprov.c:706: > 1080F176:error:078C0105:common libcrypto routines:provider_init:init > fail:../openssl-3.0.0/crypto/provider_core.c:903:name=fips > > From this state, if I copy the ossl-modules directory to a different location > like /usr/lib/ssl-3/ and try to manually install the FIPS module with > > openssl fipsinstall –module /usr/lib/ssl-3/ossl-modules/fips.so –out > /usr/lib/ssl-3/fipsmodule.cnf > > it successful installs with the following output and I see both the fips and > default providers installed. > HMAC : (Module_Integrity) : Pass > SHA1 : (KAT_Digest) : Pass > SHA2 : (KAT_Digest) : Pass > SHA3 : (KAT_Digest) : Pass > TDES : (KAT_Cipher) : Pass > AES_GCM : (KAT_Cipher) : Pass > AES_ECB_Decrypt : (KAT_Cipher) : Pass > RSA : (KAT_Signature) : RNG : (Continuous_RNG_Test) : Pass > Pass > ECDSA : (PCT_Signature) : Pass > ECDSA : (PCT_Signature) : Pass > DSA : (PCT_Signature) : Pass > TLS13_KDF_EXTRACT : (KAT_KDF) : Pass > TLS13_KDF_EXPAND : (KAT_KDF) : Pass > TLS12_PRF : (KAT_KDF) : Pass > PBKDF2 : (KAT_KDF) : Pass > SSHKDF : (KAT_KDF) : Pass > KBKDF : (KAT_KDF) : Pass > HKDF : (KAT_KDF) : Pass > SSKDF : (KAT_KDF) : Pass > X963KDF : (KAT_KDF) : Pass > X942KDF : (KAT_KDF) : Pass > HASH : (DRBG) : Pass > CTR : (DRBG) : Pass > HMAC : (DRBG) : Pass > DH : (KAT_KA) : Pass > ECDH : (KAT_KA) : Pass > RSA_Encrypt : (KAT_AsymmetricCipher) : Pass > RSA_Decrypt : (KAT_AsymmetricCipher) : Pass > RSA_Decrypt : (KAT_AsymmetricCipher) : Pass > INSTALL PASSED > > I need to get the FIPS module to install without needing the default > provider. It seems like the FIPS module is trying to install and getting > stuck in a bad state, but I could use some help debugging this. > > Thanks for any help you can provide. > Susan
Re: FIPS seed_pid issue
On Sun, Oct 14, 2012, Kumar Ghanta wrote: Thank you very much for the quick response Stephen. Is it fine if we allow parent and child processes to share the same seed? I just want to know if there are any NIST restrictions. If possible, can you please elaborate on how does openssl takes care automatically after 1.2? If two processes share the same PRNG state then it has several security issues: for example DSA private keys can be leaked. Later versions of the PRNG (and DRBG) mix (among other things) the current process ID into the internal state when random numbers are generated. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS_selftest fails under windows dynamic linking
On 02/20/2013 09:10 AM, Rickard Binnare wrote: ... Here is a minimalistic test program that displays this anomaly. Dynamic linked. It could easily be modified to show OpenSSL error msgs. ... I think the detailed error messages are relevant there. Perhaps you're seeing a DRBG seeding problem (entropy being an application responsibility)? BTW note that FIPS_selftest() has no practical value; it was defined as an external function call only because such a function is mandated by FIPS 140-2. I can't think of any real-world circumstance in which calling that function would make sense. I think if this function is mandated by FIPS 140-2 it should be possible to call it, regardless of platform and if the program is static or dynamically linked. Ah, but you can call it :-). -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl-1.0.1/FIPS-2.0 FIPS_selftest() fails after successful FIPS_mode_set(1)
On Fri, Feb 17, 2012, gatewood_gr...@mcafee.com wrote: Tested with snapshots 20120216 After compiling openssl-fips-2.0 I get a working fips_test_suite. I compile openssl-1.0.1 and then link a simple a simple application (we'll can fips_can_test, see below). compiling like so: CC=/usr/local/ssl32/bin/fipsld FIPSLD_CC=gcc -m32 /usr/local/ssl32/bin/fipsld fips_can_test.c \ -L /usr/lib -lcrypto -o fips_can_test32 -I/usr/include -I/usr/local/ssl32/include Hmm... works fine here. The only thing I can immediately think of is that the PRNG seeding doesn't function correctly. Those specific tests require the PRNG (DRBG in this case) to produce random data for the operation. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] FIPS: Which DRBG ?
From: Steve Marquess marqu...@openssl.com Date: 03/24/15 12:38 No, the OpenSSL FIPS module 2.0 code is no longer suitable (as of early 2014) for use as-is in doing copycat validations. Some non-trivial code hacks will be necessary. We'll do a new open source based validation to succeed the 2.0 FIPS module (#1747 validation) at the first opportunity, but that opportunity has not yet presented itself. I still do not know that much about the validation in practical terms. If our units go through validation, can this benefit OpenSSL ? Also, to go back to the SP 800-90 vs. SP 800-90A regarding the DRBGs, do you know how would the OpenSSL SP 800-90 validation fare in a FIPS testing lab since the Dual EC was removed and the other three were not touched ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fips CTR_DRBG
Thanks a lot, adding this flag did the trick. The returned block is identical as the expected. Dnia 2015-02-27, pią o godzinie 12:54 +, Dr. Stephen Henson pisze: On Fri, Feb 27, 2015, Piotr ??obacz wrote: I can do mutch more i can give the source code: dctx = FIPS_drbg_new(NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF); Try including the flag DRBG_FLAG_TEST: the DRBG needs to be in test mode otherwise the continuous PRNG test discards the first block generated. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Piotr Łobacz Biuro Systemów i Oprogramowania RADMOR S.A. tel. (58) 6996 929 e-mail: piotr.lob...@radmor.com.pl www.radmor.com.pl RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia NIP: 586-010-21-39 REGON: 190432077 KRS: 074029 (Sąd Rejonowy Gdańsk-Północ w Gdańsku) Kapitał zakładowy wpłacony: 9 282 830 PLN ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fips CTR_DRBG
On Thu, Feb 26, 2015, Piotr ??obacz wrote: Yes, i have read that RAND API will use CTR_DRBG by default but what if i want to have set seed and than calculate and have the same results on two different machines? As far as i understand if i set seed - which is calculated from entropy, nonce and personal string - if it is given i should get some deterministic value of returned buffer and RAND_bytes doesn't give me such result it is always different. Correct me if i am wrong. OK, can you give some details of how you are instantiating the DRBG? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] conversion of RAND_bytes to rand in fips apporved way
On Wed, Jul 25, 2018 at 11:42:34PM +0530, Sudarshan Soma wrote: > Now few applications are using libc rand function. For FIPS compliance, > applications have to call approved SP 800-90A DRBG implementation. If you're using libc's rand() for non-cryptographic purposes, you can surely continue to do that. > I was planning to replace libc rand with RAND_bytes for the same. > > But rand() returns max value of 32767. Is there a recomended way to > convert RAND_bytes to libc rand() something like this? Since 16-bit random numbers do not provide any meaningful security, it makes little sense to use a CSPRNG in a context where 16-bit random values are sufficient. > Please suggest. Is there a way to give number of bits instead of bytes to > RAND_bytes? This is probably the wrong question. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RNG behavior by default
Steffen Nurpmeso wrote in <20190107183136.-ew61%stef...@sdaoden.eu>: ... | ... ||RAND_bytes() has always documented that it can fail. Most function ... |So, to me.., i do not see any possible error condition, since the |initial seeding has been testified with RAND_status(). | |This is different now, and i will change the implementation as |soon as possible. (This week.) So i did, we disable the OpenSSL reseeding by directly calling RAND_DRBG_set_reseed_defaults() after calling OPENSSL_init_ssl(), which i hope will always be possible. Be warned that i gave credit to both of you. I have seen DRBG offers a lot of possibilities to control what OpenSSL does, also regarding the fork handlers and all that. Thanks for these possibilities, it is a terribly huge interface, but it allows users to have control on what happens, instead of sitting on an intransparent black box! Getting something going on such a thing causes grief, as it is hacky and otherwise troublesome! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?
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
RE: Regarding RAND_set_rand_method
Re Q1: I want to know is there any way to avoid this problem? I want thread T2 to call default RAND methods and avoid calling methods set by thread T1. This is not only for RAND methods, but for any other methods. First of all, I agree with Pauli: your first question should be, why do you need different random generators for different threads in the same application? Is this necessary, or are you overengineering? Let me clarify some details about the RNG implemention in OpenSSL 1.1.1.: The RAND_METHOD interface itself is not thread aware. It is only the new default RAND_METHOD implementation (added in 1.1.1.) of OpenSSL (RAND_OpenSSL()), which supports thread local random generators. The implementation is based on deterministic random bit generators (DRBG) as described in NIST.SP.800-90Ar1. Wenn a thread calls RAND_bytes() (resp. RAND_priv_bytes()), the call is forwarded to the thread-specific DRBG instance. All per-thread instances reseed from a single global DRBG instance, which in turn reseeds from from random sources provided by the operating system. In your case, by replacing the RAND_METHOD, you are changing the complete RAND implementation for all threads. Moreover, you are completely responsible yourself for reseeding your RNG properly. You could however implement a smarter RAND_METHOD which calls your specific RNG for T1 and delegates to the thread local DRBG (RAND_DRBG_get0_public() resp. RAND_DRBG_get0_private()) for all other threads. To get an idea how it can be done, take a look at the default implementation of RAND_bytes(), drbg_bytes() in drbg_lib.c: https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L958-L970 Re Q2: Also, is it possible to run OpenSSL as separate instance per thread (where each thread can do its own OpenSSL initialization) so that they can avoid above mentioned problem? No. If you really need something like that, you might want to consider splitting your two threads into two processes. HTH, Matthias From: openssl-users On Behalf Of Dr Paul Dale Sent: Friday, April 2, 2021 8:51 AM To: openssl-users@openssl.org Subject: Re: Regarding RAND_set_rand_method There isn't an easy a way to do what you want in 1.1.1. RAND_set_rand_method replaces the RNG for all of OpenSSL. In theory your RAND_METHOD could detect which thread it is running in and do different things for each. I'm not sure this is a good idea however. Why aren't the random number from your first thread good enough for the second? Good random numbers are just that - random. It should be impossible to distinguish the two streams. In OpenSSL 3.0 there are ways to achieve what you're wanting. Pauli On 2/4/21 4:24 pm, Vishwanath Mahajanshetty wrote: Hi, I have some doubts/questions on how to use methods (for ex: RAND_set_rand_method) in multi threaded application which use OpenSSL. In my application (running on OpenSSL 1.1.1d) there are two threads which use OpenSSL, both threads perform very different operations. The issue I am facing is as below: Thread T1 calls RAND_set_rand_method() and sets RAND_METHOD structure. This is very specific to T1s use case. When thread T2 wants to create SSL_CTX it calls SSL_CTX_new() which then calls RAND_priv_bytes(). I am observing that the function RAND_priv_bytes() is calling the function set by T1 by RAND_METHOD in RAND_set_rand_method(). Essentially RAND_METHOD function set by thread T1 are getting called by thread T2. Q1: I want to know is there any way to avoid this problem? I want thread T2 to call default RAND methods and avoid calling methods set by thread T1. This is not only for RAND methods, but for any other methods. Q2: Also, is it possible to run OpenSSL as separate instance per thread (where each thread can do its own OpenSSL initialization) so that they can avoid above mentioned problem? Thank you, Vishwanath M smime.p7s Description: S/MIME cryptographic signature
RE: openssl-users Digest, Vol 77, Issue 6
Hi Matthias,
I tried the changes you suggested, it works well. Now T1 can call its own RNG
and T2 calls its local DRBG. I don’t find any reasons why it can’t be done this
way, may be there are some hidden issues which I have not seen yet but as of
now it looks to be working fine. Thank you very much Matthias and Paul for your
help on this.
Regards,
Vishwanath M
From: Dr. Matthias St. Pierre<mailto:matthias.st.pie...@ncp-e.com>
Sent: 05 April 2021 03:22 PM
To: Dr Paul Dale<mailto:pa...@openssl.org>; Vishwanath
Mahajanshetty<mailto:mahajanshe...@outlook.com>;
openssl-users@openssl.org<mailto:openssl-users@openssl.org>
Subject: RE: openssl-users Digest, Vol 77, Issue 6
> It isn't possible to do what you are wanting. RAND_METHOD replaces the RNG
> everywhere. It cannot be done on a per thread process.
Well, technically it *is* possible. However, I’m still in doubt whether it is
really necessary and should be done.
The following example assumes you are compiling for linux (or another unix-ish
os) and using pthreads:
Assume that you recorded the thread id of your thread T1 (which you obtained
from pthread_create())
in the static variable ‘tid1’. Then you could take the code from [1] and modify
it as follows:
```
static int my_rand_bytes(unsigned char *out, int count)
{
int ret;
if (pthread_equal(pthread_self(), tid1) {
// ... call your special RNG here
} else {
RAND_DRBG *drbg = RAND_DRBG_get0_public();
if (drbg == NULL)
return 0;
ret = RAND_DRBG_bytes(drbg, out, count);
}
return ret;
}
```
This is just a rough sketch, note that there are more RAND_METHODs to be
considered [2].
Matthias
[1]
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L958-L970
[2]
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L1146-L1153
[NCP engingeering GmbH]
Dr. Matthias St. Pierre
Senior Software Engineer
matthias.st.pie...@ncp-e.com
Phone: +49 911 9968-0
www.ncp-e.com
Follow us on:
Facebook<https://www.facebook.com/NCPengineering> |
Twitter<https://twitter.com/NCP_engineering> |
Xing<https://www.xing.com/companies/ncpengineeringgmbh> |
YouTube<https://www.youtube.com/user/NCPengineeringGmbH> |
LinkedIn<http://www.linkedin.com/company/ncp-engineering-inc.?trk=cws-cpw-coname-0-0>
Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 • 90449 •
Nuremberg
North American HQ: NCP engineering Inc. • 601 Cleveland Str., Suite 501-25 •
Clearwater, FL 33755
Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich
Registry Court: Lower District Court of Nuremberg
Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE
133557619
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
Längere Support-Antwortzeiten durch erhöhtes Anfrage-Aufkommen
Aufgrund des anhaltend hohen Anfrage-Aufkommens im Bereich Support und System
Engineering kann es aktuell zu längeren Antwortzeiten kommen. Wir setzen alles
daran, Ihre Anfragen so schnell wie möglich zu beantworten. Wir bitten Sie hier
vorsorglich um Geduld und danken Ihnen für Ihr Verständnis.
Longer support response times due to high number of requests
Due to the continuing high volume of requests, support and system engineering
response times may be longer than expected at present. We will do our best to
answer your requests as soon as possible. We ask for your patience during this
time and appreciate your understanding.
This e-mail message including any attachments is for the sole use of the
intended recipient(s) and may contain privileged or confidential information.
Any unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please immediately contact the sender by reply
e-mail and delete the original message and destroy all copies thereof.
From: openssl-users On Behalf Of Dr Paul
Dale
Sent: Monday, April 5, 2021 3:18 AM
To: openssl-users@openssl.org
Subject: Re: openssl-users Digest, Vol 77, Issue 6
Vishwanath,
It isn't possible to do what you are wanting. RAND_METHOD replaces the RNG
everywhere. It cannot be done on a per thread process.
Pauli
On 4/4/21 9:55 pm, Vishwanath Mahajanshetty wrote:
Hi Paul,
Thanks for your response. I understand the concern for good random numbers; but
in this scenario when second thread calls SSL_CTX_new it is waiting forever in
RAND_priv_bytes(). Looks like entropy functions defined by first (bind) thread
are very specific for its own use case and can’t be used by other treads.
So I am thinking of using default OpenSSL RAND_METHOD for second thread and
keep first thread
OpenSSL 3.0.0 custom entropy source
Hi, We are upgrading from OpenSSL 1.0.1g+OpenSSL-FIPS-2.0.5 to 3.0.0. Yes, I know, big jump. We have our own entropy source we use to seed the OpenSSL DRBG. This is a basic code snippet of how we set it up: DRBG_CTX *dctx = FIPS_get_default_drbg(); FIPS_drbg_init(dctx, NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF); FIPS_drbg_set_callbacks(dctx, rand_get_entropy, rand_free_entropy, 0, rand_get_entropy, rand_free_entropy); Error checking has been removed in the example for the sake of brevity. I am trying to figure out how to implement this with OpenSSL 3. From what I have read in the docs, I need to create a rand provider. But I still feel like I don’t understand how it all fit together. I did look at fuzz_rand.c and fake_rand.c, and if I understood everything correctly, neither of them use an external entropy/seed source. Are there better examples of what I am looking for? Thanks, Kory
