Randomness generation standards
Hi all, I am required to implement the four DRBGs specified in SP 800-90 (HASH, HMAC, CTR, DUAL_EC). I previously received help from this group on that and it works just fine. The client however also required the following ...and ANS X9.62-2005 (HMAC) on the randomness. I am unsure on how to enforce this via the API. What I did was to use the NID_X9_62_prime256v1 curve on the DUAL_EC DRBG. Is this ok? I am confused since the requirement states in brackets at the end: HMAC. Can anybody direct me to something I should have read. Unfortunately I do not have access to the X9 specs. Regards Leon Brits
Re: Randomness generation standards
On Wed, Jan 15, 2014, Leon Brits wrote: Hi all, I am required to implement the four DRBGs specified in SP 800-90 (HASH, HMAC, CTR, DUAL_EC). I previously received help from this group on that and it works just fine. The client however also required the following ...and ANS X9.62-2005 (HMAC) on the randomness. I am unsure on how to enforce this via the API. What I did was to use the NID_X9_62_prime256v1 curve on the DUAL_EC DRBG. Is this ok? I am confused since the requirement states in brackets at the end: HMAC. Can anybody direct me to something I should have read. Unfortunately I do not have access to the X9 specs. Although X9.62-2005 mainly concerns ECC it also includes a DRBG which is equivalent to the HMAC DRBG of SP800-90, so it's the HMAC DRBG they want. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[PATCH] Reseed PRNG on PID change
Commit 3cd8547a2018ada88a4303067a2aa15eadc17f39 mixed the current time
into the randomness pool each time RAND_bytes is called. As the
resolution of gettimeofday() is limited, I propose to reseed the PRNG
each time a PID change is detected.
This change might also be an alternative for platforms where the
gettimeofday() call is prohibitively slow.
--
Florian Weimer / Red Hat Product Security Team
commit 136a8da88ff52ad32f894fb0ecbcab5f4205ca49
Author: Florian Weimer fwei...@redhat.com
Date: Wed Jan 15 16:46:17 2014 +0100
ssleay_rand_bytes: Re-seed on PID change
diff --git a/crypto/rand/md_rand.c b/crypto/rand/md_rand.c
index 6cab308..75382b5 100644
--- a/crypto/rand/md_rand.c
+++ b/crypto/rand/md_rand.c
@@ -153,6 +153,9 @@ static unsigned char md[MD_DIGEST_LENGTH];
static long md_count[2]={0,0};
static double entropy=0;
static int initialized=0;
+#ifndef GETPID_IS_MEANINGLESS
+static pid_t prev_pid=0;
+#endif
static unsigned int crypto_lock_rand = 0; /* may be set only when a thread
* holds CRYPTO_LOCK_RAND
@@ -201,6 +204,7 @@ static void ssleay_rand_cleanup(void)
md_count[1]=0;
entropy=0;
initialized=0;
+ prev_pid=0;
}
static int ssleay_rand_add(const void *buf, int num, double add)
@@ -439,7 +443,16 @@ static int ssleay_rand_bytes(unsigned char *buf, int num, int pseudo)
{
RAND_poll();
initialized = 1;
+ prev_pid = curr_pid;
+ }
+#ifndef GETPID_IS_MEANINGLESS
+ if (curr_pid != prev_pid)
+ {
+ RAND_poll();
+ prev_pid = curr_pid;
}
+#endif
+
if (!stirred_pool)
do_stir_pool = 1;
Re: [PATCH] Reseed PRNG on PID change
On Wed, Jan 15, 2014, Florian Weimer wrote: Commit 3cd8547a2018ada88a4303067a2aa15eadc17f39 mixed the current time into the randomness pool each time RAND_bytes is called. As the resolution of gettimeofday() is limited, I propose to reseed the PRNG each time a PID change is detected. I know historically some platforms have different PIDs for different threads. That would cause problems with this patch. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Reseed PRNG on PID change
Am Donnerstag, 16. Januar 2014, 07:41:21 schrieb Peter Waltenberg: Hi Peter, You have access to high speed event counters on most platforms now. Where those are available, use them for reseed data instead of gettimeofday(). Far higher resolution, far less performance impact. That implies, however, either hardware-specific code (i.e. special CPU instruction) or per operating system specific code (special system call, library call). Ciao Stephan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Reseed PRNG on PID change
The necessary code for MOST platforms is already in OpenSSL Look for OPENSSL_rdtsc in the crypto. directory. O.K. Not all platforms have this, but Sparc, x86/x86_64, s390, ppc, Itanium, apha,PA-RISC , ARM have some variant - admitted, quite a few hardware variants don't have a TSC, but that's determinable at runtime and you could drop back to gettimeofday() to cover those. It's at least better than gettimeofday() for this purpose - i.e. most of the bits can't be determined from outside the box, it moves faster, and it's cheaper to read. Peter From: Stephan Mueller smuel...@chronox.de To: openssl-dev@openssl.org, Date: 16/01/2014 07:45 Subject:Re: [PATCH] Reseed PRNG on PID change Sent by:owner-openssl-...@openssl.org Am Donnerstag, 16. Januar 2014, 07:41:21 schrieb Peter Waltenberg: Hi Peter, You have access to high speed event counters on most platforms now. Where those are available, use them for reseed data instead of gettimeofday(). Far higher resolution, far less performance impact. That implies, however, either hardware-specific code (i.e. special CPU instruction) or per operating system specific code (special system call, library call). Ciao Stephan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Reseed PRNG on PID change
Am Donnerstag, 16. Januar 2014, 08:11:32 schrieb Peter Waltenberg: Hi Peter, The necessary code for MOST platforms is already in OpenSSL Look for OPENSSL_rdtsc in the crypto. directory. O.K. Not all platforms have this, but Sparc, x86/x86_64, s390, ppc, Itanium, apha,PA-RISC , ARM have some variant - admitted, quite a few hardware variants don't have a TSC, but that's determinable at runtime and you could drop back to gettimeofday() to cover those. Great, then using these high-res timers should be definitely considered for the platforms where available (i.e. most common platforms). For any other platform, the gettimeofday can be called. It's at least better than gettimeofday() for this purpose - i.e. most of the bits can't be determined from outside the box, it moves faster, and it's cheaper to read. Agreed. Ciao Stephan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
