Re: BIGNUM library
Edward Chan wrote: I have more info on this now. I just tried openssl with bsafe crypto-c me. Again, I get sporadic failures. When I compare the 2 computed shared secrets, I see that they are actually the same, except that bsafe has some zero padded bytes at the beginning, even though it says it computed 128 bytes. So for example, openssl[0, 127] == bsafe[1, 128], where bsafe[0] == 0 or openssl[0, 127] == bsafe[2, 129], where bsafe[0] == bsafe[1] == 0 Anybody have any ideas. I haven't tried MS CAPI to BSAFE yet, but I have a feeling these 2 libs may work together. Can somebody point me to a spec on the ASN.1 format for BIGNUM's over the wire? Well the case with bsafe[0]==bsafe[1]==0 definitely cannot be ASN.1 integer compliant, because ASN.1 DER specifies that you must use the shortest possible encoding for a number. Having two leading 0s isn't definitely shortest (or unique), since you can get the same number with just a single leading 0. In case you want the spec for ASN.1 bignum, it should be the X.691 for Integer encoding. (i'm assuming DER here) -jb -- The biggest problem with communication is the illusion that it has occurred. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Looking official tools to test Openssl Server
Hi All I have finished coding/testing with Openssl Client/Server applications. I am looking for any official tools out there to help me breaking my codes. These tools will send to my listening server wrong cert, cert signing with non-approved CA, cert with different level CA, expire Cert... Please let me know. Thank You Thao Dinh
Re: BIGNUM library
On Fri, Apr 20, 2007 at 01:12:29PM +0530, jimmy wrote: Edward Chan wrote: I have more info on this now. I just tried openssl with bsafe crypto-c me. Again, I get sporadic failures. When I compare the 2 computed shared secrets, I see that they are actually the same, except that bsafe has some zero padded bytes at the beginning, even though it says it computed 128 bytes. So for example, openssl[0, 127] == bsafe[1, 128], where bsafe[0] == 0 or openssl[0, 127] == bsafe[2, 129], where bsafe[0] == bsafe[1] == 0 Anybody have any ideas. I haven't tried MS CAPI to BSAFE yet, but I have a feeling these 2 libs may work together. Can somebody point me to a spec on the ASN.1 format for BIGNUM's over the wire? Well the case with bsafe[0]==bsafe[1]==0 definitely cannot be ASN.1 integer compliant, because ASN.1 DER specifies that you must use the shortest possible encoding for a number. Having two leading 0s isn't definitely shortest (or unique), since you can get the same number with just a single leading 0. In case you want the spec for ASN.1 bignum, it should be the X.691 for Integer encoding. (i'm assuming DER here) Is an issue with on-the-wire interoperability of a standardized protocol, or an issue with out of band migration of key material between different systems? If the latter, there are no standards. The OP is still being fast and loose with the distinction between the private formats used internally by applications and libraries, and the public formats used on the wire... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: BIGNUM library
I think the issue is with on the wire interoperability. Let me summarize my tests so far. Openssl to openssl - this works 100% CAP to CAPI - works 100% OpenSSL to CAPI - sporadic failures XySSL to CAPI - sporadic failures OpenSSL to XySSL - works 100% Because CAPI doesn't give you access to the computed shared secret, I can't say for sure that the computed shared secret is different from openssl/xyssl. But I'm 99% sure this is the reason for the failure. And because I got another crypto lib to work with openssl, which also failed with CAPI in the same manner, I assumed the problem lie with CAPI. But now, I just tried another commercial crypto lib, RSA's BSAFE Crypto-C ME. OpenSSL to BSAFE - sporadic failures BSAFE to CAPI - works 100% What are the chances that 2 commercial crypto libraries from heavy weights Microsoft and RSA have similar bugs? Maybe the chances are high :) But at this point, I'm starting to think, dare I say it, that there might possibly be a bug in OpenSSL? Anybody else have ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Victor Duchovni Sent: Friday, April 20, 2007 7:53 AM To: openssl-users@openssl.org Subject: Re: BIGNUM library On Fri, Apr 20, 2007 at 01:12:29PM +0530, jimmy wrote: Edward Chan wrote: I have more info on this now. I just tried openssl with bsafe crypto-c me. Again, I get sporadic failures. When I compare the 2 computed shared secrets, I see that they are actually the same, except that bsafe has some zero padded bytes at the beginning, even though it says it computed 128 bytes. So for example, openssl[0, 127] == bsafe[1, 128], where bsafe[0] == 0 or openssl[0, 127] == bsafe[2, 129], where bsafe[0] == bsafe[1] == 0 Anybody have any ideas. I haven't tried MS CAPI to BSAFE yet, but I have a feeling these 2 libs may work together. Can somebody point me to a spec on the ASN.1 format for BIGNUM's over the wire? Well the case with bsafe[0]==bsafe[1]==0 definitely cannot be ASN.1 integer compliant, because ASN.1 DER specifies that you must use the shortest possible encoding for a number. Having two leading 0s isn't definitely shortest (or unique), since you can get the same number with just a single leading 0. In case you want the spec for ASN.1 bignum, it should be the X.691 for Integer encoding. (i'm assuming DER here) Is an issue with on-the-wire interoperability of a standardized protocol, or an issue with out of band migration of key material between different systems? If the latter, there are no standards. The OP is still being fast and loose with the distinction between the private formats used internally by applications and libraries, and the public formats used on the wire... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: BIGNUM library
On Fri, Apr 20, 2007 at 10:34:55AM -0700, Edward Chan wrote: I think the issue is with on the wire interoperability. Let me summarize my tests so far. Openssl to openssl - this works 100% CAP to CAPI - works 100% OpenSSL to CAPI - sporadic failures XySSL to CAPI - sporadic failures OpenSSL to XySSL - works 100% What works? What protocol are you using, and what software is constructing the packets that go on the wire? If you are building your own protocol over the multiple low-level crypto libraries, and doing your own data serialization, the you are responsible for ensuring on the wire compatibility of the of serialized data. I think you need to better explain what problem you are really solving... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: BIGNUM library
Edward Chan [EMAIL PROTECTED] wrote: Openssl to openssl - this works 100% CAP to CAPI - works 100% OpenSSL to CAPI - sporadic failures XySSL to CAPI - sporadic failures OpenSSL to XySSL - works 100% I noted earlier that when your testcode failed, OpenSSL's secret always begins with 0xCC; however sometimes the test passed with the first byte of the secret equal to 0xCC. It just realized that, with VS uninitialized memory is filled with 0xCC. So the error was not in OpenSSL or CAPI, but rather in the incorrect use of the function DH_generate_key (the return value was not taken into account properly when setting up the shared secret). A simple fix is to add zero padding when the secret is less than 128 bytes. Because CAPI doesn't give you access to the computed shared secret, I can't say for sure that the computed shared secret is different from openssl/xyssl. But I'm 99% sure this is the reason for the failure. Even though MS says otherwise, it is possible to access the DH shared secret computed by CAPI, with a bit of trickery. When disassembling dssenh.dll using the associated debug symbols, it appears that the secret is internally computed by UseDHKey, which calls DHExpo, which calls BN_mod_exp, which itself is a wrapper for _mod_exp(). Then the function BN_from_modular is called, and the result (stored in the second argument of _BN_from_modular) is the shared secret. .text:68106ED2 pushebx .text:68106ED3 lea eax, [ebp+var_200] ; shared secret .text:68106ED9 pusheax .text:68106EDA lea eax, [ebp+var_800] .text:68106EE0 pusheax .text:68106EE1 call[EMAIL PROTECTED] .text:68106EE6 testeax, eax Setting up a breakpoint at 0x68106EE6, one can therefore obtain this value directly by looking it up in the stack. What are the chances that 2 commercial crypto libraries from heavy weights Microsoft and RSA have similar bugs? Maybe the chances are high :) But at this point, I'm starting to think, dare I say it, that there might possibly be a bug in OpenSSL? Anybody else have ideas? In fact I had the same bug wrt/ the DH code in XySSL a couple months ago, not taking into account the fact that OpenSSL does not add zero padding. Christophe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: BIGNUM library
So the error was not in OpenSSL or CAPI, but rather in the incorrect use of the function DH_generate_key (the return value was not taken into account properly when setting up the shared secret). A simple fix is to add zero padding when the secret is less than 128 bytes. My mistake, it's the function DH_compute_key(). Christophe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: BIGNUM library
But I think this always returned me 128 bytes. So am I supposed to bzero the output buffer first? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Devine Sent: Friday, April 20, 2007 12:00 PM To: openssl-users@openssl.org Subject: Re: BIGNUM library So the error was not in OpenSSL or CAPI, but rather in the incorrect use of the function DH_generate_key (the return value was not taken into account properly when setting up the shared secret). A simple fix is to add zero padding when the secret is less than 128 bytes. My mistake, it's the function DH_compute_key(). Christophe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: BIGNUM library
On Fri, Apr 20, 2007 at 03:43:41PM -0700, Edward Chan wrote: I apologize for the confusion. I thought I had stated the problem before. I'm basically trying to do a DH key exchange between different crypto libraries. Why an explicit DH key exchange and not TLS, which is interoperable, and authenticates the DH exchange, ... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
SSL accept error
I see this error in my web server log when I try to connect using IE or Firefox. Does anybody know why this could be happening ? 04/15/2007 03:36:22.22 Erro:thttpd.err SSL_accept failed - error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol 04/15/2007 03:35:52.08 Erro:thttpd.err SSL_accept failed - error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol Thanks, Nagaraj
