Toronto, Ontario
Geoff represents Fireball Technology Group: a Toronto-based software company focusing on delivering custom solutions for clients with unique needs.
April 16, 2005
 - Cryptography & JCE Overview
Cryptography is an important tool to secure communications. One such implementation is the JCE, offered for the Java software platform. This article discusses cryptography and the use of the JCE.

In the 21st Century, information is being exchanged electronically at an ever-increasing rate.  Financial markets, commerce, and communication between citizens of all nations are utilizing the Internet and proprietary networks to exchange sensitive information.  In pace with this trend are those rogue persons increasingly intercepting this information or supplanting it with misleading or erroneous messages.  To continue effectively in this space Java developers should be aware and capable of building components and architecting systems based on a reliable technology that can fit within a secure environment.  An available technology for securing facets of systems is Cryptography.

Cryptography[1] is an age-old science of securing information.  It is a powerful tool to wield when protecting secrets such as credit card numbers or contact information.  It has matured over the years and become a popular topic of research.  It is from this extensive research that the Java Cryptography Extension, or the JCE, was born.


Sun recognized that their Java programming language was being used to develop e-commerce systems.  To address the requirement for secrecy they offered the JCE to the Java community as a downloadable API from their website.   When Sun acknowledged that systems were increasingly using this API, they bundled it with the SDK in 2002.

The JCE is a pluggable technology.  Sun defined the JCE interface but the technology is quite flexible; it allows different entities to provide its implementation.  This facility was largely motivated by the fact that cryptographic products are under US federal export controls.  The US government maintained that cryptography products are “weapons” and mandated that they fall under federal export controls.

The strength of a JCE implementation is largely dependant on the key sizes that it supports.  Sun’s standard JCE implementation currently shipped with the SDK is in compliance with the US’s export controls.  This means any Java system utilizing Sun’s JCE implementation can be exported outside the US.  However, the cost of using this implementation means a reduction of the Java system’s strength.  The beauty of the JCE is that it is possible to develop a system honouring the JCE and plug in a stronger JCE implementation.  One such JCE implementation is Cryptix[2], an open source solution being maintained and developed by developers from The Netherlands and around the world.  The Cryptix solution is useful since the code is open, has an active community, and has deep experience writing cryptographic software.

Before a developer can take advantage of the JCE it is useful that he understand the technology on which it is based.  To this end the document will establish a few definitions and continue with a disclosure of cipher systems and protocols.  These will aid the reader with understanding the JCE as well as other documents related to cryptography.


Secret Key: A secret piece of information which is shared by two parties and used when securely exchanging information.  To be effective the secret key is smaller than the information to be shared.  It is used in conjunction with a cryptographic algorithm to encrypt or decrypt sensitive data.

Encrypt: The method of scrambling information to secure it against onlookers.  Encryption is used with a secret key that is known only by the sender and receiver of the sensitive information.

Decrypt: The method of descrambling information from a previous encryption.  Decryption requires the knowledge of a secret key.

Cryptographic Algorithm: Method which describes how a secret key is utilized to encrypt or decrypt information.  It is also known as cipher.

Plaintext: The information to be secured.

Ciphertext: The scrambled information after an encryption process using a cryptographic algorithm and a secret key.

The JCE includes an assortment of cryptographic algorithms to perform encryption and decryption.  Assuming a correct implementation, the greater the size of a secret key supported by an algorithm, the more secure an algorithm can be made.  Cryptographic algorithms are used in the context of two systems.

Cryptographic Systems

There are two systems used in cryptography: symmetric and asymmetric (or public-key).  Symmetric cryptography deals with keeping information secure with a single key; whereas asymmetric cryptography can secure information utilizing two keys.  In the case of public-key systems, information is secured with a publicly known key and decrypted only with the secret private key.

Symmetric cryptography has the advantage of being fast.  The operations it performs are transposition and substitution; which can be effectively expressed in hardware or software.   The problem with symmetric cryptography is that its secrecy relies on the privacy of the shared key.  An example of a symmetric cryptosystem would be one utilizing the DES (Data Encryption Standard), Blowfish, AES (Rijndael)[3] algorithm.

Asymmetric cryptography requires two keys (one to be kept secret, and another which can be publicly known).  This scheme is superior to symmetric systems because it can facilitate secure key exchange and authentication, but it does so at the cost of slower processing times.  Public-key systems use hard mathematical problems for the basis of their security.[4]

With these two systems various cryptographic protocols can be expressed and utilized for sharing secrets.

Cryptographic Protocols

In line with other security texts the author will use the characters Alice, Bob, and Eve.  The first two are representative of systems that want to engage in a secure information exchange.  Eve represents an entity who wishes to intercept sensitive information or to pose as Alice or Bob.

Consider that Alice and Bob are both intelligence operatives.  Alice wants to give Bob the coordinates of a valuable witness who is in a safe house.  The witness must show up in 8 days to testify at a court in The Hague.  Unfortunately both are on different continents: Alice lives in Toronto and Bob is located in Holland.  Alice does not want anyone else, like Eve, to find out where the witness is located, because Eve would surely divulge the location to the Mafia – the organization against which the witness will testify.  Eve is also interested in thwarting Bob’s attempts to find the witness and will do whatever it takes to push him off course.  Alice and Bob each have the use of the Internet and access to a Java development system, including a full strength implementation of the JCE.

Alice and Bob are knowledgeable in cryptography and Java development.  Over an insecure means Alice and Bob determine they will use the Rinjdael algorithm to scramble their information[5].  The next step is for each to consider a protocol with which both will use to securely and effectively exchange information.

Simple Symmetric Protocol

Alice may choose to use the simple symmetric protocol.   It requires that Alice and Bob establish a secret key with which the location can be encrypted.  The two need to somehow agree upon the secret key in a secure manner- like in a private conversation, for example.  The steps to accommodate a secure exchange using a simple symmetric system would be:

   1. Alice would type the witness’ location into a simple text file using an editor.
   2. Alice would use the Rijndael cipher from the JCE to scramble the text file using the secret key agreed upon with Bob.
   3. Alice would send the output of step 2 to Bob using email.
   4. Bob reads his email, expecting a scrambled bit of text from Alice, and uses his JCE decryption Java program to descramble the text using the secret key agreed upon with Alice.  Bob would now have the location of the witness.

Simple Asymmetric Protocol

In the previous situation Alice and Bob needed to agree upon a secret key for their secure communication in person.  However, in most circumstances it is not possible to establish the secret key.  In fact, since Alice and Bob live in different countries it is unlikely that physically meeting up with one another is feasible.  In these situations asymmetric or public key systems excel.

A public key system works in the following manner: Alice and Bob each have two keys, one of which is secret to themselves and the other which is publicly known.  The publicly-known key is registered with a trusted entity.  The property of a public key system is that the sender can encrypt a message using the intended recipient’s public key, and the only key which can decrypt the message is the recipient’s private key.  Each person keeps their private key to themselves.

In our example Alice and Bob establish their public and private keys on the first day of their job at the intelligence agency, a trusted entity for both.  The following describes the protocol undertaken for Alice to securely share the location of the witness to Bob.

   1. Alice retrieves Bob’s public key from a trusted source, from Bob himself or their employer.  (It is important that the public key be gotten from a trusted source – or else Alice may inadvertently encrypt the location with Eve’s public key).
   2. Alice types in the location of the witness in a text file and scrambles it using Bob’s public key
   3. Alice sends the scrambled text file to Bob using his email address.
   4. Bob opens up Alice’s email and descrambles its content using his private key, which no one else knows.  The location of the witness is revealed.

In this protocol an asymmetric cipher is required – such as RSA or ElGamal, two standard public key systems.  Alice and Bob decide to use ElGamal.

The problem with this scenario is that the processing cost of securely exchanging information is high.  Asymmetric systems are much slower than its symmetric counterpart.  For high volume systems this is a real problem for CPU-restrained systems.  For example, if Alice wanted to send a world map of the witness’ movements the process would be quite slow for both Alice and Bob.  A truly beneficial system would be one where Alice and Bob can securely agree upon a secret key through an insecure informational channel, without fear of Eve.  With the established secret key Alice could scramble the sensitive map and securely send it to Bob using a symmetric algorithm.

Hybrid Symmetric/Asymmetric System

Utilizing an asymmetric cipher it is possible for Alice to securely send a secret key to only Bob.  Eve could not determine it while it is in transit to Bob because it is encrypted with his public key (and the only way of decrypting such a message is with Bob’s corresponding private key).  Only Bob’s private key will descramble the secret key.  With the secret key known only to Alice and Bob, both can utilize their favorite symmetric algorithm, Rijndael, to securely exchange information.[6]

Alice and Bob decide upon this protocol and find no success in its use.  Alice and Bob know that each are operating within a secure channel – but Bob is receiving a large number of emails from Alice.  As Bob opens each one the contents are directing him to locations where the witness cannot be found.

After some false leads on the whereabouts of the witness, Bob is becoming more reluctant to trust the supposed encrypted emails from Alice.  He is receiving a large number of emails from Alice offering the location of the witness, but he can’t determine which one is correct.  He suspects that Eve is using his public key and sending emails to him feigning to be Alice.  There are only days left to find the witness before the important court appearance.  To address this, Bob calls Alice up on the telephone and instructs Alice to sign her emails so he can authenticate the origin of the emails.  Now, should Eve continue to try to send Bob off-track – Alice’s email can be picked out from the other junk emails.

Signing Protocol

In addition to facilitating secure key exchanges, public key systems also support the ability to sign a message, the electronic equivalent of a person’s written signature.  Specifically, it is with one’s private key that a person may electronically sign a document.  To reduce the amount of processing and overhead with signing large documents, hash functions can be used to reduce the effort.

Hash Functions

Hash functions are one-way operations that accept data and output it to a smaller set of data, called a message digest.  Only secure hash functions can be used with electronic signatures.  Hash functions are considered secure when it is computationally infeasible to find two different input data that result in identical message digests.  The SHA1 is one example of a secure hash function[7].

Alice can utilize the following steps to sign her email messages to Bob

   1. Alice types in the location of the witness into a text file using an editor of her choice.
   2. Alice performs a SHA-1 of the text file’s contents and scrambles it with her private key.  The hash function she uses is one that is highly secure and is known to Bob.
   3. She includes the output of this scrambled data at the end of the text file
   4. Alice encrypts the whole payload using Bob’s public key and emails it to Bob using his email address.

To read the payload and verify that Alice sent him the message, Bob must do the following:

   1. Open his email from Alice and descramble the contents using his private key.
   2. Perform a hash of the supposed location of the witness using the same hash function Alice used.
   3. Using Alice’s public key Bob descrambles the latter end of Alice’s email.
   4. If the output from #2 and #3 match, Bob can be sure Alice sent the email and the location of the witness is true.  Otherwise, Eve surely has tried again to lead him astray.

After receiving an authenticated email from Alice, Bob correctly finds out the whereabouts of the important witness.  Bob safely takes the witness to court in The Hague so that the valuable evidence can be heard.


Core Classes

The following is a description of the core classes that comprise the JCE.

Cipher Class

A Cipher is the main class with which encryption and decryption is performed.  Around this class the JCE framework is built.  An instance of the Cipher class embodies how information is scrambled or descrambled, as well as with what secret key it should use when doing its work.

A static factory method on the Cipher class is the means with which Cipher objects are created.  When factorizing a Cipher object, its transformation name is essential.  Additionally, it is possible to also specify the name of a JCE provider, in case there are two or more implementations available in the Java runtime environment.

A Cipher’s transformation name follows the format: algorithm/mode/padding.

In our example above, Alice and Bob could create a Cipher class with the following,

            Cipher cipher1 = Cipher.getInstance( “Rijndael” );

The mode describes how the cipher will scramble the information internally through its work.  Standards dictate how a cipher ought to be used and in what context.  Depending on the mode a Cipher instance may require an initialization vector (IV) which kick-starts the algorithm.

The padding describes how the information is padded when the plaintext is shorter than what is required by the cryptographic algorithm.

In each case, the provider of a JCE implementation will choose a default mode and padding if none are offered.  In our example, Alice and Bob have agreed upon a specific implementation so they do not require the extra qualifiers for the Cipher object they wish to instantiate; the common code will choose the correct defaults.

Before working with a Cipher object, it must be initialized.  The two oft-used modes are:


                        Specifies that the Cipher object will be used for encryption.


                        Specifies that the Ciphert object will be used for decryption.

These modes are required because cryptographic algorithms behave differently in encryption and decryption mode.  The other missing instantiation information is the Key.  The Key can be any class that implements the interface, or from some certificate that contains the appropriate key.

There are other parameters that can be used with initializing a Cipher object.   In all cases the parameters:

         1. Specify how the algorithm will perform its work,
         2. Embody a secret key with which the algorithm uses to perform its work, or
         3. Reference a specific random number generator[8].

Cipher Stream Class

The Cipher Stream classes provide a Java developer the means with which to perform encryption or decryption on conventional streams.

KeyGenerator Class

Symmetric algorithms require the use of a key to scramble the plaintext into ciphertext.  For systems that must create keys without user input, like SSL or PGP, some sort of key generator is required.  Important to this process is the fact that symmetric algorithms each have their own definition of what constitutes a weak[9] or valid key.  The KeyGenerator class solves the problem of automatically generating secure, acceptable keys.

Similar to the Cipher class, a KeyGenerator instance is created using:

            KeyGenerator kg = KeyGenerator.getInstance(“DES”);

Using the factory method, getInstance, the above line of source code creates a KeyGenerator instance for the DES algorithm.  Additionally, a JCE provider name could be added as a second parameter in case there are more than one provider offering KeyGenerator instances in its implementation.  With an instance, the KeyGenerator instance must be initialized.

A KeyGenerator instance can be initialized by specifying the keysize, a random number generator, both, or some algorithm parameters.  The keysize is an important parameter to consider when generating a key for an algorithm that supports many different key sizes.  A developer should always be sure how strong the keys are when implementing cryptographic protocols.

With a KeyGenerator instance setup, a secret key can be made available by simply calling:

            SecretKey sk = kg.generateKey();

With this SecretKey, sk, a Java developer can secure information.

In the adventures of Alice and Bob, the two could not reliably establish a secret key unless they were speaking to one another privately.  Since both lived on separate continents it became harder to establish their secret key.  To alleviate this they used an asymmetric cryptosystem to create a secure channel through which they would share their secret key.  It is through the use of the KeyAgreement Class that Alice and Bob were able to securely share their secret key in an insecure environment.

KeyAgreement Class

Consistent with the JCE, the KeyAgreement class is available to a developer using its getInstance method.  For example,

            KeyAgreement ka = KeyAgreement.getInstance(“DH“);

creates a KeyAgreement instance utilizing the Diffie-Hellman algorithm[10].  The KeyAgreement instance requires initialization and this can be done using a user’s private information.  Additionally a developer can provide reference to a secure random generator, or some algorithm parameters.

Once the KeyAgreement instance is initialized the doPhase method must be called in order to establish a secure channel.  The method is defined as:

            public   Key doPhase(Key key, boolean lastPhase);

For Alice and Bob, a single call to this method the other person’s public key using in place of key and lastPhase=true, is sufficient.  If there are more parties with whom the secret must be shared, then the generated Key must be shared with the participants and more doPhase invocations are required.  Please refer to the JCE documentation for more details on the KeyAgreement.doPhase method.

After the single invocation, Alice and Bob will be able to extract the secret key,

            byte[] establishedSecret = kg.generateSecret();

With establishedSecret Alice and Bob can securely exchange information utilizing it as their secretKey.

Mac Class

When exchanging information securely it is useful to determine if a rogue individual has intercepted the ciphertext and modified it.  The JCE facilitates this through the Mac class.


Cryptography is a powerful technology that creates secure channels in an insecure environment.  It allows intelligence agents, suppressed nationals, and businesses to exchange information securely with others.  This technology is important in the development of systems that exchange sensitive information.

The JCE is an implementation of cryptography for Java systems.  It empowers a Java developer to securely exchange keys, scramble information with a key and provide a means to descramble it.  However, this provision operates within a larger context.

The technology on which the JCE is based can only claim with high confidence that the exchange will be secure: the JCE provides no guaranteed security.[11]  For practical purposes I would not concern oneself with this comment.  It is recommended to stay relatively current with cryptographic advances and re-address the security of a system at regular intervals.  Pick secret keys that are appropriate for your application.[12]

It is also important to note that cryptography is not the silver bullet of system security.  Well administered firewalls, a commitment to secure processes, and many other security measures are as important to securing a system as incorporating the latest cryptographic technologies and protocols.


Secret Key: A secret piece of information which is shared by two parties and used when exchanging information securely.  To be effective the secret key is smaller than the information to be shared.  It is used in conjunction with a cryptographic algorithm to encrypt of decrypt the sensitive data.

Encrypt: The method of scrambling information to secure it against onlookers.  Encryption is used with a secret key that is shared with the sender and receiver of the sensitive information.

Decrypt: The method of descrambling information from a previous encryption.  Decryption requires the knowledge of a secret key.

Cryptographic Algorithm: Method which describes how a secret key is utilized to scramble or descramble information.

Plaintext: The information to be secured.

Ciphertext: The scrambled information after an encryption process using a cryptographic algorithm and a secret key.

Cryptography: The science of maintaining secrecy.

Cryptographic protocol:  A sequence of cryptographic actions, performed by at least two entities, that accomplishes a single task.  The JCE is capable of executing many types of cryptographic protocols.


C&O 437: Information Security.  University of Waterloo.

Applied Cryptography.  Second Edition.  Bruce Schneir

Cryptography: Theory and Practice.  Douglas R. Stinson. Computer Security Resource Center (CSRC), National Institute of Standards and Technology (NIST). Java Cryptography Extension (JCE) Reference Guide.  Sun Microsystems Inc.


[1] There is a wealth of knowledge available in the public domain regarding cryptography and the reader is invited to consult the vast array of books and websites devoted to the subject.

[2] The Cryptix JCE implementation is available for download at

[3] In 1997 the US government called for cryptographic algorithm submissions for a new encryption standard.  This standard would be called the AES (Advanced Encryption Standard).  The DES algorithm was the original standard and recent attacks on it created a need for a more secure algorithm.  Rinjdael, a Belgian offering, proved the best decision after much scrutiny and became the AES in 2000.

[4] The hard problems are part of a class of problems within the mathematical community for which there are no known efficient solutions.

[5] When considering the security of a cryptographic process the widespread assumption in the cryptographic community is the utilized algorithm and protocol, including implementation details, is known by everyone.  The point of this is that the security should never rely on the secrecy of an algorithm’s implementation but in the secret key and the resulting ciphertext.

[6] Well known systems that use this scheme are SSL and PGP.  In both examples, random numbers play an important role.  Compromises to both these systems were rooted in poor generation of random numbers.

[7] It is important to utilize the latest acceptable hash function when implementing your own cryptographic protocols.  When following industry protocols, the supported hash function will be defined for you.  MD5 is no longer considered secure.

[8] It is imperative that the SecureRandom class securely generate random numbers.  To change the behavior of Java’s SecureRandom random number generator, refer to the {JRE} file.  This file configures the Java security environment, including the JCE and the URL of the random generator using the ‘securerandom.source’ key.  By default SecureRandom on UNIX systems uses /dev/random and Microsoft’s CryptoAPI on Windows systems.

[9] Each algorithm has its own notion of a “weak key”.  A weak key exposes the resulting ciphertext to well-known exploits.  For example, a weak key, in hexadecimal format, for the DES algorithm is “0000000 FFFFFFF”.  Weak keys should never be used in a cryptographic process.

[10] The Diffie-Hellman (DH) key agreement’s security is based on public-key cryptography.  The problem on which DH relies is called the Discrete Log Problem (DLP).  The mathematical setup requires 3 numbers: a number P that describes a large pool of numbers (called a finite field), a number G that can generate every number in that field, and a random number X which becomes a user’s private key.  Note: these numbers make up the AlgorithmParameters that can be passed along to the KeyAgreement’s initialization method in the context of the Diffie-Hellman algorithm.

[11] Determining absolutely if the mathematics upon which the JCE is based provides uncompromised security amounts to the question, “Does P=NP?”  Researchers have searched for years and so far they don’t know absolutely one way or another, although they believe the answer is probably, ‘no’.  If the answer does indeed amount to ‘yes’ then most security systems will break down, including the JCE.  For more information on this question read about Complexity Theory or pages 239-242 in Applied Cryptography, by Bruce Schneier.

[12] Keys can have different sizes.  The larger the size the harder it is to use processing power to determine a key.  Pick a size that makes sense compared to the required amount of security.  For example, data worth $1,000,000 should be secured with a key that would require at least $1,000,000 in processing to crack it.  Please refer to the latest documentation available in the cryptographic community when considering secret key sizes.