Hi all,
the calculation of the exponent for a ecdsa signature generation /
verification might be done as figured out in
SEC 1: Elliptic Curve Cryptography,part 4.1.3, point 5.2
http://www.secg.org/collateral/sec1_final.pdfthat is as a truncation at bit level. The code in ECDSASigner.java (as seen
below) truncates at byte level. As a failing example sign with curve
sect113r1 and hash with sha256 (where 256-113 != 0 mod8). As a counter
sample sign with secp112r1 and hash sha256 (256-112 == 0 mod8). The error is
seen in comparision with crypto++ which uses truncation at bit level (see
gfpcrypt.cpp,line83ff).
I am *not* a cryptograph, I am a developer who shall *use* ECDSA and I have
found out, that crypto++ and bc have different views upon ECDSA, the paper
quoted above is a hint for me that crypto++ might have done right.
private BigInteger
org.bouncycastle.crypto.signers.ECDSASigner.calculateE(BigInteger n, byte[]
message)
{
/* This is the original code
if (n.bitLength() > message.length * 8)
{
return new BigInteger(1, message);
}
else
{
byte[] trunc = new byte[n.bitLength() / 8];
System.arraycopy(message, 0, trunc, 0, trunc.length);
return new BigInteger(1, trunc);
}
The new code follows: truncation at bit level */
if (n.bitLength() >= message.length * 8)
{
return new BigInteger(1, message);
}
else
{
int nByteLength = (n.bitLength()+7) / 8;
byte[] trunc = new byte[nByteLength];
System.arraycopy(message, 0, trunc, 0, nByteLength);
return (new BigInteger(1, trunc)).shiftRight(nByteLength*8 -
n.bitLength());
}
}
As it is my wish to compute some ecc samples with bouncy castle I have done
a minor addition in JCEECPublicKey.java which introduces an option to save
the named curve with full outlined parameters.
Best Regards,
Andreas Menke
ECDSASigner.zip (5K) 
