HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Java programmers are network programmers and increasingly, network programmers write applications that need encryption technology. The Internet is like a huge chat room. Not only is it a worldwide sniffable net, it's developing its own unique business infrastructure. New virtual services are required to provide the confidence in business transactions that has been available through a paper-based system. In addition to privacy, Internet commerce demands digital forms of signature, currency, notarization, purchase orders and receipts. Many of the most important Internet applications can be created only with the support of sophisticated cryptographical techniques. One of the great things about using Java is that it potentially allows the developer control over both the client and the server. New crypto classes will allow creation of applets that can provide security services within existing browsers.

Because of the wide variety of applications and circumstances, many different encryption algorithms have been created and are available for use by Java programmers. The encryption algorithms discussed in this article are well-proven and have withstood many cryptanalytic attacks. Their strength lies not in their obscurity, but in their ability to resist cracking attempts even by cryptanalysts familiar with their internal workings. All other things being equal, for any given algorithm, the longer the key, the harder it is to break enciphered files. Any of these algorithms could be broken by brute strength - systematically trying each possible key until the correct one is discovered - but choice of a sufficiently long key makes this computationally infeasible.

Symmetric, or private key, algorithms use the same key for encryption and decryption. While they are exponentially more efficient than asymmetric algorithms, the need to securely share a single key complicates their use over a network. Complex key exchange methods have been developed in order to pass a key from the transmitter to the receiver without compromising its confidentiality. Symmetric algorithms take two different forms, stream ciphers and block ciphers. Block ciphers (usually the block size is 64 bits) are more commonly used on the Internet today, but stream ciphers, which encrypt a bit at a time, will become more popular as the demand for private multimedia transmissions grows.

There are several secret key block ciphers of proven robustness in use on the Internet. Blowfish is a variable key length algorithm (up to 448 bits) developed by Bruce Schneier. It is designed to be efficient and compact. IDEA (International Data Encryption Algorithm) was developed in Switzerland and uses a 128-bit key. IDEA is widely used today for Pretty Good Privacy (PGP) e-mail. RC4 was developed by RSA Data Security, Inc. Although it can accept a key of any length, at the time of this writing 40-bit keys are the longest which can be exported from the United States without obtaining a special export license. Even without having access to the algorithm, its export status is a clear sign to many cryptographers that RC4-40 is probably not very robust. A recent demonstration showed how amateurs could break it within eight days and there are persistent rumors that the U.S. Federal government can break it in real-time. Web browsers and serversexported from the US use RC 4-40.

DES was developed over twenty years ago at IBM for use by the U.S. Government. It uses 56-bit keys and some experts, anticipating continued growth in computing power, believe that it is no longer suitable for data that must be protected beyond a few years. Triple-DES, which can use three different keys to encrypt the same data three times, is significantly stronger and triple-DES encryption libraries are available for Java.

Asymmetric algorithms, commonly called public-key cryptography, use two different keys. Either key can encrypt the file and only the other one can decrypt it. Given sufficient key length, it is not computationally feasible to derive the first key from the second key and encrypted text. One key is always maintained as a private key and the other, the public key, is freely distributed. Because it is less efficient than symmetric algorithms, asymmetric encryption often is used to encrypt unique session keys that can be used with a symmetric algorithm. The most common public key encryption system is RSA, which is owned by RSA Data Security, Inc. (although some of the patent just expired in April, 1997). Keys for asymmetric algorithms are much longer than the keys used for symmetric algorithms. 1024-bit keys are commonly used for the RSA algorithm.

Hash functions are a form of encryption that create a fixed length output which cannot be turned back into the original data; sort of a compression algorithm on hormones. Common examples include checksum utilities and the password field in both UNIX and NT password files. Hash algorithms useful for electronic commerce usually have an output of at least 128 bits and must have an even distribution of bits in the output that provides no clue as to the size or composition of the hashed object. They are used to provide positive identification of a data object. The secure hash algorithm MD5 (Message Digest 5) was developed by RSA Data Security, Inc. It provides 128-bit output. The U.S. Government has promulgated a newer hash function called SHA (Secure Hash Algorithm) that produces a 160-bit hash, so it is probably stronger than MD5.

Session keys are usually created using random number generators. The standard random function available to computer programmers is not strong enough to support robust cryptography. The first reported failure in SSL was due to a flaw in the random number generator that allowed an attacker to limit the number of possible encryption keys, dramatically simplifying a brute force decryption attack. Because of the importance of random number generation, encryption libraries often include a cryptographically secure (appropriate) random number function.

The previous article in this series (JDJ, Vol. 2, Iss. 4) discussed the use of digital signatures to identify trusted applets. Most digital signature applications work just like the javasign utility. An object is subjected to a cryptographic hash algorithm, the output is encrypted with the signer's private key and the resulting signature and original object are bundled into a standardized archive format or envelope. The signature is verified by hashing the original object and comparing that result to the signature after decrypting it with the signer's public key. Properly applied, a digital signature has five properties that make it ideal for many forms of network trust mechanisms.

  1. The signature is authentic: the object could only have been signed by a specific key (presumably, it was deliberately signed by that key's owner).
  2. The signature is unforgeable: It's virtually impossible to recreate the original key or otherwise make an object appear to be signed by a key without actually having that key.
  3. The signature is not reusable: Because it is based on the hash output, a signature can only be used with a specific object.
  4. The signature cannot be repudiated: The owner of the private key can never claim that the document was not signed with that key.
  5. The signed document is unalterable: Even a one bit change in the document would change the hash output, resulting in an unacceptable signature.
In practice, a digital signature usually contains a time stamp. In many cases, the second party might not trust the first party to accurately time stamp a document before signing it, or a signer might even attempt to backdate a document by changing their computer's clock. A digital notary can solve this dilemma. Such a service would accept a signed object from the originator, time stamp it and then sign it with their own private key. Provided the recipient trusts the notary - and notaries go to great lengths to prove their trustworthiness - they can then be confident that the document was not only signed by the originator, but was received by the notary service at a specific time. On the Web, such a service could be useful for notarizing orders, order receipts, delivery receipts, laboratory test results, consulting time or electronic time cards. Several firms are working towards offering such a service.

This subject will be continued in the next issue with guidelines for choosing an appropriate encryption technology and using it either as a Java class or instead taking advantage of the encryption services already available on the Web. The next article will also include a guide to available JDK 1.1-compatible encryption libraries.

About the Author
Jay Heiser is the Director of Internet Products for HomeCom Internet Security Services, where he is currently providing network security consulting to several major financial institutions and retail chains. He has lectured on information security in the US and Europe at events such as InfoWarCon, The Internet Conference, and FOSE. Jay also has animated several presentations on basic network security topics and made them available on the Web at http://www.homecom.com/services/hiss/LearnAbout.html.
He can be reached at [email protected]


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.