In September 2000, the National Institute of Standards and Technology (NIST) approved the Federal Information Processing Standards (FIPS) 197(pdf 279.5 kb), culminating a multi-year effort to replace the out-of-date Data Encryption Standard (DES). As with DES, the new Advanced Encryption Standard (AES) should continue making inroads into private industry. This article looks at using AES in your Java programs.
What Is AES?
AES is a federal standard for private-key or symmetric cryptography. It supports combinations of key and block sizes of 128, 192, and 256. The algorithm chosen for this standard -- called Rijndael -- was invented by two Belgian cryptographers. As part of the evaluation process, the candidate algorithms (including Rijndael) were implemented in the Java language.
AES and Java Technology
The AES standard has been incorporated into several Java technology offerings. Beginning with the Java 2 SDK, Standard Edition (J2SE) v 1.4.0, the Java Cryptography Extension (JCE) was integrated with the SDK and the JRE. Since then, it has no longer been necessary to install the JCE optional package, since support for strong cryptography is now available as part of J2SE. JCE has a provider architecture that enables different providers to be plugged in under a common framework.
Several providers have supported AES in their own clean-room implementations of JCE, or under the existing framework. In Java 2 Platform, Standard Edition v 1.4.2, which is currently under beta, the Sun Provider, referred to as SunJCE, supports AES. Also, the Java Secure Socket Extension (JSSE) supports AES via JCE.
Finally, the Java Card specification version 2.2_01 supports AES with a 128-bit key size.
In this article, we will look primarily at AES support in J2SE, starting with JCE.
Using AES in JCE
Note: The programs listed in this article work only with Java 2 Platform, Standard Edition (J2SE) 1.4.2 installed.
You use AES like any other cipher. To see how, take a look at this JCE sample program. I've modified it to use AES, instead of Blowfish (another symmetric cipher). (I have changed occurrences of Blowfish to AES.)
As you can see, the changes I made to accommodate AES are very minimal -- the JCE framework is very general and extensible.
This sample program demonstrates how to use strong cryptography, which is available by default in most installations. This does mean that support for larger key sizes is normally unavailable. To use AES with 192- and 256-bit key sizes, you need unlimited strength cryptography.
Strong Versus Unlimited Strength Cryptography
Due to import-control restrictions imposed by some countries, the jurisdiction policy files shipped with the Java 2 SDK, v 1.4 only permit strong cryptography to be used. An unlimited strength version of these files (that is, with no restrictions on cryptographic strength) is available for download, however.
After installing the unlimited strength version, to use key sizes of 192 and 256 bits, simply provide the required length of the key. The following line of code illustrates how to set the key size to 256 bits:
The JCE examples given here show how to use AES for different key sizes, but they don't touch upon the more intricate issues -- like key management or key exchange algorithms. In practice, you may be more likely to use a protocol like Secure Socket Layer (SSL), which negotiates session keys using public keys that are subsequently used for bulk encryption.
Using AES in JSSE
Java Secure Socket Extension (JSSE) APIs are based around SSL, and the APIs are responsible for key negotiation and subsequent encryption and decryption. For a sample set of programs that illustrate the use of JSSE, see my earlier articles (listed in the See Also section, below). Since some of these articles are somewhat dated, note that the
Some of the cipher suites may not be enabled for optimization of startup time. When
You can use the
The following code illustrates the changes I made to the server program. The program uses regular expressions to prioritize AES encryption algorithms, with 256 bits as key size.
Here is the corresponding client code:
When running the server and the client, the output on the server side should be similar to the following:
This output illustrates that the AES 256-bit algorithms are set to higher precedence than the other available algorithms. The cipher suite
Note: For performance reasons, it's probably not a good idea to enable all the supported algorithms, but I've included them here for illustration purposes.
The JCE framework is a very powerful and flexible framework for using different cryptographic algorithms. It's based on a provider architecture that enables the same framework to be used for newer cryptographic algorithms. From a developer perspective, this means a higher level of abstraction, and a common set of APIs for newer and different cryptographic algorithms -- without the need to worry about the inner workings of the algorithm.
Some of the other Java security APIs -- such as JSSE -- are implemented on top of JCE, and supplement it to make the different cryptographic algorithms (ciphers, Message Authentication Codes (MACs), and Key Exchange algorithms) available to in a more developer-friendly manner.
Java World article on Java Security optional packages (reprinted in java.sun.com)
About the Author
Raghavan "Rags" Srinivas is a Java technology evangelist at Sun Microsystems, Inc. He specializes in Java technology and distributed systems. Srinivas has worked on several technology areas, including internals of VMS, UNIX® software, and NT.
Have a question about programming? Use Java Online Support.
Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.