Hi,
What is the Number of Bytes Returned by aes-256 ctr drbg ?
Thanks,
Nagarjun
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
/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
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
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
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
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
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)
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
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
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
cks)
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 rando
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_insta
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
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
ecify 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 fetc
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
. 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
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
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
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
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
-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
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
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
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
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
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
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
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 i
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
t;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 a
> 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
an
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
ection, 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
HM
:\ 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
DRBG P-521 SHA512 test started
DRBG P-521 SHA512 test OK
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 additi
or 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
signed char *out, int count)
{
int ret;
if (pthread_equal(pthread_self(), tid1) {
// ... call your special RNG here
} else {
RAND_DRBG *drbg = RAND_DRBG_get0_
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
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 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
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
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
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
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
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
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
hat they'd mean:
> >
> > Random Configuration
> > The name random in the initialization section names the
section containing the random number
> > generater settings.
> >
> > Within the ran
> > 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:
>
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.
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
>
T_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
nuous_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 :
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
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
. 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
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
(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
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
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 co
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 bla
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
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
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
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
1 - 100 of 148 matches
Mail list logo
