[openssl.org #425] Build error on Windows NT4?
I am getting the same error as well on Windows XP Home / VC++ 6.0. I followed the instructions on the apache.org site to build this for Windows for inclusion in the Apache build. I haven't touched the codebase at all. I found this discussion and ran the perl Configure VC-WIN32 (I needed to add a -I"Path" because of my personal installation) and it then compiled fine. Thanks for the info!! __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #523] Question about DES/CBC Cipher
I don't like to send my questions to [EMAIL PROTECTED] as this doesn't look like a bug. But my mail doesn't seem like getting through with user and dev emails... == Hi, I am developing a cipher encryption tool in c++ using your openssl- crypto library. The result encrypted string is passed to another system for decryption and vice versa, in which the cipher encryption tool was developed in Java, cipher algorithm is DES, mode is CBC, PKCS 5 padding. I tried both functions DES_ncbc_encrypt() and DES_cbc_encrypt() in lib crypto/des for encryption, the result string can't be decrypted by the Java version cipher tool, it doesn't work the other way around neither. I got around the padding by adding padding with each value equal to the number of paddings, but the result strings just look totally different before encryption. Am I using the wrong functions? Which function provides the same algorithm/mode as the one we used in our Java version. Please help!! Thanks. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #521] [PATCH] Avoid uninitialized data in random buffer
On Fri, 28 Feb 2003 11:34:20 +0100 (MET), Daniel Brahneborg via RT wrote: >At lines 467-469 in crypto/rand/md_rand.c is an interesting >thing: > >#ifndef PURIFY >MD_Update(&m,buf,j); /* purify complains */ >#endif > >That is the code that causes the problem (I just verified >it with Valgrind). Does it have any bad side affects to >always skip that code? Since both Purify and Valgrind is >unhappy with that function call, something must be wrong >with it. Purify and Valgrind flag this line because its behaviour is unpredictable. But since it's part of a random number generator, predictability is not important. Purify/Valgrind assume you want your code to behave in a predictable way -- usually a correct assumption just not in this case. -- David Schwartz <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #521] [PATCH] Avoid uninitialized data in randombuffer
* Daniel Brahneborg via RT ([EMAIL PROTECTED]) wrote: > > At lines 467-469 in crypto/rand/md_rand.c is an interesting > thing: > > #ifndef PURIFY > MD_Update(&m,buf,j); /* purify complains */ > #endif > > That is the code that causes the problem (I just verified > it with Valgrind). Does it have any bad side affects to > always skip that code? Since both Purify and Valgrind is > unhappy with that function call, something must be wrong > with it. The reason, when you consider what the RAND_*** code is supposed to do, is that using uninitialised data (where available) is actually a better-than-nothing addition to the amount of entropy in the PRNG. IIRC it is not counted as an increment to the entropy seeded to the PRNG, more of a "freebie". Of course, purify/valgrind/etc will consider that bogus because it considers any access to uninitialised data as bad - after all, you never know *what* the memory might be set to. This of course is exactly the property you want to stir into the randomness pool ... Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.openssl.org/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #522] ocsp http-client bug
Hi, we discovered a problem with the openssl ocsp HTTP client: when doing "openssl ocsp -issuer issuer.pem -cert cert.pem -url http://ocspserver/ocsp -port 80 -CAfile ca.pem" towards a server that returns as first line "HTTP/1.1 200 ", and not "HTTP/1.1 200 OK", then the error "Error querying OCSP responsder" is returned. In the HTTP/1.1 RFC (2616), in sections 6.1 and 6.1.1, we find following definitions: Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Reason-Phrase = * This indicates that Reason-Phrase can be empty (* indicates 0 or more). The openssl code in crypto/ocsp/ocsp_ht.c however requires a non-empty reason-code to be present, making it fail for ocsp requests towards an ocsp server that returns an emtpy Reason-Phrase (e.g. "HTTP/1.1 200 ", including the trailing space). It can be fixed by applying attached patch (actually a diff to crypt/ocsp/ocsp_ht.c, version 0.9.7a). Regards, Peter __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
select timout in crypto/rand/rand_unix.c
openssl 0.9.7X uses select() in crypto/rand/rand_unix.c.
i think that the timeout value should be configurable.
we use the /dev/random device only to get very good
random numbers (no /dev/urandom and no egd stuff).
that can be done by using -DDEVRANDOM=\"/dev/random\"
-DDEVRANDOM_EGD=NULL config options.
that way it can happen that you have to wait several
seconds! for random bytes. it takes about 7sec to
get data on a sun blade 100 @ 500mhz after that
machine has been rebooted. (if the machine is running
you get the data much faster).
the default (0.9.7 and 0.9.7a) is to wait for
10msec ... way to short! i modified
crypto/rand/rand_unix.c from 0.9.7a to have a
timeout of 15 sec:
===
diff -r -u -N openssl-0.9.7a.orig/crypto/rand/rand_unix.c
openssl-0.9.7a/crypto/rand/rand_unix.c
--- openssl-0.9.7a.orig/crypto/rand/rand_unix.c Thu Nov 28 09:08:40 2002
+++ openssl-0.9.7a/crypto/rand/rand_unix.c Fri Feb 28 11:41:25 2003
@@ -159,8 +159,8 @@
#endif
)) >= 0)
{
- struct timeval t = { 0, 10*1000 }; /* Spend 10ms on
- each file. */
+ struct timeval t = { 15, 0 }; /* Spend 15s on
+each file. */
int r;
fd_set fset;
@@ -185,11 +185,11 @@
up here, otherwise, we will do
this once again for the remaining
time. */
- if (t.tv_usec == 10*1000)
- t.tv_usec=0;
+ if (t.tv_sec == 15)
+ t.tv_sec=0;
}
while ((r > 0 || (errno == EINTR || errno == EAGAIN))
- && t.tv_usec != 0 && n < ENTROPY_NEEDED);
+ && t.tv_sec != 0 && n < ENTROPY_NEEDED);
close(fd);
}
===
this change should not affect openssl if you dont change
the config parameters and if you have /dev/urandom.
/dev/urandom is used first and so you should get random
numbers from that device very fast.
but if /dev/urandom does not exist and you use
/dev/srandom or
/var/run/egd-pool /dev/egd-pool /etc/egd-pool /etc/entropy
then you have to wait for that timeout several times.
maybe the order of the devices should be changed that the
least secure one (the fastest) goes first...
maybe the egd stuff should go first, then /dev/urandom and
then /dev/random.
i dont know about /dev/srandom -- just using solaris and linux...
hope this helps, niki
--
niki w. waibel - system administrator @ newlogic technologies ag
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #521] [PATCH] Avoid uninitialized data in random buffer
Nils Larsch via RT wrote: > Daniel Brahneborg via RT wrote: >>I'm using Valgrind to debug a program that uses the OpenSSL >>libraries, and got warnings about uninitialized data in the >>function RSA_padding_add_PKCS1_type_2(), on the line with >>"} while (*p == '\0');" (line 171 in version 0.9.7a). The >>following patch ensures that the data is always modified, >>something that the bytes() method obviously fails to do. > > If it's a bug in bytes() why do you change RAND_bytes(), > wouldn't it be more appropriate to patch the bytes() function > of the correspondig RAND_METHOD ? RAND_bytes() is only a > wrapper function to call the bytes() function from the > RAND_METHOD object (if existing). Obviously patching the real bytes() is the proper way to do it, but since I didn't have the time to further examine where the uninitialized variable came from, patching RAND_bytes() became the easy (and simple) solution for me. At lines 467-469 in crypto/rand/md_rand.c is an interesting thing: #ifndef PURIFY MD_Update(&m,buf,j); /* purify complains */ #endif That is the code that causes the problem (I just verified it with Valgrind). Does it have any bad side affects to always skip that code? Since both Purify and Valgrind is unhappy with that function call, something must be wrong with it. /Basic __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #521] [PATCH] Avoid uninitialized data in random buffer
Daniel Brahneborg via RT wrote: > Hi, > > I'm using Valgrind to debug a program that uses the OpenSSL > libraries, and got warnings about uninitialized data in the > function RSA_padding_add_PKCS1_type_2(), on the line with > "} while (*p == '\0');" (line 171 in version 0.9.7a). The > following patch ensures that the data is always modified, > something that the bytes() method obviously fails to do. If it's a bug in bytes() why do you change RAND_bytes(), wouldn't it be more appropriate to patch the bytes() function of the correspondig RAND_METHOD ? RAND_bytes() is only a wrapper function to call the bytes() function from the RAND_METHOD object (if existing). Regards, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #521] [PATCH] Avoid uninitialized data in random buffer
Hi,
I'm using Valgrind to debug a program that uses the OpenSSL
libraries, and got warnings about uninitialized data in the
function RSA_padding_add_PKCS1_type_2(), on the line with
"} while (*p == '\0');" (line 171 in version 0.9.7a). The
following patch ensures that the data is always modified,
something that the bytes() method obviously fails to do.
--- openssl-0.9.7a/crypto/rand/rand_lib.c Thu Jan 30 18:37:45 2003
+++ openssl-0.9.7a-safe/crypto/rand/rand_lib.c Wed Feb 26 13:48:27 2003
@@ -154,6 +154,7 @@
int RAND_bytes(unsigned char *buf, int num)
{
const RAND_METHOD *meth = RAND_get_rand_method();
+ memset(buf, 0, num);
if (meth && meth->bytes)
return meth->bytes(buf,num);
return(-1);
/Basic
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
