Most read:
Popular archives:
Java Q&A Forums - Let the great migration begin
We're pleased to announce the first phase of the integration of the Java Q&A Forums with our community platform, JavaWorld's
Daily Brew. Whether you're one of our longtime forum users or a brand newbie, we hope you'll visit the Java Q&A Forums in their new home alongside JW Blogs.
| Enterprise AJAX - Transcend the Hype |
| Oracle Compatibility Developer's Guide |
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 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.
In 1998, the NIST solicited from the industry algorithms that had to meet NIST-defined requirements. The algorithms had to:
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:
Of course, nagging doubts persisted about whether the NIST was capable of reaching a solution that would satisfy both the cryptographic and user communities.