Hi Chrisitan, > The OtherPublicKey is a signed positive integer without the ASN1 > integer header (just the plain bytes), it starts with 0x00 because > otherwise if it started with 0xB2 it would be negative. > So OtherPublicKey length is 0xC1 bytes. The best I can tell, there are two points to observe here.
First, you are correctly observing the ASN.1/Integer encoding, which results in 0x00 being prepended to OtherPublicKey when the value would otherwise be interpreted as negative. But what seems to be missing is as follows: when the ASN.1::Integer is stripped from OtherPublicKey (resulting in the plain byte array), the leading 0x00 can also be stripped. In your case, it must be stripped. The behavior seems to be library dependent, since the leading 0x00 of the byte array does not effect the value of the integer it is representing. For example, I've seen the same issue with Microsoft's crypto implementations in the CLR. If you load an integer (byte array) into a MS RsaCryptoServiceProvider(), RsaCryptoServiceProvider() happily takes superfluous leading 0x00s. However, if you try the same with a digital signature and the MS DsaCryptoServiceProvider(), the DsaCryptoServiceProvider() will throw a 'Bad Data' exception when it internally validates the 'p' or 'q' parameters. Java seems to be OK - it's ASN.1 parser is very forgiving. In the end, I find it is library dependendent. So when I build test cases, I try to observe how a library reacts to the situation, and modify values accordingly. As you can see, I've already explored it with some Microsoft providers. (Apparently you don't have a TrimLeading() function in your war chest yet :). Jeff On Fri, Jun 20, 2008 at 10:52 AM, Christian Berczely <[EMAIL PROTECTED]> wrote: > > I was doing some more digging so I could provide more info about this > problem: > > The OtherPublicKey is a signed positive integer without the ASN1 > integer header (just the plain bytes), it starts with 0x00 because > otherwise if it started with 0xB2 it would be negative. > So OtherPublicKey length is 0xC1 bytes. > > The Prime is a signed positive integer, which is represented here WITH > the ASN1 integer header: '02 81 C1' 00 D7 BC E1..... > On the sample code I provided, I wrote 02 81 "C0" 00 D7.... instead of > C1, because I was testing something and forgot to revert the > changes... the correct is C1. > Again, like in the OtherPublicKey, it needs the 00 in the begining > because otherwise it would be a negative number if it stared with D7. > > > So.... the problem is that dh.PrivateKeyLength(), dh.PublicKeyLength() > and dh.AgreedValueLength() return 0xC0 as the length. > Then when I call: Agree(SharedSecret, myPrivKey, OtherPublicKey, > true) there is no way for me to tell Agree that the OtherPublicKey > has length of 0xC1 instead of 0xC0. Agree is expecting the length of > 0xC0! > > This does not seem to be a problem when I use the iPrime, because it > is a crypto++ Integer, and therefor when I pass it to DH dh(iPrime, > iGenerator) it knows that it is 0xC1 bytes long. > > > If Agree would take as an input the Integer data type for the > OtherPublicKey, then maybe this would work. > > Any ideas???? > > Thanks. > Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [EMAIL PROTECTED] More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
