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 List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
