unlimited strength : Java Glossary

The government of the USA does not want other countries using long encryption keys, making it harder for the CIA (Central Intelligence Agency) to snoop, so they made it illegal for US companies to export the technology. This is ridiculous for four reasons:

1. All the algorithms are openly published.
2. You can acquire third party software outside the USA. People just bought their encryption from the Australians (BouncyCastle), Europeans… All this foolish bill did was penalise American encryption sellers.
3. To use Oracle’s unlimited strength version all you have to do in install two jars freely available from Oracle. All the code for unlimited strength is already present in the JDK (Java Development Kit). All you have to do is turn it back on.
4. The bill restricts SSL (Secure Sockets Layer) encryption export to 40 bits. Such a code can be broken with a PC (Personal Computer) in a matter of days. It is hardly better than no encryption at all.

However, the bill made an exception for Americans and Canadians. They could use good encryption. This is odd given the US government primarily spies on its own citizens.

So Oracle shipped Java with decent encryption turned off. To turn it back on, all you need to do is install a a couple of files. Terrorists are supposed to refrain from doing this. Only Americans and Canadians are supposed to use decent encryption. There is no check that you truly are Canadian or American.

Most people when they buy SSL/TLS certificates buy ones that do not require unlimited strength, but some buy unlimited strength it inadvertently.

How To Turn Unlimited Strength Encryption Back On

1. JCE unlimited strength encryption extension from the Oracle website. Make sure you select the version matching your JDK. I presume 1.8.
2. unzip/extract the downloaded jce_policy-8.zip file into your C:\UnlimitedJCEPolicy directory.
3. Inside you will find two files: US_export_policy.jar and local_policy.jar.
4. Track down all the existing copies of those two files on your hard disk. Look in places like:
   C:\Program Files\java\jre1.8.0_131\lib\security\local_policy.jar
   C:\Program Files\java\jre1.8.0_131\lib\security\US_export_policy.jar
   C:\Program Files (x86)\java\jre1.8.0_131\Java\jre8\lib\security\local_policy.jar
   C:\Program Files (x86)\java\jre1.8.0_131\Java\jre8\lib\security\US_export_policy.jar
   J:\Program Files\java\jdk1.8.0_131\jre\lib\security\local_policy.jar
   J:\Program Files\java\jdk1.8.0_131\jre\lib\security\US_export_policy.jar
   J:\Program Files (x86)\java\jdk1.8.0_131\jre\lib\security\local_policy.jar
   J:\Program Files (x86)\java\jdk1.8.0_131\jre\lib\security\US_export_policy.jar
5. Back up the existing copies or rename them.
6. Replace them by copying the corresponding downloaded files over top of them.
7. Verify the files have been replaced by checking the file sizes and times now installed.
8. If you have any version 1.7 JDKs/JREs, the version of the files for them and repeat the process.

The instructions in the zip are rather geekish. My instructions here should be all you need.

Bat File Replacement

Its is generally safer to compose a bat file to do the copying. Here is an example of what one might look like:

When Do You have to Reinstall the Policy Files?

• When you upgrade to a new major version, e.g. from 1.6 to 1.7 or 1.7 to 1.8.
• When you have uninstalled and reinstalled a JRE/JDK.
• I am not sure if this is necessary, but to be safe, any time you upgrade to a new minor version. If you find out if this is necessary, please let me know.