Bouncy Castle DSA带有SHA1签名验证

Question

我的项目使用来自某些第三方软件的一些数据集的签名验证.使用的签名算法是SHA1withDSA.当我使用SDK附带的标准SUN加密提供程序时,一切都很顺利.最近我切换到Bouncy Castle 1.50,之后一些以前(也就是SUN提供商)的数据集经过验证,开始失败,其余的仍然可以验证.

我探索了两个提供商的源代码,结果发现SDK的默认提供商对错误形成的签名(虽然能够被恢复)有某种保护,而Bouncy Castle提供商没有它.查看 OpenJDK for Java 7(第336-344行)或 OpenJDK for Java 8(第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的值组成，它们如何编码并不重要，只要你最终收到正确的值即可。