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]
