Jce Cannot Authenticate the Provider Bc in Java Swing Application

JCE cannot authenticate the provider BC in java swing application

To expand on the comment from GregS, all JCE provider JARs must be signed before they will be trusted by your Java runtime.

BouncyCastle dutifully supplies signed JARs that will work without a problem. However, if you extract class files from this JAR, or recompile the source, it will remove the signature and cause Java to reject the code.

See this related SO question: How to sign a custom JCE security provider

JCE cannot authenticate the provider BC when using sshj

There are 2 classpaths in Java, the bootclasspath and the regular classpath. The bootclasspath is where java.* and javax.* are located (jre/lib/rt.jar). But because that is not loaded by the system classloader, it is not supported to drop signed/verified jars in there. You need to ensure that the BouncyCastle jars are on the regular classpath (as specified using the -classpath option in the JRE/JDK

Java JCE cannot authenticate provider BC in jarsplice created jar

You probably want to register the cryptographic service provider at runtime to ensure the configuration will work for everyone. You can use either of the Security.addProvider() or Security.insertProviderAt() methods. See documentation linked below under "Managing Providers".

• http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#Provider

Just use addProvider() unless the order of providers is somehow important for you. I saw one contributor commented that you might slot it in at entry #9, but I didn't see evidence that this is right for your configuration, so probably just an extraneous detail from his/her config file. Obviously, if I missed something about your configuration and you do need it there, then go for insertProviderAt().

GNU-CRYPTO: JCE cannot authenticate the provider GNU-CRYPTO

This is likely due to the fact that that project was integrated into GNU classpath. That means that the last signed provider was for 1.4. Up to 1.5 you had to create signed versions of your libraries for each Java version, so one for 1.4 is probably not compatible with 1.5 and higher (check for instance the bouncy class library, which has separate downloads for each version of Java up to 1.5). Furthermore, the certificate may have expired.

Please use cryptographic libraries that are actually maintained. There should be no need for GNU crypto in the first place.

BouncyCastle SecurityException throws only when the *bcprov*.jar is packaged into the generated JAR

I will speculate a bit, based on your description and without any experimentation, but I hope that it will help you satisfy your curiosity.

Java security providers that implement Cipher and some other services from javax.crypto must sign their code. If any of the signed BouncyCastle classes (or resources) were modified, the signature verification would fail, and the provider would not be available.

My guess is that in the process of re-bundling the content of the provider, Eclipse modified some files, invalidating the signature. The most likely culprit would be a change to a manifest. You could test this by computing the hash of every resource in the good and bad versions, and see if there are any discrepancies.

---

Related Topics