Re: Alternate RAND_poll for XP/2003 Server/Vista
On Dec 2 13:38, Steven Reddie wrote: Two sentences after that one are these: To form the seed for the random number generator, a calling application supplies bits it might have-for instance, mouse or keyboard timing input-that are then added to both the stored seed and various system data and user data such as the process ID and thread ID, the system clock, the system time, the system counter, memory status, free disk clusters, the hashed user environment block. This result is SHA-1 hashed, and the output is used to seed an RC4 stream, which is then used as the random stream and used to update the stored seed. So although all processes access the same PRNG it seems that there is provision to mix it up a little. I imagine that an installed Cryptographic Provider could provide its own PRNG and Windows could be configured to use that instead. If you install another CSP, you can use this CSP and this CSP in turn can use another source for its cryptographic magic, including the sources for its random number generator. The above description is only valid for the predefined CSPs as delivered by default by the OS[1]. If you decide to use CryptGenRandom, you also have to call CryptAcquireContext[2]. This function gets the CSP as an argument. If you use NULL here, as the openssl library does, the CSP is the one set as the user default CSP. The user default CSP can be set by a call to CryptSetProvider[3], and is then used as the default provider for this user. Every process started after this call gets the new CSP. This means, that the openssl library can not be sure to use the same CSP all the time, or even a trustworthy one (for a given value of trust). But, if you call CryptAcquireContext with one of the Microsoft predefined CSPs, you can rely on the fact that the same random number generator is used all the time and the description above describes how the random numbers are generated then. Whatever your trust level in relation to Microsoft is, you know at least which CSP is used. FWIW, the Cygwin implementation of /dev/random and /dev/urandom uses the Microsoft Base Cryptographic Provider 1.0, MS_DEF_PROV, so at least it's using the same cryptographic source all the time. Shouldn't a fixed CSP be used for the native Windows random number generator in crypt/rand/rand_win.c, too? Corinna [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptographic_provider_names.asp [2] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptacquirecontext.asp [3] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptsetprovider.asp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Corinna Vinschen Sent: Friday, 2 December 2005 7:59 AM To: openssl-dev@openssl.org Subject: Re: Alternate RAND_poll for XP/2003 Server/Vista On Dec 1 12:43, Rick Jones wrote: Corinna Vinschen wrote: I'm wondering about this anyway. While the exact code of CryptGenRandom isn't open source, MSDN has a quite extensive description how the random numbers are generated by CryptGenRandom, see the Remarks section in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secc rypto/security/cryptgenrandom.asp which also talks about the entropy sources used. Being otherwise blissfully ignorant of things Windows, does this snippet from the URL above: With Microsoft CSPs, CryptGenRandom uses the same random number generator used by other security components. imply that CryptGenRandom might be satisfied by code other than that from Microsoft described in the URL above? You omited the next sentence: This allows numerous processes to contribute to a system-wide seed. I understand this as every process using one of the Microsoft CSPs will internally access the same random number generator. As if, say, every process uses /dev/random on Linux. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
[EMAIL PROTECTED] - Mon Sep 19 10:05:09 2005]: Hello, I have traced again and found out that c_zlib.c::zlib_compress_block() is responsible that wrec-length is sometimes 44 (korrect value) and sometimes 45 (troublesome value) I'm using zlib 1.2.3 !!! for length 45 I'm getting the trouble with the SSP_OP_TLS_BLOCK_PADDING_BUG handling. Korrekt handling requestor side: length is 44; augmented to 48; -data[47] = 3 provider side: length is 48; decremented with 3+1 = 44 Wrong handling requestor side: length is 45; augmented to 48; -data[47] = 2 provider side: length is 48; decremented with (2+1-1/* PADDING_BUG '\0...' FLAGS..PADDING_BUG */) = 46 !!! I hope this helps - to find out whats going wrong. The bug seems to be reproduced without compression (s_client reports than both Compression and Expansion are equal to 'NONE'). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
--- see below -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of via RT Sent: Friday, December 02, 2005 2:17 PM To: Kämpfe, Christiane Cc: openssl-dev @openssl.org Subject: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling [EMAIL PROTECTED] - Mon Sep 19 10:05:09 2005]: Hello, I have traced again and found out that c_zlib.c::zlib_compress_block() is responsible that wrec-length is sometimes 44 (korrect value) and sometimes 45 (troublesome value) I'm using zlib 1.2.3 !!! for length 45 I'm getting the trouble with the SSP_OP_TLS_BLOCK_PADDING_BUG handling. Korrekt handling requestor side: length is 44; augmented to 48; -data[47] = 3 provider side: length is 48; decremented with 3+1 = 44 Wrong handling requestor side: length is 45; augmented to 48; -data[47] = 2 provider side: length is 48; decremented with (2+1-1/* PADDING_BUG '\0...' FLAGS..PADDING_BUG */) = 46 !!! I hope this helps - to find out whats going wrong. The bug seems to be reproduced without compression (s_client reports than both Compression and Expansion are equal to 'NONE'). I'm sorry, I don't understand your remark. I was stepping also inside the compression handling called by openssl ! I have now made the same tests with an openssl produced without compression abilities (no-zlib). This works fine. openssl with compression still doesn't work with zlib 1.2.3. By the way, why couldn't I change the compression level for openssl compression ? ... we'v got via gSOAP the best performance results with level 1 in combination with HTTP chunking. - c.kae __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Greetings! On Fri, 2 Dec 2005, [EMAIL PROTECTED] via RT wrote: The bug seems to be reproduced without compression (s_client reports than both Compression and Expansion are equal to 'NONE'). I'm sorry, I don't understand your remark. I was stepping also inside the compression handling called by openssl ! I have now made the same tests with an openssl produced without compression abilities (no-zlib). This works fine. openssl with compression still doesn't work with zlib 1.2.3. By the way, why couldn't I change the compression level for openssl compression ? ... we'v got via gSOAP the best performance results with level 1 in combination with HTTP chunking. I've reproduced this bug with s_client and apache as server requesting page which requires client certificate. So I'm not sure that this bug is completely zlib-related. -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Greetings! On Fri, 2 Dec 2005, [EMAIL PROTECTED] via RT wrote: The bug seems to be reproduced without compression (s_client reports than both Compression and Expansion are equal to 'NONE'). I'm sorry, I don't understand your remark. I was stepping also inside the compression handling called by openssl ! I have now made the same tests with an openssl produced without compression abilities (no-zlib). This works fine. openssl with compression still doesn't work with zlib 1.2.3. By the way, why couldn't I change the compression level for openssl compression ? ... we'v got via gSOAP the best performance results with level 1 in combination with HTTP chunking. I've reproduced this bug with s_client and apache as server requesting page which requires client certificate. So I'm not sure that this bug is completely zlib-related. -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Greetings back ! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry Belyavsky via RT Sent: Friday, December 02, 2005 2:45 PM To: Kämpfe, Christiane Cc: openssl-dev@openssl.org Subject: RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling Greetings! On Fri, 2 Dec 2005, [EMAIL PROTECTED] via RT wrote: The bug seems to be reproduced without compression (s_client reports than both Compression and Expansion are equal to 'NONE'). I'm sorry, I don't understand your remark. I was stepping also inside the compression handling called by openssl ! ... snip/ I've reproduced this bug with s_client and apache as server requesting page which requires client certificate. So I'm not sure that this bug is completely zlib-related. -- SY, Dmitry Belyavsky (ICQ UIN 6575) Aah, now I understand a little bit more. .. requires client certificates ... so both sides use OpenSSL ?. OpenSSL is normaly produced using compression even if you don't notice this - beginning with the handshakes ! So I'm not sure if your bug is completely unconnected with zlib. By the way - do you know the versions of zlib used on both sides ? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Greetings! On Fri, 2 Dec 2005, [EMAIL PROTECTED] via RT wrote: I've reproduced this bug with s_client and apache as server requesting page which requires client certificate. So I'm not sure that this bug is completely zlib-related. Aah, now I understand a little bit more. .. requires client certificates ... so both sides use OpenSSL ?. OpenSSL is normaly produced using compression even if you don't notice this - beginning with the handshakes ! So I'm not sure if your bug is completely unconnected with zlib. By the way - do you know the versions of zlib used on both sides ? 1.2.2-4.sarge.2 on client side 1.2.3-8 and 1.2.2-4.sarge.2 on different server. -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Greetings! On Fri, 2 Dec 2005, [EMAIL PROTECTED] via RT wrote: I've reproduced this bug with s_client and apache as server requesting page which requires client certificate. So I'm not sure that this bug is completely zlib-related. Aah, now I understand a little bit more. .. requires client certificates ... so both sides use OpenSSL ?. OpenSSL is normaly produced using compression even if you don't notice this - beginning with the handshakes ! So I'm not sure if your bug is completely unconnected with zlib. By the way - do you know the versions of zlib used on both sides ? 1.2.2-4.sarge.2 on client side 1.2.3-8 and 1.2.2-4.sarge.2 on different server. -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
OpenSSL and Mac OS X 10.4 and the use of dynamic engine
Mac OS X 10.4 provides a version of OpenSSL in /usr. With security update 2005-009 applies a version of OpenSSL-0.9.7i /usr/bin/openssl appears to be linked static. /usr/lib/libcryoto.0.9.7.dylib and /usr/lib/libssl.0.9.7.dylib are also provided. These look like they are also 0.9.7i. None of these have the OpenSSL 'dlfcn' shared library method which means the dynamic engine code does not work. And the /usr/include/openssl header files appear to be 0.9.7b Anyone know how to get Apple to add in the DSO code for the dynamic engine, and get the header files to match the libs? I would rather use the vendor's provided versions of these if at all possible. -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and Mac OS X 10.4 and the use of dynamic engine
On Dec 2, 2005, at 9:52 AM, Douglas E. Engert wrote: Mac OS X 10.4 provides a version of OpenSSL in /usr. With security update 2005-009 applies a version of OpenSSL-0.9.7i /usr/bin/openssl appears to be linked static. /usr/lib/libcryoto.0.9.7.dylib and /usr/lib/libssl.0.9.7.dylib are also provided. These look like they are also 0.9.7i. None of these have the OpenSSL 'dlfcn' shared library method which means the dynamic engine code does not work. And the /usr/include/openssl header files appear to be 0.9.7b Anyone know how to get Apple to add in the DSO code for the dynamic engine, and get the header files to match the libs? I would rather use the vendor's provided versions of these if at all possible. Go to http://bugreport.apple.com and file a report. Don't worry that someone might have reported this before, more reports just get more attention, even if they get marked as duplicates, so tell your friends. If you don't already have an Apple Developer Connection (ADC) account, you can sign up for a free on-line membership at http://connect.apple.com. You might also ask this question on one of the Darwin lists. See http://lists.apple.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Alternate RAND_poll for XP/2003 Server/Vista
On Fri, Dec 02, 2005 at 01:44:49PM +1100, Steven Reddie wrote: CryptGenRandom is available on all Windows back to Windows 95. RtlGenRandom is only available since XP, however CryptGenRandom makes use of it. Presumably RtlGenRandom has always been around, it's just never been documented or made generally available until now. From what I can tell, up until recently the PRNG was embedded into CryptoAPI, and could not be accessed without going through that. I would imagine that what happened is that the PRNG implemented by CryptGenRandom was split off into its own distinct chunk of code starting with XP. Keep in mind that right now it doesn't even have an entry point - you have to get ahold of it dynamically through a DLL load. It seems pretty obvious that RtlGenRandom was supposed to just be used internally, with CryptoAPI being the primary interface. Probably someone at Microsoft finally realized that it might be useful to get random bits without having to pull all of CryptoAPI into the mix. Why is there a reluctance to deal with CryptoAPI? I've used CryptGenRandom in my own code and never had a problem with it. I don't have huge issues with it myself (in terms of entropy generation, CryptGenRandom has been fairly painless compared to some other mechanisms), but CryptoAPI is somewhat big, and there are various annoyances, such as the fact that repeatedly initializing and shutting down CryptoAPI causes a large memory leak on some older systems. -J __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
