This is happening because BigInteger in BC are signed.
You don't say which standard you are trying to follow, but be careful
with this, in many cases if you're trying to generate a ECDSA signature
the leading zero should be preserved.
For a regular signature it's
SEQUENCE {
r INTEGER,
s INTEGER
}
INTEGER in ASN.1 is signed - there is no unsigned type, so the encoding
is a sequence with 2 signed integers.
If you're trying to implement a variation on ECDSA that requires a fixed
length r and s then X9IntegerConverter will most likely do what you want.
Regards,
David
On 12/02/14 12:20, Mankowski, Chris wrote:
When I sign a message with the following code in Bouncy Castle
ECDsaSigner signer = new ECDsaSigner();
signer.Init(true, privateKey);
BigInteger[] sig = signer.GenerateSignature(msgHash);
I then convert sig[0] (the r value) into an array, which should always
be 65 bytes. EXCEPT when a BigInt like the following is encountered
58650980636392567052140988972187067219911065282189351724280630818031190701698
102727959281289207806250813963437648116869730621833588327739351476733611695109
I noticed that each time the length is 66 bytes long, position[0] of
this array is zero. If I delete this zero and resize the array, all
cryptographic routines work as expected.
Can anyone tell me why this is the case and how I could properly
mitigate it?
I’m including a message Peter sent the list earlier about a similar
issue, but this was regarding ECPoint.GetEncoded or
X9IntegerConverter. Before I tinker and experiment with those
classes, I think it’s best to check with the experts on which approach
I should take.
-Chris
From: Peter Dettman <peter.dett...@bouncycastle.org
<mailto:peter.dett...@bouncycastle.org>>
Date: Saturday, October 26, 2013 at 9:37 PM
To: "dev-crypto-csharp@bouncycastle.org
<mailto:dev-crypto-csharp@bouncycastle.org>"
<dev-crypto-csharp@bouncycastle.org
<mailto:dev-crypto-csharp@bouncycastle.org>>
Subject: Re: [dev-crypto-csharp] Re: Bug: X and Y in
ECPublicKeyParameters is sometimes 33 bits instead of 32
Please note that while ToByteArrayUnsigned accounts for the possible
leading zero, it will not give the full 32 bytes in the case where the
field element has a small value relative to the field characteristic.
So please do use X9IntegerConverter or you will get incorrect (short)
output randomly for ~%1 of points.
Better yet, just use ECPoint.GetEncoded() if that is applicable.
Regards,
Pete Dettman
On 27/10/2013 7:35 AM, Mankowski, Chris wrote:
Ahh yes, that’s perfect. Thank you.
From: Atanas Krachev <akrac...@gmail.com <mailto:akrac...@gmail.com>>
Date: Saturday, October 26, 2013 at 3:17 PM
To: Chris Lamont Mankowski <cmankow...@nfp.com
<mailto:cmankow...@nfp.com>>
Cc: "dev-crypto-csharp@bouncycastle.org
<mailto:dev-crypto-csharp@bouncycastle.org>"
<dev-crypto-csharp@bouncycastle.org
<mailto:dev-crypto-csharp@bouncycastle.org>>
Subject: Re: [dev-crypto-csharp] Re: Bug: X and Y in
ECPublicKeyParameters is sometimes 33 bits instead of 32
Hi Chris,
Wouldn't the ToByteArrayUnsigned() method of the BigInteger class be
helpful in your case?
Cheers,
Atanas Krachev
------------------------------------------------------------------------
Notice: This e-mail message and any attachment to this e-mail message
may contain information that is confidential, proprietary,
privileged, legally privileged and/or exempt from disclosure under
applicable law. If you are not the intended recipient, please accept
this as notice that any disclosure, copying, distribution or use of
the information contained in this transmission is strictly
prohibited. NFP reserves the right, to the extent and under
circumstances permitted by applicable law, to retain, monitor and
intercept e-mail messages to and from its systems.
Any views or opinions expressed in this e-mail are those of the
sender and do not necessarily express those of NFP. Although this
transmission and any attachment are believed to be free of any virus
or other defect that might affect any computer system into which it
is received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
NFP, its subsidiaries and affiliates, as applicable, for any loss or
damage arising in any way from its use.
If you have received this e-mail in error, please immediately contact
the sender by return e-mail or by telephone at 212-301-4000 and
destroy the material in its entirety, whether electronic or hard copy
format.
------------------------------------------------------------------------
This e-mail may contain information that is privileged, confidential
or protected under state or federal law. If you are not an intended
recipient of this email, please delete it, notify the sender
immediately, and do not copy, use or disseminate any information in
the e-mail. Pursuant to IRS Circular 230, any tax advice in this email
may not be used to avoid any penalties imposed under U.S. tax laws.
E-mail sent to or from this e-mail address may be monitored, reviewed
and archived.
