使用secp256r1曲线（BouncyCastle）生成ECDSA签名，签名长度为127

I am implementing ECDSA signature generation using secp256r1 curve and SHA256 algorithm using BouncyCastle.

我正在使用secp256r1曲线和使用BouncyCastle的SHA256算法实现ECDSA签名生成。

For some of the inputs the signature length is 127 characters long. I feel the "0" at the beginning are getting removed as the signature is stored to BigInteger datatype in ECDSASigner class.

对于某些输入，签名长度为127个字符。我觉得开头的“0”会被删除，因为签名存储在ECDSASigner类的BigInteger数据类型中。

I have added the sample from rfc6979 ECDSA signing using Deterministic Approach

我已经使用确定性方法从rfc6979 ECDSA签名中添加了样本

The relevant parts of the code :-

代码的相关部分： -

//Private key used in hex format -C9AFA9D845BA75166B5C215767B1D6934E50C3DB36E89B127B8A622B120F6721
        String secretNumberK = "09F634B188CEFD98E7EC88B1AA9852D734D0BC272F7D2A47DECC6EBEB375AAD4";
        SecureRandom secureRandom = new FixedSecureRandom(Hex.decode(secretNumber));
        ECPrivateKeyParameters ecPrivateKeySpec = Util.getECPriKeyParameter(ecPrivateKey);//it is the PrivateKey of the sample shown 
        byte[]  messageInHex = Hex.decode("test");

         ECDSASigner ecdsaSigner = new ECDSASigner();

        ecdsaSigner.init(true, new ParametersWithRandom(ecPrivateKeySpec,
                secureRandom));

         BigInteger[]  sig = ecdsaSigner.generateSignature(Util
                .generateSHAHash(messageInHex));
        flag = true;
        LOG.debug("r:: " + sig[0].toString(16).toString());
        LOG.debug("s:: " + sig[1].toString(16).toString());

Expected R and S of Signature as per document:-

根据文件预期的签名R和S： -

 r = 0EAFEA039B20E9B42309FB1D89E213057CBF973DC0CFC8F129EDDDC800EF7719
 s = 4861F0491E6998B9455193E34E7B0D284DDD7149A74B95B9261F13ABDE940954

But Iam getting

但我得到了

r = EAFEA039B20E9B42309FB1D89E213057CBF973DC0CFC8F129EDDDC800EF7719
s = 4861F0491E6998B9455193E34E7B0D284DDD7149A74B95B9261F13ABDE940954

The only difference is the zero in the r value. And because of this length of signature is only 127.

唯一的区别是r值为零。而且由于这个签名长度只有127。

Please let me know if my inference is correct. Is this a bug in Bouncy Castle?

如果我的推断是正确的，请告诉我。这是Bouncy Castle的一个错误吗？

1 个解决方案

#1

This isn't a bug in BouncyCastle. BouncyCastle has returned a BigInteger to you. I don't believe Java's BigInteger class stores any information about how many leading zeros should be printed, and you are not supplying that information when you use .toString(16).toString(), so the inevitable result is that leading zeros will not be shown.

这不是BouncyCastle中的错误。 BouncyCastle已经为您返回了一个BigInteger。我不相信Java的BigInteger类存储有关应该打印多少前导零的任何信息，并且在使用.toString（16）.toString（）时不提供该信息，因此不可避免的结果是前导零不会显示。

You understand that, for example, hex "0EAF" is the same number as hex "EAF", right? So this is just a string formatting issue. The numbers are correct.

你明白，例如，十六进制“0EAF”与十六进制“EAF”的号码相同，对吧？所以这只是一个字符串格式问题。数字是正确的。

If you want your strings to exactly match the text from the document, you will need to do some additional work when you are formatting your strings in order to add leading zeros.

如果希望字符串与文档中的文本完全匹配，则在格式化字符串以添加前导零时，需要执行一些额外的工作。

Here is a similar questions and resources:

这是一个类似的问题和资源：

BigInteger.toString method is deleting leading 0
BigInteger.toString方法正在删除前导0
https://linkpeek.com/blog/pad-zeros-on-java-biginteger-when-making-md5-hash.html
https://linkpeek.com/blog/pad-zeros-on-java-biginteger-when-making-md5-hash.html

#1