我需要验证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)
最佳答案
您做的还可以,实际上您别无选择。
但是,真正的问题在于itextpdf
的工作方式。密钥算法ECGOST3410
的名称为hardcodes BouncyCastle的名称,而同一算法的CryptoPro JCP名称为GOST3410EL
的名称。这使得像您的情况一样,很难切换为使用其他安全提供程序生成的密钥。
库可以使用Key.getAlgorithm()从键中获得相同的值,这将消除对硬编码的需求,并使库对安全提供者的依赖性降低。
考虑到PdfPKCS7构造函数允许选择安全提供程序,硬编码是一个特别糟糕的主意。