吞异常，太恶心了。org.bouncycastle.crypto.signers.SM2Signer#verifySignature(byte[])

[wangzongying]

这个sm2验签方法吞异常，当传入的签名值不太符合规范时，或者BigInteger是无符号数，导致解析为负数时，异常被吞。直接返回false。害人不浅。

[wangzongying]

public boolean verifySignature(byte[] signature)
{
try
{
BigInteger[] rs = encoding.decode(ecParams.getN(), signature);

        return verifySignature(rs[0], rs[1]);
    }
    catch (Exception e)
    {
    }

    return false;
}

[peterdettman]

(translated) This SM2 signature verification method swallows exceptions when the input signature value doesn't conform to the specifications, or when the BigInteger is an unsigned number that is parsed as a negative number. It simply returns false. This is quite harmful.

It's unclear to me what you think the problem is here. Do you have a signature that you think is valid that is failing to verify? Are you using the default implementation of DSAEncoding (e.g. by calling new SM2Signer()) or have you written your own?

[ligefeiBouncycastle]

@wangzongying 感谢您提出的宝贵反馈。我们理解您在调试SM2签名验证时遇到的不便。

当前BC-Java库的设计选择是：验证方法只返回布尔值（true/false），不暴露内部异常细节。这是出于以下考虑：

• API简洁性：保持验证接口简单统一

• 安全原则：避免通过错误信息泄露系统内部状态

对于调试困难的问题，我们建议：

• 在调用verifySignature前，先对输入数据进行基本验证

• 确保签名生成符合SM2规范

为了更准确地分析您遇到的问题，请提供您正在使用的SM2签名示例（有效或验证失败的案例）。 这将帮助我们更好地理解具体是哪种格式问题导致了验证失败。

我们将此反馈纳入讨论，将在后续版本中评估是否需要增加调试支持（如可选日志记录或详细错误码），同时保持现有API的稳定性。

[ligefeiBouncycastle]

@peterdettman

The user is raising a concern about the SM2 signature verification API. Their issue isn't about a specific valid signature failing verification, but rather about the debugging experience when verification fails.

Should we consider adding optional diagnostic capabilities? For example:
Add a debug mode via system property
-- Would log specific failure reasons to a configurable logger
-- Can be disabled by default for production

[wangzongying]

这个方法来自org.bouncycastle.crypto.signers.SM2Signer#verifySignature(byte[]) ，不管使用java.security.Signature spi 还是直接使用new SM2Signer 进行验签，都会执行这个方法。某些客户端设备签名值不太符合规范，会导致在执行 org.bouncycastle.crypto.signers.StandardDSAEncoding#decode
org.bouncycastle.crypto.signers.StandardDSAEncoding#checkValue
时抛出
if (x.signum() < 0 || (null != n && x.compareTo(n) >= 0))
{
throw new IllegalArgumentException("Value out of range");
}
异常，导致验签返回false。

而此签名值使用nodejs的sm2-crypto是验签通过的。nodejs兼容了r s为负数的情况。

如果异常不抛出，非常难以排查出这个原因，因为nodejs验签通过的。最终我是使用源码debug才发现是出现了异常返回false。

[wangzongying]

我理解你说的。在调用verifySignature前，先对输入数据进行基本验证。确实我这么做了，我现在验签之前对签名值做了合法性转换，就验签通过了。
public static byte[] fixSignatureForBC(byte[] sig) throws Exception {
ASN1Sequence seq = (ASN1Sequence) ASN1Sequence.fromByteArray(sig);
BigInteger r = ((ASN1Integer) seq.getObjectAt(0)).getValue();
BigInteger s = ((ASN1Integer) seq.getObjectAt(1)).getValue();

    // 1️⃣ 确保 r 和 s 为正数，如果负数，加前导 0x00
    r = toPositive(r);
    s = toPositive(s);

    // 2️⃣ 重新构造 ASN.1 序列
    ASN1EncodableVector vec = new ASN1EncodableVector();
    vec.add(new ASN1Integer(r));
    vec.add(new ASN1Integer(s));
    DERSequence fixedSeq = new DERSequence(vec);

    return fixedSeq.getEncoded();
}

// 将 BigInteger 转为正数，确保 BC 解析兼容
private static BigInteger toPositive(BigInteger n) {
    if (n.signum() < 0) {
        byte[] bytes = n.toByteArray();
        byte[] positiveBytes = new byte[bytes.length + 1];
        System.arraycopy(bytes, 0, positiveBytes, 1, bytes.length);
        return new BigInteger(positiveBytes);
    }
    return n;
}

[peterdettman]

I think node.js is wrong to accept signatures where the ASN.1 Integer is negative. If you really want to support them, the simplest way to force positive interpretation is by using ASN1Integer#getPositiveValue(), e.g.:

    public class CustomDSAEncoding extends StandardDSAEncoding
    {
        @Override
        protected BigInteger decodeValue(BigInteger n, ASN1Sequence s, int pos)
        {
            return checkValue(n, ((ASN1Integer)s.getObjectAt(pos)).getPositiveValue());
        }        
    }

I would suggest contacting whoever is generating these signatures and tell them to fix their ASN.1 encoder and/or switch to plain DSA encoding.

I don't think verifySignature should throw for a mere invalid signature; that is what the return code is for. Arguably we could throw in case the signature validity cannot be determined for some reason (e.g. some sort of VM error), but in this case it is returning false for a definitely invalid signature.