我有一个奇怪的问题。我编写了一个 Java 应用程序来执行一些加密操作(使用 AES 加密并使用 ECDSA 进行数字签名)。我决定使用 BouncyCaSTLe API...我在 Eclipse 中尝试了我的应用程序，一切都很顺利。然后，我使用 Eclipse 向导将应用程序导出到“可运行的 JAR 文件”中，并选择了“将所需的库打包到生成的 JAR 中”选项。 然后我启动 JAR，应用程序抛出了不幸的著名异常
java.security.NoSuchProviderException: JCE cannot authenticate the provider BC
所以，我在这里和其他网站上读到了一些内容。有人写道，有必要修改 java.security 文件并添加 BouncyCaSTLeProvider。我还将 BouncyCaSTLe 的 JAR 添加到 jre/lib/ext/中，但仍然抛出异常。然后我发现有人写道我需要更改 JAR 中的库导出顺序。 因此，受此启发，我使用选项“将所需的库复制到生成的 JAR 旁边的子文件夹中”重新导出了 JAR。 我运行新的 JAR，一切都很顺利。 在这篇大介绍的最后(感谢您的耐心)我的问题是:为什么现在没有抛出 SecurityException？为什么将库从 JAR 中取出会起作用？ 编辑:我已经解决了问题并且我明白为什么抛出异常， 但我不明白为什么，在外部子文件夹中导出 bcprov 问题就消失了。
最佳答案
根据您的描述，我会在没有任何实验的情况下进行一些推测，但我希望这能帮助您满足您的好奇心。
实现 Cipher 和 javax.crypto 中的一些其他服务的 Java 安全提供程序必须对其代码进行签名。如果任何已签名的 BouncyCaSTLe 类(或资源)被修改，签名验证将失败，并且提供程序将不可用。
我的猜测是，在重新捆绑提供程序内容的过程中，Eclipse 修改了一些文件，导致签名无效。最有可能的罪魁祸首是 list 的更改。您可以通过计算好版本和坏版本中每个资源的哈希值来测试这一点，看看是否有任何差异。
关于java - 仅当 *bcprov*.jar 打包到生成的 JAR 中时，BouncyCaSTLe SecurityException 才会抛出，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30580073/