Re: [openssl.org #2753] AutoReply: Patch: let application explicitly seed RNG on Unix
Here is a better patch. The previous one caused problems for
applications that called RAND_bytes() (usually indirectly) before
any other RAND function -- like, say, the OpenSSH client.
Thor
Index: crypto/rand/md_rand.c
===
RCS file: /cvsroot/src/crypto/external/bsd/openssl/dist/crypto/rand/md_rand.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -r1.1.1.3 -r1.3
--- crypto/rand/md_rand.c 5 Jun 2011 14:59:27 - 1.1.1.3
+++ crypto/rand/md_rand.c 7 Mar 2012 10:17:47 - 1.3
@@ -141,7 +141,6 @@
static unsigned char md[MD_DIGEST_LENGTH];
static long md_count[2]={0,0};
static double entropy=0;
-static int initialized=0;
static unsigned int crypto_lock_rand = 0; /* may be set only when a thread
* holds CRYPTO_LOCK_RAND
@@ -187,7 +186,6 @@
md_count[0]=0;
md_count[1]=0;
entropy=0;
- initialized=0;
}
static void ssleay_rand_add(const void *buf, int num, double add)
@@ -389,18 +387,16 @@
CRYPTO_w_unlock(CRYPTO_LOCK_RAND2);
crypto_lock_rand = 1;
- if (!initialized)
- {
- RAND_poll();
- initialized = 1;
- }
-
if (!stirred_pool)
do_stir_pool = 1;
ok = (entropy = ENTROPY_NEEDED);
if (!ok)
{
+
+ RAND_poll();
+ ok = (entropy = ENTROPY_NEEDED);
+
/* If the PRNG state is not yet unpredictable, then seeing
* the PRNG output may help attackers to determine the new
* state; thus we have to decrease the entropy estimate.
@@ -571,11 +567,10 @@
CRYPTO_w_unlock(CRYPTO_LOCK_RAND2);
crypto_lock_rand = 1;
}
-
- if (!initialized)
+
+ if (entropy ENTROPY_NEEDED)
{
RAND_poll();
- initialized = 1;
}
ret = entropy = ENTROPY_NEEDED;
Index: crypto/rand/rand_unix.c
===
RCS file:
/cvsroot/src/crypto/external/bsd/openssl/dist/crypto/rand/rand_unix.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- crypto/rand/rand_unix.c 19 Jul 2009 23:30:41 - 1.2
+++ crypto/rand/rand_unix.c 5 Mar 2012 20:13:36 - 1.3
@@ -182,6 +182,16 @@
u_int32_t rnd = 0, i;
unsigned char buf[ENTROPY_NEEDED];
+ /*
+* XXX is this really a good idea? It has the seemingly
+* XXX very undesirable eventual result of keying the CTR_DRBG
+* XXX generator exclusively with key material produced by
+* XXX the libc arc4random(). It also guarantees that even
+* XXX if the generator tries to use RAND_poll() to rekey
+* XXX itself after a call to fork() etc, it will end up with
+* XXX the same state, since the libc arc4 state will be the same
+* XXX unless explicitly updated by the application.
+*/
for (i = 0; i sizeof(buf); i++) {
if (i % 4 == 0)
rnd = arc4random();
Re: [openssl.org #2755] [PATCH] DTLS does not lower MTU after retransmissions
On Mar 6, 2012, at 7:29 PM, Stephen Henson via RT wrote: [seggelm...@fh-muenster.de - Mon Mar 05 15:26:38 2012]: The DTLS implementation does not lower the assumed MTU after unsuccessful retransmissions, which results in a failing handshake in case fragmentation is necessary. With this patch the MTU is reduced to a safe value of 576 - 20 - 8 for IPv4 and 1280 - 40 - 8 for IPv6, respectively, after 2 retransmissions. Should this be applied to OpenSSL 0.9.8? The patch seems to work (with some complaints) but it wont compile. I forgot to add a patch for 0.9.8. The issue is that DTLS in 0.9.8 has no IPv6 support, so the sockaddr structures are different. That's why it doesn't compile. Is there any reason why the IPv6 patch was never applied? Since only IPv4 is possible, the attached version of the patch for 0.9.8 simply always returns the value for IPv4. Best regards Robin 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 dtls-timer-mtu-bug-0.9.8.patch Description: Binary data
[openssl.org #2756] [PATCH] DTLS timeout handling bug
DTLS does not handle timeouts correctly, because the timeout counter is reset every time anything has been received, and not only after a full handshake flight. The reset should only be done when the retransmission timer is stopped, otherwise the maximum number of retransmission is never met in case a flight always arrives incomplete, so retransmissions continue and the connection is not terminated. Additionally, the retransmission counter is not increased when the server retransmits its last flight, which is triggered by the retransmission of the client's last flight. This is a problem if the server's last flight exceeds the path MTU, for example. In this case the flight will never arrive at the client, because the server is not counting retransmissions and will not reduce its MTU, or simply give up when the maximum number of retransmissions is reached. Best regards Robin dtls-timeout-handling-bug-1.0.0.patch Description: Binary data dtls-timeout-handling-bug-1.0.1.patch Description: Binary data dtls-timeout-handling-bug-0.9.8.patch Description: Binary data
Re: [openssl.org #2569] [PATCH] EC_POINT_invert checks wrong function pointer
Bump. On Fri, Jul 22, 2011 at 2:49 AM, Billy Brumley via RT r...@openssl.org wrote: In crypto/ec/ec_lib.c function EC_POINT_invert checks dbl function pointer instead of invert. Fix attached. Billy __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
