I’m trying to follow Bitcoin’s signature format suitable for key recovery.. I’m
not sure what standard it follows but here is the outline:
X9ECParameters ecParams =
Org.BouncyCastle.Asn1.Sec.SecNamedCurves.GetByName("secp256k1");
HALF_CURVE_ORDER = ecParams.N.ShiftRight(1);
Then if “s” is less than HALF_CURVE_ORDER, then s = Curve.N.Subtract(sig[1]);
The signature consists of a header byte followed by 32 bit R and S values.
The header byte indicates what value of “r” to use for public key recovery, and
whether or not the public key is compressed or not.
Not sure what standard that aligns to, but feedback is welcome.
From: "d...@autochthonous.org<mailto:d...@autochthonous.org>"
<d...@autochthonous.org<mailto:d...@autochthonous.org>>
Reply-To: "d...@autochthonous.org<mailto:d...@autochthonous.org>"
<d...@autochthonous.org<mailto:d...@autochthonous.org>>
Date: Tuesday, February 11, 2014 at 9:07 PM
To: Chris Lamont Mankowski <cmankow...@nfp.com<mailto:cmankow...@nfp.com>>,
Peter Dettman
<peter.dett...@bouncycastle.org<mailto:peter.dett...@bouncycastle.org>>,
"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] Unwanted zeros in signer.GenerateSignature()
"R" value as a BigInteger ?
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.
