java - 如何为java.security.Provider添加别名?

标签 java security gost3410

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

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 的工作方式。它对 BouncyCaSTLe 的关键算法名称 ECGOST3410 进行了硬编码,而 CryptoPro JCP 则对同一算法具有 GOST3410EL 名称。这使得很难切换到使用不同安全提供商生成的 key ,就像您的情况一样。

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

关于java - 如何为java.security.Provider添加别名?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/21913413/

相关文章:

java - 通过类名查询实体

c# - 将非 MVC 相关属性应用于 MVC 操作

security - 每次在VS2012中打开解决方案时,都会重置IIS express applicationhost.config安全性

java - Google App Engine JDO 增强失败

java - http ://java. sun.com/jsp/jSTL/core 和 http ://java. sun.com/jSTL/core 之间的区别

java - 在android中搜索一个网站

php - 在社交网络 Web 应用程序中应该在什么级别实现安全性?

java - 如何在 Java 客户端中启用 GOST 密码

security - OpenSSL 和 GOST 引擎问题(静态链接)