Local_Policy.Jar and Us_Export_Policy.Jar Different with Unlimited Strength VS Default

local_policy.jar and US_export_policy.jar different with Unlimited Strength Vs Default.

Does every JDK bundle comes with local_policy.jar and US_export_policy.jar ?

yup. JCE has been integrated into the Java 2 SDK since the 1.4 release.

What is the limitation in default local_policy.jar and US_export_policy.jar. Is it the key size ?

Yes it is the key size. I thing more than 128 bit is not allowed. You can check the maximum size of the algorithm using int maxKeyLen = Cipher.getMaxAllowedKeyLength("AES");

If I need to use 128 bit keys does it required to go for Unlimited Strength Java Cryptography Extension

For 128 bit key encryption I dont think you need Unlimited Strength Java Cryptography Extension jars. Default ones should work just fine.

Is there a way I can keep these two jars in external path and load it. Because I have more 50 servers rather than coping in each JDK I would prefer to maintain it in a central place.

As mentioned above this scenario should not occur if you are using 128 bit key for encryption but if you are using more lengthy key (Eg 256) you will need to get unlimited strength jars and replace them in $JAVA_HOME/jre/lib/security. As it is in the JDK/JRE itself you cannot make it centralized not in case of distributed servers. You will need to replace it on each of your servers.

Refer oracles reference guide.

Also if you don't want to do this you can refer to following thread for alternatives -

How to avoid installing “Unlimited Strength” JCE policy files when deploying an application?

Reflection is user in the thread as a work around. Though I would not recommend it you can take a look at it.

I have summarized everything in a post. You can refer that too -

How to install Java Cryptography Extension (JCE) unlimited strength jurisdiction policy files

How to install Unlimited Strength Jurisdiction Policy Files?

You need to determine your Java home path (either via System.getenv("JAVA_HOME") from Java or $ echo $JAVA_HOME on the command line). It should be a path like the following:

C:\Program Files\Java\jre8 on Windows
/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home on Mac OS X
/usr/java/jdk1.8.0_101/bin/java on *nix

You then need to copy the US_export_policy.jar and local_policy.jar files you downloaded into the directory: <JAVA_HOME>/jre/lib/security and overwrite the existing files of the same name.

Updated 05/17/17

The following code (for demonstration purposes only) will instruct the JVM that it is allowed to use AES-256 bit encryption and corresponding TLS ciphers regardless of the policy files installed. It is not recommended to employ this method.

if (Cipher.getMaxAllowedKeyLength("AES") < 256) {
  try {
    Field field = Class.forName("javax.crypto.JceSecurity").
    getDeclaredField("isRestricted");
    field.setAccessible(true);
    field.set(null, java.lang.Boolean.FALSE);
  } catch (Exception e) {
    fail("Could not override JCE cryptography strength policy setting");
    fail(e.getMessage());
  }
}

JCE deployed with project instead of JDK update

If you mean "Unlimited Strength Jurisdiction Policy Files" with JCE, then you cannot achieve what you need with any kind of packaging. These policy files need to be installed to the running JVM, and thus you cannot solve this problem either programmatically or via different packaging options.

To achieve what you need, you have to use BC throgh their own API, rather then calling JCE functions and specifying "BC" as the provider since it will fail because of policy/security checks. You can walk around this check only by using BC API (or any other crypto library) directly.

Local_Policy.Jar and Us_Export_Policy.Jar Different with Unlimited Strength VS Default