Is Unlimited JCE Working? How to Actually Test It
Luke Hebert
- 3 minutes read - 426 wordsDeploying Java apps that use AES-256 or other strong ciphers? The first thing to confirm is whether your JDK actually allows it. This post covers which releases include Unlimited Strength JCE out of the box and gives you a two-line test to verify your runtime.
Which JDK Releases Include Unlimited Strength by Default
Starting with the releases listed below, the Unlimited Strength policy files are bundled and enabled out of the box. No manual download or installation is required.
- Java 9 and later (10, 11, 17, 21, etc.): Any official release ships with unlimited strength enabled.
- Java 8u161 or later: Available directly from Oracle’s download site.
- Java 7u171 or later: Available only through My Oracle Support.
- Java 6u181 or later: Available only through My Oracle Support.
If you are running an older build than the versions above, you will need to download the policy files from Oracle and place them in $JAVA_HOME/jre/lib/security (or $JAVA_HOME/lib/security for JDK 9+).
Verifying Your Environment
The quickest way to confirm that unlimited strength is active is to ask the Cipher class for the maximum allowed AES key length. A value of 2147483647 (effectively unlimited) means you are good. A value of 128 means the restricted policy is still in effect.
import javax.crypto.Cipher;
class Test {
public static void main(String[] args) {
try {
System.out.println("Hello World!");
int maxKeyLen = Cipher.getMaxAllowedKeyLength("AES");
System.out.println("Max AES key length: " + maxKeyLen);
} catch (Exception e) {
System.out.println("Sad world: " + e);
}
}
}Compile and run it against the target JDK:
javac Test.java
java TestIf you see Sad world in the output, the Unlimited Strength policy is not enabled for that runtime. Check your JDK version against the list above, or install the policy files manually.
A Few Practical Notes
On JDK 9 and later the policy files were removed entirely. The crypto.policy property in java.security is no longer read, and unlimited strength is the only mode. If you see documentation referencing local_policy.jar or US_export_policy.jar, that guidance applies to JDK 8 and earlier only.
- For containerized deployments (Docker, Kubernetes), make sure the base image you pull actually contains a JDK build at or above the thresholds listed above. Some minimal images still ship older 8u builds.
- If you are migrating from a restricted environment, watch for
InvalidKeyExceptionorIllegalKeySizeExceptionin application logs. Those are the classic symptoms of a 128-bit cap still being enforced.
Keeping your JDK current is the simplest long-term fix, but the test program above gives you a fast, repeatable check whenever you spin up a new environment.