This topic is usually only of interest for old versions of Java 6, 7 and 8 as since around the year 2018, unlimited encryption is the default. For those old versions, see the information below:
If one of the following exceptions is thrown in your application while trying to use strong encryption with key lengths of more than 128 bits, the cause for this is most likely a missing Java Cryptography Extension (JCE):
- java.security.InvalidKeyException: Illegal key size
- Cryptographic key type aes256-cts-hmac-sha1-96 not found
- Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled
For Azul Zing versions released before the year 2018 (versions 17.12.x.x and older), the solution is to install the Zulu Cryptography Extension Kit (Zulu CEK). Azul Zing and Azul Zulu ship with strong encryption, though limited to key lengths of up to 128 bit in earlier versions. The Zulu CEK provides an upgrade to 'unlimited' key sizes. After installing the Zulu CEK, you can use for example AES 256 bits for https, SSL/TLS, Kerberos or other applications of encryption.
The Zulu CEK is compatible with Java versions 6, 7 and 8.
For Azul Zing versions released in 2018 and later (version 18.1.x.x and newer) no configuration or installation of JCE is necessary any more as the unlimited encryption is enabled by default. Azul Zing follows the OpenJDK strategy here which changed to this setting with 8u161. If your application requires the old limited policy for compatibility reasons, you can switch back to it by either adding the line crypto.policy=limited to /opt/zing/zing-jdk8/jre/lib/security/java.security or adding the line Security.setProperty("crypto.policy", "limited") to your code.
For Azul Zing versions release in the end of the year 2017 (17.11.x.x and 17.12.x.x), all the above solutions are usable to facilitate the transition. The only difference towards Azul Zing versions release in 2018 and later is the default setting, which is set to limited on 17.11.x.x and 17.12.x.x as it was with OpenJDK 8u152.
For Azul Zulu: The CEK is no longer needed beginning in versions released of Jan 2018 (e.g. Zulu 8.27, 7.22, 6.19 and up) since they use the unlimited strength policy by default.
Add Comment
Comments
Im not a computer science major, and everything listed above makes no sense to me. I am trying to download software from GE. Specifically GE Element, and I need to have Java Azul downloaded in order for it to run. I don't know which Azul download to select.
Jonathon, thanks for opening a ticket by emailing support at azul.com. I hope we have now answered your question.
Hi and quick question. I'm running zulu17.34.19-ca-jdk17.0.3-linux_x64. As I understand it, the JCE (or CEK) should be packaged with this JDK, as a default.
However, while a client using this JDK and attempts to authenticate against Kerberos, it receives a "Caused by: javax.security.auth.login.LoginException: KDC has no support for encryption type (14) - BAD_ENCRYPTION_TYPE" error from the KDC.
I can fix this issue by adding "allow_weak_crypto=true" to the client side krb5.conf, but that makes me a little nervous. I'm wondering if this is a real problem, or just failing because the encryption type Zulu uses isn't specified in the list of supported_enctypes, specified on the KDC.
Can someone please confirm that the JCE/CEK is packaged with this JDK? If it is, is there something I need to do to enable it? Lastly, If it's packaged and enabled by default, what encryption type is being used?
Thanks
Article is closed for comments.