1.3 Java Cryptography Extension (JCE)
Strictly speaking, the JCE extends the JCA by simply exposing more engines and including an additional provider, the SUNJCE provider, that includes one or more implementations for each engine. Recall that the separation between the JCA and the JCE was a result of political situations, not technical limitations. The JCE places its classes in a different package, javax.crypto.*, and it has several idiosyncrasies as we'll see shortly. We've already seen what engines the JCA includes, now let's shift our focus to the JCE engines. The following engines are specific to the JCE:
■ Cipher performs encryption and decryption operations
■ KeyGenerator produces secret keys used by ciphers
■ SecretKeyFactory similar to the JCA's KeyFactory, but operate exclusively on SecretKey instances
■ KeyAgreement embodies a key agreement protocol for multiple parties to dynamically create a shared secret among them
■ Mac provides message authentication code functionality
Together, the JCA and the JCE represent a complete cryptographic platform. However, this platform is not without its idiosyncrasies. A common criticism often cited is that the disjunction between the JCA and the JCE is too visible. Developers are forced to remember which package an engine resides in—is it a JCA engine located in the Java, security package or is it a JCE engine located in javax. crypto package? Another less obvious architectural difference lies in the class hierarchy. The JCA follows a stringent pattern, where the abstract engine class, e.g., Engine, extends another class with an identical name and SPI suffix, e.g., EngineSpi. The JCE, however, doesn't follow this pattern. For example, the
JCE Cipher engine neither declares itself abstract nor does it extend the CipherSpi class. Despite these differences, fortunately the key concept—looking up an engine implementation via a factory method—remains in tack. Recently, there have been calls to refactor these libraries into a single, more consistent library, especially since the political boundaries that existed have been removed and both libraries ship as part of JDK 1.4.
Overlooking these differences between the JCA and JCE, it is important to have at least a rudimentary understanding of the underlying architecture a provider must implement. Providers follow a strict set of rules denned by the SPI. The next section will provide developers with a high level understanding of the SPI.
|