充气城堡DSA与SHA1签名验证

Question

我的项目正在对来自某些第三方软件的某些数据集进行签名验证。使用的签名算法是 SHA1withDSA。当我使用SDK附带的标准SUN加密提供程序时，一切都很顺利。最近我切换到了Bouncy Castle 1.50，之后，一些以前（即SUN提供者）进行验证的数据集开始失败，而其余的仍然被验证正常。

我探索了两个提供程序的源代码，结果发现SDK的默认提供程序对格式错误的签名有某种保护（同时能够恢复），而Bouncy Castle提供程序没有。查看OpenJDK forJava7（第336-344行）或OpenJDK forJava8（第265-273行）：他们在某些情况下做了一些签名修复。虽然没有为org.bouncycastle.jcajce.provider.asymmetric.dsa.DSASigner#engineVerify做这样的事情，但在org.bouncycastle.crypto.signers.DSASigner#verifySignature中明确规定数字必须是正数，否则验证会立即失败。

这是BC省的一个错误，还是我错过了什么？为了克服这个问题，我子类化了org.bouncycastle.crypto.signers.DSASigner，并在那里添加了相同的上述签名修复程序，然后将其作为另一种签名算法插入（通过子类化org.bouncycastle.jcajce.provider.asymmetric.dsa.DSASigner）。但也许还有另一种方式我忽略了，这个“问题”是众所周知的？请指教。

Answer 1

如果ASN.1整数的错误BER / DER编码 - 存储为有符号大端序，右对齐八位字节序 - 确实是罪魁祸首，那么Bouncy就没有错误。如果设置了编码的第一位，则应使用 00 值字节填充正值，否则它将表示负值。

Sun提供者允许这些类型的签名进行验证是错误的，而另一方当然正在生成无效的签名。请注意，在Sun代码中没有这种“修复”的情况下，可以让签名进行验证：只需在将其提供给验证函数之前调整编码即可。

唯一不可能的情况是DSA验证作为通用签名验证方法从另一个库调用，而不是从可以在调用前调整数据的应用程序调用。

另一方面，我认为您已经创建了一个优雅的修复程序。它的唯一问题是，如果从JCA兼容框架验证了提供者的签名，它可能无法运行。另一个可能的修复程序是在将其提供给Signature类进行验证之前重新编码。

请注意，我不认为这是一个安全问题；签名由R和S的值组成，它们是如何编码的并不重要，只要最终得到正确的值。