2

我需要验证 pdf 文件中的数字签名。
我使用itextpdf和cryptopro

cryptopro为所需算法提供这些别名：

, JCP: Signature.GOST3411withGOST3410EL -> ru.CryptoPro.JCP.Sign.GostElSign
  aliases: [1.2.643.2.2.3, OID.1.2.643.2.2.3, 1.2.643.2.2.9with1.2.643.2.2.19]

itextpdf尝试获取“GOST3411withECGOST3410”并失败：“没有这样的算法：提供者 JCP 的 GOST3411withECGOST3410”

这有效：

Provider prov = Security.getProvider(PROVIDER_NAME);
prov.put("Alg.Alias.Signature.GOST3411withECGOST3410", "GOST3411withGOST3410EL");

虽然不确定这是正确的方法。

Exception in thread "main" ExceptionConverter: java.security.NoSuchAlgorithmException: no such algorithm: GOST3411withECGOST3410 for provider JCP
    at sun.security.jca.GetInstance.getService(GetInstance.java:70)
    at sun.security.jca.GetInstance.getInstance(GetInstance.java:190)
    at java.security.Signature.getInstance(Signature.java:324)
    at com.itextpdf.text.pdf.security.PdfPKCS7.initSignature(PdfPKCS7.java:692)
    at com.itextpdf.text.pdf.security.PdfPKCS7.<init>(PdfPKCS7.java:452)
    at com.itextpdf.text.pdf.AcroFields.verifySignature(AcroFields.java:2349)
    at org.foo.PdfVerifier.verify(PdfVerifier.java:83)
    at org.foo.PdfVerifier.main(PdfVerifier.java:53)
4

1 回答 1

2

你所做的是好的，实际上你别无选择。

然而，真正的问题在于工作方式itextpdf。它硬编码 BouncyCastle 的关键算法名称ECGOST3410，而 CryptoPro JCP 具有GOST3410EL相同算法的名称。这使得切换到使用不同安全提供者生成的密钥变得困难，就像你的情况一样。

该库可以使用Key.getAlgorithm()从密钥中获取相同的值，这将消除对硬编码的需要，并使库更少“依赖于安全提供程序”。考虑到PdfPKCS7构造函数允许选择安全提供程序，硬编码是一个特别糟糕的主意。

于 2014-02-21T11:21:44.033 回答