JCE History cheat sheet

JCE stands for Java Cryptography Extension; it began as an optional extension package (com.sun.crypto.provider, javax.crypto) that had to be downloaded and installed separately on top of the JDK.

JCE 1.2 was released in 1998 alongside JDK 1.2, introducing the javax.crypto package with Cipher, KeyGenerator, SecretKey, Mac, and the SunJCE provider.

Early JCE versions were export-controlled: strong cipher strengths required a separate unlimited-strength jurisdiction policy file download; weak default limits applied to symmetric key lengths.

JCE 1.2.1 and 1.2.2 were maintenance releases; JCE was bundled into the JDK starting with J2SE 1.4 (2002), ending separate installation.

The Java Cryptography Architecture (JCA) predates JCE and covers digests, signatures, keys, and certificates; JCE extended JCA with encryption, key agreement, and MAC services.

JCE 1.2 introduced provider-based architecture: algorithms are supplied by providers registered via java.security.Security, with SunJCE as the reference implementation.

The 2000s saw export policy liberalization; by JDK 8 update 161 (2018), unlimited-strength crypto became the default, removing the need for policy file overrides.

Key historical milestones to anchor: 1997 JCE 1.1 (limited), 1998 JCE 1.2, 2002 bundling in J2SE 1.4, 2004 JCE in J2SE 5.0 with AES support, 2018 default unlimited strength.

The U.S. Export Administration Regulations (EAR) classified strong encryption as dual-use; JCE's early key-length restrictions (e.g., 128-bit max for some algorithms) reflected these rules until liberalization.

The 'unlimited strength jurisdiction policy files' mechanism (local_policy.jar, US_export_policy.jar) was the official workaround for export limits and remained until JDK 8u161.

JCE 1.2's reference implementation was Sun's; third-party providers (Bouncy Castle, IBM, RSA) emerged to supply algorithms Sun could not export or had not implemented.

Bouncy Castle was created in 2000 as a clean-room JCE provider, notable for early AES and elliptic curve support before Sun's provider caught up.

The JCE API's design was influenced by the failure of earlier ad-hoc crypto APIs; the provider/service model was intended to allow algorithm independence and pluggability.

In 2004, J2SE 5.0 added AES to SunJCE and introduced the SunPKCS11 provider, bridging JCE to hardware security modules.

The 2017 Java SE 9 modularization moved JCE into the java.base and jdk.crypto modules; the javax.crypto package remained in java.base.

Historical deprecations: DES and DESede remained but were discouraged; RC4 and MD5-based constructions were removed or disabled in later JDKs (e.g., RC4 disabled by default in JDK 8u).