More action with Struts 2
In a recent review of Struts 2 in Action, JW Blogger Oleg Mikheev notes that Struts 2 is "just a collection of extensions built upon WebWork, which is ultimately the right thing to learn before starting a Struts 2 project." While Struts 2 has some architectural flaws, Oleg calls WebWork well-designed, well-tested, and reliable. What are your experiences using Struts 2 and WebWork?

Also see "Hello World the WebWork way," a JavaWorld excerpt from WebWork in Action, by Patrick Lightbody and Jason Carreira.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Development Tools >

AES: Who won?

Discover the results of the Advanced Encryption Standard contest

By Raghavan N. Srinivas, JavaWorld.com, 10/27/00

Private-key cryptography has been used for ages, especially on the battlefield. It employs a shared-secret key for communication. By contrast, public-key cryptography, invented in the mid-1970s, relies on the notion of key pairs: a secret private key and a freely available public key. Public-key cryptography obviated the problem of reliable key distribution, a major drawback of private-key cryptography. On the other hand, private-key cryptography is much faster. In practice, a hybrid of these techniques is used -- public-key cryptography is used to set up a session key, which becomes the basis for subsequent communication with private-key cryptography.

Approved in 1977, the Data Encryption Standard (DES) was an early standard for private-key cryptography. (See the Sidebar for more on DES.) By 1997, it had become long in the tooth, so the National Institute of Standards and Technology (NIST) issued a Request for Comment (RFC) for a new standard -- the Advanced Encryption Standard (AES) -- to replace DES. The NIST planned to work closely with the cryptographic community to develop this next-generation private-key algorithm. Note: For further background on AES and a report from the third AES conference, held in April 2000, see Raghavan N. Srinivas's "AES: Cryptography advances into the future" (JavaWorld, April 2000).

For an introduction to computer security and cryptography, see "Java security evolution and concepts, Part 1: Security nuts and bolts" (JavaWorld, April 2000), also by Raghavan N. Srinivas.

The process

The cryptographic landscape had changed since the days of DES; the new standard needed to be small, hard to crack, fast, and suitable for small devices. These tough and sometimes conflicting requirements, as well as the perception that the government had botched the original DES development process, led to a common belief that the AES process was doomed under the NIST's direction. The National Bureau of Standards (NBS), which oversaw the DES process, had been widely criticized for its closed and highly secretive approach. The NIST, which morphed out of the NBS, made the AES process far more open by soliciting active input from the cryptographic community.

The requirements

In 1998, the NIST solicited from the industry algorithms that had to meet NIST-defined requirements. The algorithms had to:

  • Implement private-key cryptography
  • Be a block cipher
  • Work on 128-bit blocks and with three key sizes: 128, 192, and 256 bits


The NIST also stipulated that candidate algorithms had to be available worldwide on a nonexclusive, royalty-free basis. The NIST would evaluate candidates based on security margin, performance, and other factors. The institute left other questions about the selection process unanswered, including:

  • Would a single or multiple algorithm be selected?
  • Would the NIST insist on tweaks to the algorithm as a condition for selection?
  • Would the NIST use an arbitrary tiebreaking criteria to decide a close race?


Of course, nagging doubts persisted about whether the NIST was capable of reaching a solution that would satisfy both the cryptographic and user communities.

Resources