Hi Chris,
Suggest you look at the bitcoinj code here:
https://code.google.com/p/bitcoinj/source/browse/core/src/main/java/com/google/bitcoin/core/ECKey.java#624
In place of their Utils.bigIntegerToBytes, you might simply use e.g.:
BigIntegers.AsUnsignedByteArray(32, r)
Regards,
Pete Dettman
On 12/02/2014 9:16 AM, Mankowski, Chris wrote:
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.
