Feature: Goodbye DES, Hello AES

Security products should begin rolling out this year based on Advanced Encryption Standard, which the U.S. government has selected to replace the current Data Encryption Standard, AES' predecessor.

The National Institute of Standards and Technology (NIST) in October selected Rijndael (pronounced "rain doll"), the combined work of Belgian researchers Vincent Rijmen and Joan Daemen, as the basis for AES.

Rijndael was selected from among five finalists in a process that took more than three years.

Although a fundamentally sound algorithm, the older DES, which dates back to the 1970s, has been proven to be breakable through brute-force attacks because it uses a relatively small key size (56 bits).

---

AES vs. Triple-DES

---

As a practical matter, anyone today who wants high security uses a more powerful version of DES called Triple-DES.

To start encrypting with Triple-DES, two 56-bit keys are selected. Data is encrypted via DES three times, the first time by the first key, the second time by the second key and the third time by the first key once more. This process creates an encrypted datastream that is unbreakable with today's code-breaking techniques and available computing power, while being compatible with DES.

However, one does not need to be a cryptographer to see future problems with Triple-DES. Needing to encrypt a singular piece of data three times before transmitting it is CPU-intensive. While encrypting data today is the exception, not the rule, it's likely that encryption will become more prevalent in the future.

With the rise in the use of the Internet and devices such as smart cards, cell phones and PDAs, the need to communicate securely will increase. But these smaller devices require an encryption standard with a smaller footprint that uses less resources. Triple-DES is not a workable solution for the future.

While security and network administrators are loath to upgrade their systems to add another encryption algorithm, they will eventually need to support AES.

Unbreakable security

AES has more elegant mathematical formulas behind it, and only requires one pass to encrypt data. AES was designed from the ground up to be fast, unbreakable and able to support the tiniest computing devices imaginable. The big differentiators between AES and Triple-DES are not strength of security, but superior performance and better use of resources.

The next step is getting AES out of the mathematicians' hands and into products. NIST is writing the formal standard for AES, with a targeted completion of later this summer. The formal standard will then have a permanent Federal Information Processing Standard (FIPS) number associated with it (DES and Triple-DES are FIPS 46-3). The algorithm itself is widely available and a limited number of products are already being released that support it.

Adoption will likely fall into two categories: upstart vendors seeking to gain market share and notoriety by being early adopters, and established market leaders that are in less of a rush.

RSA Security, developer of widely used encryption algorithms and developers' tool kits, has announced its intention to support AES, but will likely wait until the FIPS number is assigned this summer. RSA was one of the AES finalists whose algorithm did not get selected. CheckPoint Software is working on beta versions of AES for its products.

Cisco released a position paper in February stating an intention to support AES. Cisco also pointed out that as a practical matter AES won't be widely implemented until it moves through the Internet Engineering Task Force (IETF).

For VPNs, the IETF needs to specify how AES should be implemented within the IP Security standard to maintain compatibility in a multivendor network. The same type of definitions must be developed for Secure Sockets Layer, the encryption process for Web browsers and Web servers.

Most vendors will probably begin shipping products with AES this fall because delaying any longer risks exclusion from federal contracts (Triple-DES will still be a government-approved method, but it is logical to expect that products compatible with both methods will be preferable). AES should be widely implemented by 2004.

The reasons IT executives will want AES in their networks are well-aligned with the reasons AES was developed in the first place: It provides faster encryption and compatibility with the widest range of devices. Without AES, it will be necessary to have different encryption technologies for application-specific purposes, such as wireless e-mail, financial transactions or quality-of-service-specific applications.

The biggest benefits that IT executives will see in adherence to the AES standard are those normally associated with standardization. Reduced prices, greater compatibility, more innovation and increased flexibility will all be outcomes of getting the industry to support AES.

An important step for IT departments to take is to specify AES compatibility on requests for proposal for data processing equipment that will be performing encryption. If it currently isn't supported, it is wise to push for a firm support date and a free upgrade at that time.

What about researchers Rijmen and Daemen. Will they become rich and famous over their contribution?

As part of the process for submitting algorithms for consideration, developers had to agree to put their creations into the public domain and receive no royalty payments whatsoever.

So other than receiving a lot of attention and being considered national heroes, the creators derive no other benefits from their hard work.

---

Reavis is a freelance writer and security consultant. He can be reached at jim@reavis.org.

Error 404--Not Found

From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1: 10.4.5 404 Not Found The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.