Slashdot Mirror

superid asks: "Our facility is just beginning to install small wireless 802.11b networks to support our office developers and staff. I think most people end up happy with wireless and enjoy the freedom. Our little branch office has about 100 people and our whole facility has close to 3000 people, so it's reasonable to expect our wireless needs to grow. However, I have just received an email, sent to all network administrators of our facility, directing us to shut down all wireless devices until they are certified by our Information Security department. Of course I'm not surprised by this. I'm aware of the problems with WEP and tools like airsnort. I know there are numerous security products and projects, but can any of them trace a lineage back to FIPS? Wouldn't it be a major victory to see an OSS product listed as validated by NIST?"

"Here are the certification requirements:

Encryption must be implemented end-to-end over an assured channel and shall meet the FIPS 140-1 or 140-2, Overall Level 2 (Triple-DES or AES) standard, at a minimum.

I know there are uncertified software solutions, but for ease of integration, our office has chosen AirFortress for a hardware solution. This will run us about $2,500 for our small office and is quite reasonable. However, it would be nice if there was an Open Source solution as well. The difference is that any OSS solution must be 'certified'."

LordPhatal writes "NIST researchers have demonstrated a new kind of atomic clock that has the potential to be up to 1,000 times more accurate than today's best clock. The new clock is based on an energy transition in a single trapped mercury ion.

An anonymous reader says: "KernelTrap has an interesting story about megabytes versus mebibytes. Though the article refers to Linux, the topic is applicable to all computers. Will there be a time when all computer users will talk about adding mibibytes of RAM, rather than a megabytes? From the article: '[the kernel patch] changes references from the familiar MB (megabyte) and GB (gigabyte) to the NIST standard MiB (mebibyte) and GiB (gibibyte). According to these standards, technically a megabyte (MB) is a power of ten, while a mebibyte (MiB) is a power of two, appropriate for binary machines. A megabyte is then 1,000,000 bytes. A mebibyte is the actual 1,048,576 bytes that most intend.'"

m00nshyn3 asks: "If a person were to find a O(n) solution to an NP complete problem, it would obviously be a great advance in computer science, but what are the consequences of such a discovery? Would our most popular implementations of cryptography be useless overnight? It seems like there is a lot of immediate damage that could occur if such a solution were found. So if (when) the time comes, what is the responsible way for the solution to be made public?" If you had such an algorithm in hand, what could you do with it? It would be interesting to see how many problems we could map into the NP Complete model.

chekhov writes: "Today NIST has finally announced AES (Advanced Encryption Standard) as a Federal Standard after 4 years of development. See the press release. AES is the replacement of DES and is expected to be used in financial systems and secure networks for up to 20 years. More information on the AES homepage."

chekhov writes: "Today NIST has finally announced AES (Advanced Encryption Standard) as a Federal Standard after 4 years of development. See the press release. AES is the replacement of DES and is expected to be used in financial systems and secure networks for up to 20 years. More information on the AES homepage."

*no comment* writes: "Linux has broken the barrier with the 100 petabyte ceiling, and doing it at 144 petabytes." And this is even more impressive in pebibytes, too.

More information on calls for Canadian Web regulation, the fate of the famous Israeli AI called HAL, (yes, again) Intel's continuing dance with Rambus and more, below in tonight's edition of Slashback.

It's the incredible edible, heavy-investment waffle double gainer! steevo.com writes: "Intel has decided to stay with Rambus. Say it ain't so! Details are at C-NET.

Time was when ... wilkinsm writes: "When I tuned my shortwave to 5 Mhz today, I learned that NIST (National Institute of Standards and Technology) is currently doing a open survey on the time and frequency user community. I encourage all of you unix admins that use the network time protocol to show your support and fill the online survey out."

Has the code been tossed out with the bathwater? nonAI writes: "The Israeli company, which promoted a competition against an AI, closed its gates, as reported by an Israeli economic magazine (sorry, babelfish doesn't help). That's the end for the Child Machine HAL."

Now imagine you know of a freewheeling, opinionated discussion board ... Wael Islam, a member and volunteer with IslamWay.com, writes with some words on the objections B'nai Brith Canada raised to postings on IslamWay's message boards.

"In IslamWay.com discussion board we've more than 4000 Member and at the time of the media attack there was more than 28,000 posts!! Bnai Brith didn't only take one of the posts, but even took a statement out of context to prove that IslamWay.com is a terrorist website! ...

... The discussion post was between two people who were fighting each others by words, one called the other one that you are a hypocrite, so the other one was very angry so he told him - I'm just giving the meaning- : Let's see who is the hypocrite, Come with me to Afghanistan and let's train ourselves there .. so the person meant that army exercises will be a way to prove who is the coward and who is the brave!"

The people who attacked IslamWay.com based on the Discussion Board post didn't clarify that it was mentioned in the discussion board, and they just said a post on IslamWay.com."

Of course, we could require that all public communications be approved in advance, licensed, and inoffensive.

Please resume watching your educational audio-visual materials. echoSpades writes: "I guess I wasn't the only one to be annoyed with Apple's DVD playback. Apple's website has a small text link to info about a class action suit against them: 'There is a proposed settlement of a class action lawsuit against Apple Computer, Inc. involving issues with DVD playback in earlier models of the Apple iMac DV, iMac DV SE and Power Mac G4 computers."

More information on calls for Canadian Web regulation, the fate of the famous Israeli AI called HAL, (yes, again) Intel's continuing dance with Rambus and more, below in tonight's edition of Slashback.

It's the incredible edible, heavy-investment waffle double gainer! steevo.com writes: "Intel has decided to stay with Rambus. Say it ain't so! Details are at C-NET.

Time was when ... wilkinsm writes: "When I tuned my shortwave to 5 Mhz today, I learned that NIST (National Institute of Standards and Technology) is currently doing a open survey on the time and frequency user community. I encourage all of you unix admins that use the network time protocol to show your support and fill the online survey out."

Has the code been tossed out with the bathwater? nonAI writes: "The Israeli company, which promoted a competition against an AI, closed its gates, as reported by an Israeli economic magazine (sorry, babelfish doesn't help). That's the end for the Child Machine HAL."

Now imagine you know of a freewheeling, opinionated discussion board ... Wael Islam, a member and volunteer with IslamWay.com, writes with some words on the objections B'nai Brith Canada raised to postings on IslamWay's message boards.

"In IslamWay.com discussion board we've more than 4000 Member and at the time of the media attack there was more than 28,000 posts!! Bnai Brith didn't only take one of the posts, but even took a statement out of context to prove that IslamWay.com is a terrorist website! ...

... The discussion post was between two people who were fighting each others by words, one called the other one that you are a hypocrite, so the other one was very angry so he told him - I'm just giving the meaning- : Let's see who is the hypocrite, Come with me to Afghanistan and let's train ourselves there .. so the person meant that army exercises will be a way to prove who is the coward and who is the brave!"

The people who attacked IslamWay.com based on the Discussion Board post didn't clarify that it was mentioned in the discussion board, and they just said a post on IslamWay.com."

Of course, we could require that all public communications be approved in advance, licensed, and inoffensive.

Please resume watching your educational audio-visual materials. echoSpades writes: "I guess I wasn't the only one to be annoyed with Apple's DVD playback. Apple's website has a small text link to info about a class action suit against them: 'There is a proposed settlement of a class action lawsuit against Apple Computer, Inc. involving issues with DVD playback in earlier models of the Apple iMac DV, iMac DV SE and Power Mac G4 computers."

More information on calls for Canadian Web regulation, the fate of the famous Israeli AI called HAL, (yes, again) Intel's continuing dance with Rambus and more, below in tonight's edition of Slashback.

It's the incredible edible, heavy-investment waffle double gainer! steevo.com writes: "Intel has decided to stay with Rambus. Say it ain't so! Details are at C-NET.

Time was when ... wilkinsm writes: "When I tuned my shortwave to 5 Mhz today, I learned that NIST (National Institute of Standards and Technology) is currently doing a open survey on the time and frequency user community. I encourage all of you unix admins that use the network time protocol to show your support and fill the online survey out."

Has the code been tossed out with the bathwater? nonAI writes: "The Israeli company, which promoted a competition against an AI, closed its gates, as reported by an Israeli economic magazine (sorry, babelfish doesn't help). That's the end for the Child Machine HAL."

Now imagine you know of a freewheeling, opinionated discussion board ... Wael Islam, a member and volunteer with IslamWay.com, writes with some words on the objections B'nai Brith Canada raised to postings on IslamWay's message boards.

"In IslamWay.com discussion board we've more than 4000 Member and at the time of the media attack there was more than 28,000 posts!! Bnai Brith didn't only take one of the posts, but even took a statement out of context to prove that IslamWay.com is a terrorist website! ...

... The discussion post was between two people who were fighting each others by words, one called the other one that you are a hypocrite, so the other one was very angry so he told him - I'm just giving the meaning- : Let's see who is the hypocrite, Come with me to Afghanistan and let's train ourselves there .. so the person meant that army exercises will be a way to prove who is the coward and who is the brave!"

The people who attacked IslamWay.com based on the Discussion Board post didn't clarify that it was mentioned in the discussion board, and they just said a post on IslamWay.com."

Of course, we could require that all public communications be approved in advance, licensed, and inoffensive.

Please resume watching your educational audio-visual materials. echoSpades writes: "I guess I wasn't the only one to be annoyed with Apple's DVD playback. Apple's website has a small text link to info about a class action suit against them: 'There is a proposed settlement of a class action lawsuit against Apple Computer, Inc. involving issues with DVD playback in earlier models of the Apple iMac DV, iMac DV SE and Power Mac G4 computers."

Several people wrote with news that NIST has released a draft standard for the AES. They're inviting public comment, so if the NSA has added a backdoor to Rijndael, now would be a good time to find it.... :)

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

An Anonymous Coward writes: "The National Institute of Standards and Technology (NIST) has just released a series of cryptographic hash functions (SHA-256, SHA-384, SHA-512) to work with the new Advanced Encryption Standard. Of course, they must be secure since they're designed by our good friends at the NSA."

-is writes: "NetBSD-current IPsec (from KAME) now supports the rijndael algorithm for ESP encryption, thanks to the integration work of Jun-ichiro itojun Hagino. rijndael is the finalist of AES contest, and will be standardized in the FIPS standard suite, to replace DES. The implementation is known to be interoperable with others. Also, it is possible to negotiate rijndael IPsec SA by using the latest racoon IKE daemon (pkgsrc/security/racoon, be sure to get version 20001004a).

For more info see:

• http://www.nist.gov/aes/ (the algorithm itself)
• http://www.kame.net/ (KAME project where NetBSD IPsec comes from)
• http://www.netbsd.org/Documentation/network/ipsec/ (NetBSD IPsec FAQ)

• The change is now on the 1.5 branch, and will be available in the 1.5 release."

^BR writes "Rijndael the Belgian algorithm candidate to being AES won the competition. It has just been announced by NIST. The scoop. Too bad for Twofish and Serpent." More info should appear at the NIST AES website soon.

^BR writes "Rijndael the Belgian algorithm candidate to being AES won the competition. It has just been announced by NIST. The scoop. Too bad for Twofish and Serpent." More info should appear at the NIST AES website soon.

^BR writes "Rijndael the Belgian algorithm candidate to being AES won the competition. It has just been announced by NIST. The scoop. Too bad for Twofish and Serpent." More info should appear at the NIST AES website soon.

Anonymous Coward writes: "The National Institute of Standards and Technology (NIST) will announce the winner of the Advanced Encryption Standard competition on Oct. 2 at 11:00 am (Eastern Standard Time). This algorithm is going to be the new government standard, so it's worth checking the page out. Following the announcement a report on the AES development efforts will be released on the NIST AES webpage. The NIST Advanced Encryption Standard page can be found at http://www.nist.gov/aes."

From a hundred feet up, the action on the floor at FOSE would look like that of any technical tradeshow. Eager vendors try to get their names into the heads of buyers, and the aisles are jammed with swag-toting prospects. The show floor has plenty of the power suits and eager vendors that any other shows do, but also more than a scattering of military insignia, camouflage and Marine crew cuts. And for the first time, just a quick stroll from the 50,000 square foot Microsoft display, this year's FOSE floor also featured Linux vendors and a dedicated Linux pavilion. (Read more.)

Why FOSE matters

Linux at computer trade shows is nothing new -- but this show in particular targets no one outside the largest buyer of computers and software in the entire world, bar none: the Feds. The Federal government spends upward of 35 billion dollars each year on computer systems and software; how much more depends on who you ask.

"If you ask Federal sources, they pin it around 38 billion dollars, and that's become an accepted number -- that includes telecommunications buying. One of the reasons that the estimates are so diverse is that the government doesn't count things the way businesses do," says FOSE consultant Peg Hosky. Remember, that estimate too is conservative: trying to calculate the depths of the black budgets which drive some of the largest and most secretive IT purchases, not to mention contingency spending hidden in euphemized line items, is a black art.

The Departments of Defense, Energy, the Interior, Transportation, the Federal Aviation agency (and all the other agenices associated with the every Federal department) --- the list stretches from the White House to the most distant exploratory spacecraft.

The goods on offer at FOSE, though, are for the most part more mundane. Though the show is now simply called by its acronym, the initials stood for Federal Office Systems Exposition: you won't find radar systems or flight control computers on offer at the show. But for anything related to desktop computing, "FOSE's always been the introduction point of new technologies to the Federal government, because the government leaders and the national press focuses on this show," said Hosky.

Getting penguins in the door

The main-floor pavillion was the brainchild of Northern Virginia LUG (NoVaLUG) member Tim Bogart, by day a network server administrator for a major telecommunications company, and furthered by Lois Rude, industry manager with FOSE. After a Washington-area Linux exposition was cancelled nearly a year ago, Bogart asked himself and fellow LUG members "Why don't we get in on the real action?"

He began angling at a more ambitious target than the Linux enthusiasts who populate LUGs and Linux-only conventions. A previous job had put Bogart into the realm of Federal purchasing as the manager of a 20-million dollar IT project, and he knew how complicated government purchasing was. "My background isn't as a coder -- I'm an electrical engineer by training. I thought this was a way I could contribute to the community," he said. "You have no idea how complicated it gets."

Going from interested user to organizer put Bogart into contact with a receptive FOSE executive, and that made all the difference. "[Bogart] called on the sales people, and the salesperson didn't understand what he was asking for, so they gave him to me," says Rude. "I was new with FOSE at the time. We talked, we had lunch together and the more we talked, the more we realized it would be mutually beneficial to have all of them do something within FOSE."

Billy Ball, Linux book author and fellow NoVaLUG member, helped spearhead the effort too. "Bill and Tim came in and gave our sales team an amazing demonstration with Linux, and really educated us about it," says Rude.

Abstract goals like education are fine -- and to that end, volunteers from several local LUGs donated time in the pavillion answering questions of every level -- but the organizers also have a more pragmatic reason to make Linux more visible to Federal buyers: "I would like nothing more than to reach my hand down into Bill Gates' pocket and pull out $11-18 billion in accounts receivable," says Bogart.

To that end, he and the other volunteers solicited donations of software and information from Linux vendors, and cajoled others to actually show up at the show. Applix and Caldera occupied booths flanking the pavilion, but as you'll read they were far from the only vendors present.

The problem with "free" The biggest obstacles to getting Linux onto Federal desktops currently running Microsoft operating system is not just perception -- hardware vendors industry wide are touting their Linux compatibility, and mainstream magazines have featured Linux on their covers -- but the inertia which characterizes federal sales even more than it does the private sector.

High-performance computing centers like Sandia National Laboratory and Los Alamos aside, the problem is the desktop. Open-source software, Linux or not, tends to advance more rapidly and with less oversight than government purchasers are comfortable with.

Col. Stephen Quick, who specializes in training and retention for the U.S. Air Force, put it this way: "We've got a force of about 75,000 Air Force personnel who we've got to train to sustain that [desktop software investment]. Of course, our user community is all of the Air Force, about 550,000 people. So you've got to make sure you've got standardization, configuration control in whatever you do." The other armed forces face similar constraints -- workforces that shift at the drop of an order, and a work force made up of people enlisted for just a few years.

"We use a lot of UNIX in the command and control centers, but we use NT for the desktop," says Quick. With open-source software, "you could well have somebody developing a little application that they become dependent on. The person who develops it leaves, somebody else moves in who's never seen it before. If that's your expert, and they're now over in Saudi, you're kind of out of luck."

Citing manpower restraints for support as well as development, many vendors said their products would remain Microsoft-centric for the foreseeable future. "In my 20-person shop," said one biometric device manufacturer's rep who asked not to be identified, "we're doing everything we can to get even one client version out the door. We don't rule out porting to other platforms, but frankly we have to go where the market is. After NT, we're working on Novell, because that has the second largest installed base among our customers. Other clients have to wait."

Hits and misses

This may be the first year for a Linux pavilion, but Linux also showed up at the fair in unexpected corners: Apple, for instance.

While work on the BSD-based OS X is moving along, no machines at FOSE were demonstrating the new OS. However, under a sign proclaiming High Performance Computing, developer Kai Staat of Terra Soft Solutions happily demonstrated Yellow Dog Linux 1.2 on a Macintosh G4. With a few keystrokes, he switched from a KDE desktop to the usual Mac desktop -- or rather, to Mac On Linux, in a KDE window. "To the Mac OS, it's as if you just pushed the power key on the keyboard," he explained to some onlookers from the Air Force, showing them that both systems were happily coexisting on the machine.

After one of these demonstrations, NIST robotics researcher David Gilsinn told me "My scientific work, it's on UNIX, so I have to either run X, or go sit at a UNIX box to do it, so that [Linux on G4] looked like a really good option." Gilsinn said that his workplace is currently Sun based, but that "we're trying to cut down the cost of our systems, especially Unix systems, and Linux is getting to be a viable option."

Corel's large exhibit showed off, in addition to their Windows products, both Corel Linux and the company's office suite. And API, who manufacture the Alpha processor, were also out in force. I spoke with Michael Foley, API technical marketing engineer, about what Linux meant to their product. And despite the availability of BSD Unix, Foley said, "With NT no longer on the Alpha platform, I think [Linux] offers the best possibilities. The BSD Unix is a great Unix, but it doesn't have the push behind it that Linux does today. And the Digital Unix, True64 -- that's owned by Compaq, and it doesn't have the popularity [of Linux]."

Linux also shows up in many products which don't tout the OS unless prompted: it serves as the embedded OS driving Watchguard's firewall and VPN devices, and Linux on x86 serves as the platform for Trend Micro's AntiVirus software, which patrols for virii stalking more vulnerable desktop OSes. And a small company with the inscrutable name of Applied Business Services is quietly reselling and customizing open-source accounting software which runs on both Linux and Windows to both government and private buyers.

From the impressed looks on visitors to the Corel Office 2000 Linux kiosk, not to mention those on everyone who stopped to examine the tiny embedded-Linux Web server on display at the Linux pavillion, the interest in Linux products seemed palpable.

A Wednesday-afternoon panel hosted by Ball and featuring some of the biggest names in commercializing open source software, though, drew only sparse attendance and seemed aimed at a less Linux-saavy audience which didn't materialize -- perhaps because it intersected the 4 p.m. end of the Expo day.

Chris DiBona of VA Linux and Red Hat's Bob Young joined SGI VP of marketing for servers and high-end graphics Jan Silverman and Rene Schmidt of Corel's Linux division.

Unsurprisingly, and despite a few friendly jabs at each other and at mutual rival Sun Microystems, the four mostly agreed with each other: Linux is stable, extensible and high-quality. No brass from the big agencies showed up for their presentation, though, which reflects the tenor of many of the buyers at the show.

"We're an NT shop and we're going to stay that way for the foreseeable future. I don't see us moving from that to Linux or any non-Microsoft OS," said one Social Security official.

Whether those words get eaten remains to be seen, but both Bogart and Rude are upbeat about next year. "Next year, mark my words, they'll have to cross names off the list [of Linux exhibitors]," says Bogart.

Most of the questions we got for crypto guru Bruce Schneier earlier this week were pretty deep, and so are his answers. But even if you're not a crypto expert, you'll find them easy to understand, and many of Bruce's thoughts (especially on privacy and the increasing lack thereof) make interesting reading even for those of you who have no interest in crypto because you believe you have "nothing to hide." This is a *long and strong* Q&A session. Click Below to read it all.

First Bruce says, by way of introduction...

"I'd like to start by thanking people for sending in questions. I enjoyed answering all of them.

"I've written on many of these topics before, and often I will point to existing writings on my Web site or in my Crypto-Gram newsletter. This isn't to be annoying; it just seems useful to point to things I have already written. I urge anyone interested to sign up for a free subscription to Crypto-Gram. I write it monthly, and I regularly answer questions such as these, or write about topics in the news (especially ones that have been reported on badly). To subscribe, visit my Web site at www.counterpane.com/."

ryanr asks:
I've heard you say many times that unless a particular crypto alg. has undergone lots of public review, it should not be considered safe. Unless possibly it's from the NSA. (Excluding, of course, the NSA stuff that is INTENTIONALLY backdoored.)

The implication there is that the NSA has applied some many resources to the crypto problems, that they are as good as the rest of the cryptographers put together.

My question is: Do you really think that a private process, no matter how many resources applied, can equal the public process?

ANSWER:
Yes. One way of looking at a public process is as a large and distributed private process. If the NSA collected all of the academic cryptographers, gave them a clearance, and locked them in a basement somewhere, it would become a private process. The real issue is whether or not the NSA has equivalent expertise to the public academic community, and whether it can apply that expertise in an effective manner.

The NSA has a lot more cryptographic experience in the narrow fields of making and breaking algorithms. They have been doing this, and nothing else, for decades. I don't believe that they have much expertise in weird digital signature schemes, or zero-knowledge protocols, or even more bizarre electronic commerce and voting schemes, because they aren't really of practical interest. But the NSA certainly has a very strong practical interest in algorithm design and analysis, to a much greater degree than we in the public community do. And they have seen a lot more ciphers: both designs that they have proposed internally and designs in production systems that they have tried to attack.

The NSA also has the ability to target its analysis resources. The public academic community is scattershot. We work on what interests us, and we are each interested by different things. A director at the NSA has the ability to take the top ten cryptanalysts in the building and say: "You. Go into that room and don't come out until you've broken RC4. I don't care if it takes two years." That ability to direct resources at particular problems gives them an edge that we don't have.

But how much of an edge? Until recently, I would have stated unquestionably that the NSA is a decade ahead of the state of the art in cipher design and analysis. Now, I'm not so sure.

Over the past five years, there has been a lot of open research in cryptography. We have discovered many different types of attacks, and have learned a lot about how to design ciphers. The best and brightest of the cryptographers are staying in the open academic community, and are not being swallowed up by the NSA (or by its counterparts in other countries). There is a vibrant academic community in cryptography; people can exchange ideas, share research, build on each other's work. We've seen attacks against the NSA-designed algorithm Skipjack that almost certainly were not known by the NSA. (See http://www.counterpane.com/crypto-gram-9807.html#skip for Skipjack information, and http://www.counterpane.com/crypto-gram-9809.html#impossible for information on impossible-differential cryptanalysis.) We've seen other attacks that, I believe, were not known by the NSA. (See http://www.counterpane.com/mod3.html for more information.) The public research community is now doing cutting-edge research in cryptography.

Now this doesn't mean we are better than they are. Certainly the NSA knows more about cryptography than the public community does. They read everything we publish, and we read nothing that they publish. Almost by definition, they know what we do. That imbalance alone will always give them an edge in knowledge. But I think that edge is closing rapidly.

And on a related topic, I don't think the recent press flap about the NSAKEY means that the NSA has a backdoor in Microsoft Windows. I wrote about this in HREF="http://www.counterpane.com/crypto-gram-9909.html#NSAKeyinMicrosoftCryptoAPI. But I do think that the NSA deliberately puts back doors in products; seehttp://www.counterpane.com/crypto-gram-9902.html#backdoors for some details.

Sajma asks:
Your book describes a slew of interesting applications for crypto protocols, including electronic money orders, digital time-stamping, and secure multi-party computation. What are the remaining crypto problems of interest to the general public which have not been solved? (secure distribution of digital media comes to mind -- can you sell someone a music file, allow them to use the file anywhere, but make sure no one else can use it?)

- SEE NEXT QUESTION -

randombit asks:
OK, hypothetical question. You rub a magic lamp, and a genie comes out. Specifically, a cryptographic protocol genie. He can come up with an efficient, secure protocol for any activity you want (assuming a protocol is possible, of course). What would you pick, and more importantly, why?

ANSWER:
Two questions; one answer. We actually have all the protocols we need. It's true that I described all sorts of interesting protocols in _Applied Cryptography_. The reality is that none of them is actually useful. What is useful are the few simple primitives -- signatures, encryption, authentication -- and the different ways to mirror real-life trust models using them. These protocols are simpler, easier to understand, and more useful.

The real problem with protocols, and the thing that is the hardest to deal with, is all the non-cryptographic dressing around the core protocols. This is where the real insecurities lie. Security's worst enemy is complexity.

This might seem an odd statement, especially in the light of the many simple systems that exhibit critical security failures. It is true nonetheless. Simple failures are simple to avoid, and often simple to fix. The problem in these cases is not a lack of knowledge of how to do it right, but a refusal (or inability) to apply this knowledge. Complexity, however, is a different beast; we do not really know how to handle it. Complex systems exhibit more failures as well as more complex failures. These failures are harder to fix because the systems are more complex, and before you know it the system has become unmanageable.

Designing any software system is always a matter of weighing and reconciling different requirements: functionality, efficiency, political acceptability, security, backward compatibility, deadlines, flexibility, ease of use, and many more. The unspoken requirement is often simplicity. If the system gets too complex, it becomes too difficult and too expensive to make and maintain. Because fulfilling more of the other requirements usually involves a more complex design, many systems end up with a design that is as complex as the designers and implementers can reasonably handle. (Other systems end up with a design that is too complex to handle, and the project fails accordingly.)

Virtually all software is developed using a try-and-fix methodology. Small pieces are implemented, tested, fixed, and tested again. Several of these small pieces are combined into a larger module, and this module is tested, fixed, and tested again. The end result is software that more or less functions as expected, although we are all familiar with the high frequency of functional failures of software systems.

This process of making fairly complex systems and implementing them with a try-and-fix methodology has a devastating effect on security. The central reason is that you cannot easily test for security; security is not a functional aspect of the system. Therefore, security bugs are not detected and fixed during the development process in the same way that functional bugs are. Suppose a reasonable-sized program is developed without any testing at all during development and quality control. We feel confident in stating that the result will be a completely useless program; most likely it will not perform any of the desired functions correctly. Yet this is exactly what we get from the try-and-fix methodology with respect to security.

The only reasonable way to "test" the security of a system is to perform security reviews on it. A security review is a manual process; it is very expensive in terms of time and effort. And just as functional testing cannot prove the absence of bugs, a security review cannot show that the product is in fact secure. The more complex the system is, the harder a security evaluation becomes. A more complex system will have more security-related errors in the specification, design, and implementation. We claim that the number of errors and difficulty of the evaluation are not linear functions of the complexity, but in fact grow much faster.

For the sake of simplicity, let us assume the system has n different options, each with two possible choices. Then, there are about n^2 different pairs of options that could interact in unexpected ways, and 2^n different configurations altogether. Each possible interaction can lead to a security weakness, and the number of possible complex interactions that involve several options is huge. We therefore expect that the number of actual security weaknesses grows very rapidly with increasing complexity.

The increased number of possible interactions creates more work during the security evaluation. For a system with a moderate number of options, checking all the two-option interactions becomes a huge amount of work. Checking every possible configuration is effectively impossible. Thus the difficulty of performing security evaluations also grows very rapidly with increasing complexity. The combination of additional (potential) weaknesses and a more difficult security analysis unavoidably results in insecure systems.

In actual systems, the situation is not quite so bad; there are often options that are "orthogonal" in that they have no relation or interaction with each other. This occurs, for example, if the options are on different layers in the communication system, and the layers are separated by a well-defined interface that does not "show" the options on either side. For this very reason, such a separation of a system into relatively independent modules with clearly defined interfaces is a hallmark of good design. Good modularization can dramatically reduce the effective complexity of a system without the need to eliminate important features. Options within a single module can of course still have interactions that need to be analyzed, so the number of options per module should be minimized. Modularization works well when used properly, but most actual systems still include cross-dependencies where options in different modules do affect each other.

A more complex system loses on all fronts. It contains more weaknesses to start with, it is much harder to analyze, and it is much harder to implement without introducing security-critical errors in the implementation.

This increase in the number of security weaknesses interacts destructively with the weakest-link property of security: the security of the overall system is limited by the security of its weakest link. Any single weakness can destroy the security of the entire system.

Complexity not only makes it virtually impossible to create a secure system, it also makes the system extremely hard to manage. The people running the actual system typically do not have a thorough understanding of the system and the security issues involved. Configuration options should therefore be kept to a minimum, and the options should provide a very simple model to the user. Complex combinations of options are very likely to be configured erroneously, resulting in a loss of security. There are many stories throughout history that illustrate how management of complex systems is often the weakest link.

I repeat: security's worst enemy is complexity. The most serious protocol problem is how to deal with complex protocols (or how to strip them down to the bone).

Get Behind the Mule asks:
Bruce, thanks very much for making cryptography so much more accessible to us all.

You wrote in Applied Cryptography that IDEA was your "favorite" symmetric cipher at the time. Is that still true today?

ANSWER:
It depends what you mean by "favorite." If I needed a secure symmetric algorithm for a design, and performance were not an issue, I would choose triple-DES. No other algorithm has been as well-studied, so nothing can compare in confidence.

The problem is that triple-DES is slow; on a 32-bit microprocessor it encrypts data at a rate of 108 clock cycles per byte. (You have to remember that DES was designed in the mid-1970s for discrete hardware. It is very slow on 32-bit microprocessors.) If I need a faster algorithm, I would use Blowfish. Blowfish encrypts data at a rate of 18 clock cycles per byte. Information on Blowfish is at http://www.counterpane.com/blowfish.html.

Neither is my favorite algorithm. Currently, my favorite algorithm is Twofish. Twofish is our submission to AES. It is still too new to use operationally, but I hope it will see wide use as people analyze it and as confidence grows in its security. Information on Twofish is at http://www.counterpane.com/twofish.html. It's even faster than Blowfish, and (I think) much better designed.

Faster algorithms are more problematic. I don't really like RC4. SEAL is better, but patented by IBM. I don't care for WAKE. I would probably use one of Belgian cryptographer Joan Daemen's designs.

I don't recommend IDEA anymore for several reasons. One, it isn't very fast; on a 32-bit microprocessor it encrypts data at a rate of 50 clock cycles per byte. Two, IDEA is patented, and the terms change regularly. Also, attacks against IDEA have steadily eaten away at the security margin. IDEA has eight rounds, and the current best attack breaks 4.5 rounds. There are still no attacks against the full eight-round cipher, and there is no reason to believe that any are possible. Still, since there are algorithms with much better performance, it seems improper to suggest IDEA.

Speed comparisons of other algorithms can be found at http://www.counterpane.com/speed.html. A detailed paper comparing performance of the AES candidates can be downloaded at http://www.counterpane.com/aes-performance.html. And for a current summary of attacks against various algorithms, see http://www.ii.uib.no/~larsr/bc.html.

Remember, though -- breaking the cryptographic algorithm is almost never the way to attack a security product. There is almost always an easier way to break the security. I've written about this extensively; see http://www.counterpane.com/whycrypto.html and http://www.counterpane.com/pitfalls.html in particular.

Tet asks:
Scott McNealy claims we've already fought and lost the war for personal privacy. Do you agree with him or not, and why?

ANSWER:
One hundred years ago, everyone could have personal privacy. You and a friend could walk into an empty field, look around to see that no one else was nearby, and have a level of privacy that has forever been lost to today's technology. The framers of the Constitution never explicitly put a right to privacy into the document; it never occurred to them that it could be withheld. The ability to have a private conversation, like the ability to keep your thoughts in your head and the ability to fall to the ground when pushed, was a natural consequence of the world. When the Supreme Court found a right to privacy in the Constitution, it's because the language of the Constitution assumed its existence.

Technology has demolished that worldview. Powerful directional microphones can pick up conversations hundreds of yards away. Pinhole cameras -- now being sold over the Internet -- can hide in the smallest cracks; satellite cameras can read the time on your watch from orbit. And the Defense Department is prototyping micro-air vehicles, the size of small birds or butterflies, that can scout out enemy snipers, locate hostages in occupied buildings, or spy on just about anybody.

In the aftermath of the terrorist takeover of the Japanese embassy in Peru, news reports described audio bugs being hidden in shirt buttons that allowed police to pinpoint everyone's location. Van Eck devices can read what's on your computer monitor from halfway down the street. (I heard that the CIA demonstrated this for Scott McNealy at Sun; they captured his password from a van in the company's parking lot.) Lasers bounced off windows can reveal the Doppler effect of compression and rarefaction of air by soundwaves, and eavesdrop on conversations happening on the other side. If an attacker can plug into your power line, it can read it from even further away. Purchase anything lately? Unless you use cash, what, where, and when is recorded in a database. And in many stores, a security camera has recorded your presence while the helpful sales clerk captures your name and personal information.

The ability to trail someone remotely has existed for a while, but it is only used in exceptional circumstances. In 1993, Colombian drug lord Pablo Escobar was found partly by tracking him through his cellular phone usage. Timothy McVeigh's truck was found because the FBI collected the tapes from every surveillance camera in the city, correlated them by time (presumably the explosion acted as a great synch pulse), and looked for it. During Desert Storm the U.S. dropped thousands of miniature robots -- millimeters in diameter -- on Iraq that looked for signs of biological warfare.

The technology to automatically search for drug negotiations in random telephone conversations, for suspicious behavior in satellite images, or for faces on a "wanted list" of criminals in on-street cameras isn't here yet, but it's just a matter of time. Face-recognition software can pick individual faces out of a crowd. Voice recognition will soon be able to scan millions of telephone calls, listening for a particular person; it can already scan for suspicious words or phrases. Moore's Law, which says the industry can double the computing power of a microchip every 18 months, affects surveillance computing just as it does everything else: the next generation will be smaller, faster, and a lot cheaper. As soon as the recognition technologies can find the people, the computers will be able to do the searching automatically.

At the same time, the fear of crime is facilitating a great deal of surveillance, not all of it instigated by the police. Some U.S. airports automatically record the license plates of anyone coming onto airport property, even if it is just to pick up someone. Some cities are installing directional microphones to pinpoint gunfire; others are setting video cameras on lampposts to deter crime. It's getting difficult to walk into a store without being videotaped. Timothy McVeigh couldn't drive a truck through downtown Oklahoma City without it showing up on an in-store surveillance camera, and these cameras were positioned to protect the store, not to track goings-on outside the windows.

The U.S. is initiating a program called "computer-assisted passenger screening," or CAPS. The idea is to match commercial air travelers against profiles of evildoers, using such items as the traveler's address, credit card number, destination, whether or not he is traveling alone, whether the ticket was paid in cash, when the ticket was purchased, whether it was one-way or round trip, and about three dozen other factors that are being kept secret. Needless to say, groups like the ACLU have objected to stopping and searching people based on stereotypes. Not to mention that the data is saved, just in case the government needs to peek into people's pasts. No warrant required, of course.

More is coming. Out of concern for public safety, the FCC has ruled that by 2001, cellular and PCS companies must be able to locate users who dial 911 to within a radius of 125 meters. Consumers will foot this bill through a user tax, and you can be sure that wireless operators will introduce a plethora of other services based on this technology. The companies are probably going to use the cellular technology to locate people, although if they can wait a couple of technological generations they can drop miniature GPS receivers in the phones and do even better. One way or another, people will end up carrying technology that allows them to be digitally tailed. And currently, no warrant is required.

The surveillance infrastructure is being installed in our country under the guise of "customer service." Some hotels track guest preferences in international databases, so that customers will feel at home even if it is their first stay in a particular city. Caterpillar Corporation is installing diagnostic chips into all new farm machinery. These chips alert the local dealer, via satellite, when a part is failing. The dealer can then drive to the farm with a replacement, often before the machine has even broken down. This is great; I'll bet farmers really like the prompt service and the reduction in downtime. But the same technology can be used for other, less benign, purposes.

Automobile surveillance is almost automatic. Rental cars, equipped with GPS navigational systems, can keep a complete record of exactly where that car has been. Mercedes Benz is planning on embedding a Web server into its cars, so that technicians can spot service problems remotely. At least two companies plan on marketing a smart car locator that uses a GPS receiver and a cellular phone to alert the authorities to your whereabouts in case of an emergency. It only takes a slight modification to allow the locator to work automatically when queried by the police. Lojack, the device that can track your car if it has been stolen, can also be used for surveillance. Will net-connected smart cars give police the ability to track everybody in the country simultaneously? Already systems like Lojack do this, as do car phones.

GPS is a dream technology for surveillance. One company is selling an automatic warehouse inventory system, using GPS and affixable transmitters on objects. The transmitters broadcast their location, and a central computer keeps track of where everything is. Spies have probably been able to use this kind of stuff for years, but it's now becoming a consumer item.

Individual privacy is being eroded from a variety of directions. Most of the time the erosions are small, and no one kicks up a fuss. But there is less and less privacy available, and most people are completely oblivious of it. It is very likely that we will soon be living in a world where there is no expectation of privacy, anywhere or at any time.

rise asks:
As one of the stronger voices behind the proposition that only peer reviewed, open, and thoroughly tested algorithms can be trusted you've widely disseminated several algorithms, Solitaire and Yarrow among them. What attacks or interesting analyses have surfaced since their release?

ANSWER:
For those who want to know what he is asking about, you can read about Solitaire at http://www.counterpane.com/solitaire.html, and about Yarrow at http://www.counterpane.com/yarrow.html. And you can read about my position on the importance of using a public, peer-reviewed algorithm at http://www.counterpane.com/crypto-gram-9904.html#different, my snide comments about proprietary cryptography at http://www.counterpane.com/crypto-gram-9902.html, and my dismissing of cracking contests at http://www.counterpane.com/crypto-gram-9812.html#contests.

There has been some excellent analysis of Solitaire by Paul Crowley. He has posted his results to the sci.crypt newsgroup, and you can look them up. Briefly, he found a bug in the code and a problem with the algorithm. I will fix the bug in the code as soon as I get around to it, but the problem with the algorithm is more disturbing. We hope to write a joint paper documenting the problem, and proposing a fix.

I don't think it is a problem operationally, though. Solitaire is a pencil-and-paper cipher designed for very short messages, and the attack will require a lot of ciphertext. Still, it is a problem and one that I should fix.

As to Yarrow, I don't know any outside cryptanalysis. I'd like to see some.

Thagg asks:
I bought your first edition of Applied Cryptography, and you say two things that bother me, with respect to your submission of Twofish as a Federal standard for encryption.

In the forward, you describe how you got interested in cryptography, and that you had no background or training in the field, but you thought it was interesting. Also, several times throughout the book you caution people not to trust cryptosystems from amateurs.

Clearly you have become well versed in the history and application of cryptography, your book makes all other descriptions of the state of the art invisible by comparison. Still, it appears to me that cryptosystem design and analysis requires fairly extreme mathematical proficiency, which I do not believe that you have.

Now, of course, Twofish is published in detail, and the best people in the world have attempted to crack it (and I think that the competitive process that the US Gov't has promoted is a spectacular way to get the best people to attack each other's ciphers). But, I remain somewhat worried that at the foundations of Twofish...is there something missing that a PhD in mathematics and number theory would have seen?

The winner of this competition will likely be the next DES, and will provide security for a fairly large percentage of the planet. The stakes are high. I'm sure that you have an answer to this criticism, and I'm eager to hear it.

ANSWER:
Certainly you should not trust cryptographic algorithms designed by people who have no experience designing and analyzing cryptographic algorithms. The question you ask is different. You are asking if a Ph.D. in mathematics and number theory gives someone any special insights that someone without the Ph.D. would miss. I believe that cryptographic experience is something that is learned through both training and through experience, and that someone with a Ph.D. is not automatically a better cryptographer.

Cryptography is interesting, because there are no absolute metrics. Anyone can design an algorithm that he himself cannot break. This means that anyone, from the best cryptographer to the sorriest man on the street, can design a cryptographic algorithm that works: that encrypts and decrypts data properly, and that the designer cannot break. The false reasoning that often follows is this: "I can't break it, therefore it is secure." The first question that anyone else should ask is: "You say you can't break it; well, who the hell are you?" More on this topic can be found at http://www.counterpane.com/crypto-gram-9810.html#cipherdesign.

The experience of the designers is something that I look at very carefully when I evaluate an algorithm. I can't devote the months and years necessary to convince myself that an algorithm is secure, so I want to know about the people who are convinced. And I don't look at their academic degrees; I look at what else they have broken.

The Twofish team has dozens of published cryptanalytic attacks, breaking all kinds of ciphers. (A list of Counterpane papers can be found at http://www.counterpane.com/publish.html, and David Wagner's published papers can be found at http://www.cs.berkeley.edu/~daw/.) These are impressive results: mod n cryptanalysis, boomerang attacks, slide attacks, side-channel cryptanalysis, related-key differential cryptanalysis, and attacks against Skipjack, Speed, Akelarre, RC5a, CMEA, ORYX, TwoPrime, etc., etc., etc. Interestingly enough, all five AES finalists have been designed by teams that have a similarly impressive list of published cryptanalytic attack. With a couple of exceptions, none of the non-finalists have any cryptanalysts on their teams.

Another thing to look at is the quality of the designer's analysis. I like designs that have long and detailed documents that discuss how the designers have attacked their own design. You can see this in the submissions for Twofish, and for Mars, RC6, and E2. I worry about a cipher like Serpent that does not come with any analysis. Either the designers didn't do any, which is bad -- or they did it and are hiding it, which is worse.

I think these things speak more to the strength of the design than academic degrees.

In fact, I have seen many systems designed by Ph.D. mathematicians with little cryptographic experience, that have been quickly broken. Experience in cryptography is much more important than experience in general mathematics.

It is certainly possible that there are attacks against an algorithm that the designers missed. This is why AES is a public process. Before AES is chosen, dozens of people with Ph.D.s in mathematics will be performing their own analyses on the submissions. If Twofish is chosen, it will because none of those Ph.D.s have found any weaknesses.

But if you want Ph.D.s on the Twofish team, co-designer Doug Whiting has a Ph.D. in computer science from CalTech. His dissertation was on building Reed-Solomon error-correcting codes in VLSI, so it had a heavy math content.

Enoch Root asks:
It was noted in your biography that you hold a degree in Physics in addition to your M.S. in Computer Science. This seems to be a developing trend in IT, as many Physics graduates turn to CS. Neal Stephenson undertook studies in Physics before becoming a writer. I am myself a physics graduate turned computer geek.

What impact do you think your science studies have on your current career? I suspect the high mathematical background of physics prepared you for cryptology, but what other aspects of a science degree come into play in your line of work? Would you call your B.S. in Physics an advantage or a disadvantage?

ANSWER:
The unfortunate answer is that it wasn't very relevant. It was neither an advantage nor a disadvantage, although it was harder to get a job out of college with a physics degree. Physics teaches mathematics, and that was helpful.

If you want to become a cryptographer, study mathematics and computer science. I wrote an essay on this very topic; see http://www.counterpane.com/crypto-gram-9910.html#SoYouWanttobeaCryptographer.

Hobbex asks:
One would think that cryptographers, who study the mathematical means for controlling information (not just secrecy, but also signatures, zero knowledge proofs etc) would be the least inclined to support the artificial limits to information set up by our legal system, and yet the field is littered with patents (probably more so than any other field of mathematics).

You, on the other hand, have been very generous with your algorithms and cryptos. Is there a political, ideological, or practical reason behind this?

ANSWER:
It is impossible to make money selling a cryptographic algorithm. It's difficult, but not impossible, to make money selling a cryptographic protocol.

Look at algorithms first. There are free encryption algorithms all over the place: triple-DES, Blowfish, CAST, most of the AES submissions. Look again at the URLs attached to question 6. It makes sense for a designer to use one of these public algorithms. If I patented Blowfish, no one would have used it. No one would have analyzed it. (Why would they do work for free, if I were making money off of it?) Only because Blowfish is free is it in over 100 products. (For a list, see A HREF="http://www.counterpane.com/products.html">http://www.counterpane.com/products.html.) If I patented it and charged for it, it would be much less widely used. IDEA is a good example of this. IDEA could have been everywhere; for a while it was the only trusted DES replacement. But it was patented, and there were licensing rules. As a result, IDEA is barely anywhere. SEAL is a great-looking stream cipher. But because IBM has a patent on it, no one uses it.

The early public-key patents are the only exception to this. Because the patents controlled the concept of public-key cryptography, there was no way to do public-key encryption, key exchange, or digital signatures without licensing the patents. This exception is over; the Diffie-Hellman patents have expired.

Regularly I hear from algorithm inventors who want to patent their new cool algorithm and then sell it. This business plan has absolutely zero percent chance of succeeding. I recommend that people give their cryptography away, and use the PR benefit to make a living. If the IDEA patent holders did that, they would be much better off.

Protocols are a little bit different. You can patent a protocol and turn it into a useful business. It's hard; most of the time a competitor can engineer around a protocol patent. But it is possible, and many companies are making a go at marketing patents in authentication, certificate revocation, digital content protection, etc. I'm not thrilled by this, but it's the reality of American business today.

aheitner asks:
As many know, your Twofish algorithm is one of the (many) submissions to become the AES standard. The goal for these algorithms is to be able to implement them extremely cheaply in hardware -- say on a 6800 with 256 bytes of RAM. In other words, cheaply enough to put on a smart card.

But IBM's team alleges that any algorithm that simple can be fairly easily cracked by doing a power usage analysis on the chip (by watching fluctuations in the electrical contacts with the reader) and that the necessary equipment to protect against power analysis would be equivalent to a much more complex processor -- so much so you might as well just implement a different and more complex (and hopefully power-random) algorithm. Of course IBM suggests their own implementation.

What do you think? Is there a way to build a simple smart card so that power analysis isn't a problem? Perhaps the whole question will become irrelevant since we'll be carrying around so much processing power in our PDAs that we'll just use them?

ANSWER:
Power analysis involves breaking a cryptographic algorithm by looking at the power trace from a chip executing that algorithm. This is a specific case of what I call "side-channel attacks." I wrote about side-channel attacks at http://www.counterpane.com/crypto-gram-9806.html#side, and some excellent information on power analysis can be found at http://www.cryptography.com/dpa/index.html.

I don't believe it is possible to create a cryptographic algorithm that, because of its mathematics, is immune from side-channel attacks.

Any cryptographic primitive, such as a block cipher or a digital signature algorithm, can be thought of in two very different ways. It can be viewed as a mathematical object; typically, a function taking an n-bit input and producing an m-bit output. Alternatively, it can be viewed as a concrete implementation of that mathematical object. Traditionally, cryptanalysis has been directed solely against the mathematical object, and the resultant attacks necessarily apply to any concrete implementation. The statistical attacks against block ciphers -- differential and linear cryptanalysis -- are example of this; these attacks will work against DES regardless of which implementation of DES is being attacked.

In the last few years, new kinds of cryptanalytic attacks have begun to appear in the literature: attacks that target specific implementation details. Both timing attacks and differential fault analysis make assumptions about the implementation, and use additional information garnered from attacking certain implementations. Failure analysis assumes a one-bit feedback from the implementation -- was the message successfully decrypted -- in order to break the underlying cryptographic primitive. Related-key cryptanalysis also makes assumptions about the implementation, in this case about related keys used to encrypt different texts. Side-channels attack are a generalization of this idea.

These attacks don't necessarily generalize -- a fault-analysis attack just isn't possible against an implementation that doesn't permit an attacker to create and exploit the required faults -- but can be much more powerful. For example, differential fault analysis of DES requires between 50 and 200 ciphertext blocks (no plaintext) to recover a key.

A side-channel attack occurs when an attacker is able to use some additional information leaked from the implementation of a cryptographic function to cryptanalyze the function. Clearly, given enough side-channel information, it is trivial to break a cipher. An attacker who can, for example, learn every input into every S-box in every one of DES's rounds can trivially calculate the key. What is surprising is how little side-channel information is necessary to break an algorithm. I have published a paper on side-channel attacks against block ciphers at http://www.counterpane.com/side_channel.html.

You can't design the math to solve this problem. You can try to design he hardware so that side-channel information does not leak; this seems to be far more difficult than it appears. Or you can design your cryptographic protocols so that side-channel attacks don't matter. This makes the most sense. Choosing AES based on side-channel resistance is short-sighted.

A long digression on AES, for those who haven't been following the process and for those who care about the outcome: AES is the Advanced Encryption Standard, the new encryption algorithm that will replace DES. NIST is in the process of defining a new encryption standard, which will have a longer key length (128-, 192-, and 256-bit), larger block size (128-bit), be faster than DES, be patent-free, and hopefully will remain strong for a long, long time.

The process is an interesting one. In 1997, NIST sent out a request for candidate algorithms. They received fifteen submissions by the June 1998 deadline, five from the U.S. and ten from other countries. In August, we (my own algorithm, Twofish, was one of the submissions) presented our algorithms to the world at the First AES Candidate Conference.

There was a Second AES Candidate Conference in Rome in March 1999, where people presented analyses of the algorithms. NIST chose five finalist algorithms this summer: Mars, RC6, Rijndael, Serpent, and Twofish. There will be a third AES Candidate Conference in New York in April 2000. NIST is also accepting public comments on the algorithms through 15 April 2000. Finally, NIST will choose an algorithm to become the standard (or perhaps more than one algorithm).

Cryptographers are busily analyzing the submissions for security. It's tempting to think of the process as a big demolition derby: everyone submits their algorithms and then attacks all the others...the last one standing wins. Really, it won't be like that. I strongly believe at the end of the process most of the candidates will be unbroken. The winner will be chosen based on other factors: performance, flexibility, suitability.

This means that we need your input into this process. I know you're not cryptographers, and you won't be able to comment on the mathematics of the various submissions. But you can comment on your encryption requirements, and whether the algorithms will suit your needs.

• AES will have to work in a variety of current and future applications, doing all sorts of different encryption tasks. Specifically:
• AES will have to be able to encrypt bulk data quickly on top-end 32-bit CPUs and 64-bit CPUs. The algorithm will be used to encrypt streaming video and audio to the desktop in real time.
• AES will have to be able to fit on small 8-bit CPUs in smart cards. To a first approximation, all encryption DES implementations in the world are on small CPUs with very little RAM. It's in burglar alarms, electricity meters, pay-TV devices, and smart cards. Sure, some of these applications will get 32-bit CPUs as those get cheaper, but that just means that there will be another set of even smaller 8-bit applications.
• AES will have to be efficient on the smaller, weaker, 32-bit CPUs. Smart cards won't be getting Pentium-class CPUs for a long time. The first 32-bit smart cards will have simple CPUs with a simple instruction set. 16-bit CPUs will be used in embedded systems that need more power than an 8-bit CPU, but can't afford a 32-bit CPU.
• AES will have to be efficient in hardware, in not very many gates. There are lots of encryption applications in dedicated hardware: contactless cards for fare payment, for example.
• AES will have to be key agile. There are many applications where small amounts of text are encrypted with each key, and the key changes frequently. This is a very different optimization problem than encrypting a lot of data with a single key.
• AES will have to be able to be parallelized. Sometimes you have a lot of gates in hardware, and raw speed is all you care about.
• AES will have to work on DSPs. Sooner or later, your cell phone will have proper encryption built in. So will your digital camera and your digital video recorder.
• AES will need to be secure as a hash function. There are many applications where DES is used both for encryption and authentication; there just isn't enough room for a second cryptographic primitive. AES will have to serve these same two roles.
• AES needs to be secure for a long time. Infrastructure is hard to update. Like DES, AES hardware is likely to be installed and used for decades. A radical new algorithm, with interesting and exciting ideas, just doesn't make sense. A conservative algorithm is what is needed.

Choosing a single algorithm (or even a pair of algorithms) for all these applications is not easy, but that's what we have to do. It might make more sense to have a family of algorithms, each tuned to a particular application, but there will be only one AES. And when AES becomes a standard, customers will want their encryption products to be "buzzword compliant." They'll demand it in hardware, in desktop computer software, on smart cards, in electronic-commerce terminals, and other places we never thought it would be used. Anything we pick for AES has to work in all those applications.

So how do you comment? NIST is accepting formal comments either on paper or by e-mail. See http://www.nist.gov/aes for instructions. Be sure to identify who you represent and what cryptography interests you have. And if you have any weird cryptography applications or environments, tell me. I'd like to know. Remember, the AES is going to be your cryptography standard for the 21st century. Tell NIST what you think.

Christopher B. Brown
Several announcements have been made lately about ciphers being assortedly vulnerable/invulnerable against Quantum cryptography.

Quantum physics seems to be the "magical" form of physics, and its application to cryptography even more magical. I don't think I properly understand "quantum cryptography," and I don't think that most of the people that have made public comment on it understand it terribly well either.

Could you comment on the present state of Quantum cryptography, and its probable relevance in public matters short term (which appears nonexistent), medium term (where the research of today may be in 5-10 years), and longer term?

ANSWER:
There are two separate applications of quantum mechanics to cryptography: quantum computing and quantum cryptography. I think you are conflating the two. Let me take them up in turn.

Quantum cryptography is a means of using quantum mechanics for key exchange. Basically, because it is impossible to measure the state of a quantum system without disturbing it, the physics of the key-exchange protocol allows you to detect eavesdroppers. It's a cool idea, and I spend a few pages in _Applied Cryptography_ explaining it in detail.

Quantum computing is newer. It turns out that it is theoretically possible to build a quantum computer. And, if you can build such a beast, it can factor large numbers and calculate discrete logarithms efficiently. Hence, it renders pretty much all of public-key cryptography insecure.

Both of these things are pretty far out. Quantum cryptography has been demonstrated in the lab; British Telcom researchers have exchanged keys over a 10km fiber-optic link. This is interesting, but I don't see it being used very much. The mathematics of cryptography, while not perfect by any means, is the one thing we can do well. There are so many easier ways of breaking into systems, it doesn't make any sense to replace mathematics with physics. And math is always cheaper.

Quantum computing is far out technologically. These computers are theoretically possible to build. We actually have no idea how to build them. Figure it will be ten or twenty or more years before this has a possibility of being a reality. An excellent article was published in a magazine called _The Sciences_. You can find it at http://cryptome.org/qc-grover.htm.

And when it becomes a reality, it does not destroy all cryptography. Quantum computing reduces the complexity of arbitrary calculations by a factor of a square root. This means that key lengths are effectively halved. 128-bit keys are more than secure enough today; 256-bit keys are more than secure enough against quantum computers.

Neville asks:
What's your response to the notion that the web's reliance on centralized Certificate Authorities for secure commerce is ultimately flawed? There are those, like the Meta Certificate Group, who feel that a hierarchical chain of certificates leading back to only a couple of elite organizations won't hold up in the distributed environment of the Internet. The entire framework of e-commerce seems to stand on the private keys of Verisign and Thawte. Do you feel this is a danger, and will there be viable alternatives?

ANSWER:
I agree with you 100%. The notion of a single global public-key infrastructure (PKI) makes no sense. Open your wallet, and you will see a variety of different authentication credentials: driver's license, credit cards, airline frequent flyer cards, library cards, a passport, and so forth. All of these are analog certificates, and will eventually have digital equivalents. There's no reason in the world why Visa can't use your driver's license number as a credit card number; it's just a pointer into a database, after all. But Visa never, ever will. They want control over issuance, update, and revocation. Similarly, digital credentials only make sense when the entity who cares about the credential controls the issuance, use, update, and revocation of that credential.

I have jointly written a paper with Carl Ellison called "Ten Risks of PIKI: What you aren't being told about Public Key Infrastructure." It will be published in the Winter 2000 issue of the _Computer Security Journal_. It's not on my Web site yet, but will be in by December. (Watch http://www.counterpane.com for details.) You can find a lot more good material on the problems with PKI at Carl Ellison's Web site: http://www.clark.net/pub/cme/html/spki.html.

jovlinger asks:

Bruce,

In a recent cryptogram, you write that most symmetric ciphers need more entropy than people can remember and hence supply. Even with bio-metrics adding more bits, it is not really worth the effort to construct ciphers with more than 128 bits of entropy in the key, because people won't give them more than that much entropy in the pass phrase.

However, social and technological pressures make longer and longer keys a necessity. What promising approaches do you see for making remembering and entering -- even though I have long passages of text memorized, I don't want to type them in for each e-mail I want to send -- usefully long passphrases?

I.e., to paraphrase, would you discuss the state of the art of cipher/human interaction, as it pertains to key management?

ANSWER:
For the rest of you, the Crypto-Gram article he mentions is at http://www.counterpane.com/crypto-gram-9910.html#KeyLengthandSecurity. In it, I argue that people just can't remember complicated enough keys and passwords to be immune from brute-force attacks (for example, L0phtcrack, see http://www.l0pht.com/l0phtcrack). Some of us can, but the masses that are using the Internet aren't able to, can't be bothered to, and won't be cajoled to.

The other way to carry around a large pool of random bits is on a data storage mechanism: a smart card, a Dallas Semiconductor iButton, a chip inside a physical key (like the device DataKey sells). These mechanisms are more annoying than passwords and passphrases, but they work. There's no real alternative; if something is too large to memorize, the only solution is to store it somewhere.

I don't believe that biometrics will ever become cryptographic keys. I wrote about this at http://www.counterpane.com/crypto-gram-9808.html#biometrics. Biometrics does have use as an authentication mechanism (note the difference), if it is engineered properly.

-----------------------

Next week: Mick Morgan, "the Queen of England's Webmaster," will answer questions about why not only the Royal Family's Web site but also the huge open.gov.uk site (and more than 80 other official UK Web sites) now run on Linux.

Kathleen Ellis, editor of the Privacy News Portal, has written an excellent feature about how The President's Export Council Subcommittee on Encryption (PECSENC) has recommended dropping almost all export controls on strong crypto, and why it is unlikely that this group's recommendations will be acted on in any meaningful way. (More below)

White House Subcommittee Endorses Crypto Reform.
Will Someone Please Listen?
By Kathleen Ellis

Another shot was fired in one of the longest-lasting and most contentious battles regarding Internet policy last Wednesday, when a White House advisory subcommittee announced it has recommended that the Clinton Administration all but reverse its restrictive stance on the export of encryption products.

The President's Export Council Subcommittee on Encryption (PECSENC) was formed earlier this year by the White House to provide guidance in the U.S. Government's development of encryption policy, which has been the subject of heated debate. As many Slashdot readers already know, the government has insisted for years that liberalizing encryption export could cause serious problems for national security by giving terrorists and criminals access to the technology. Of course, net activists and industry folk assert that the right to privacy supercedes the wishes of any bureaucrat, and that terrorists and criminals can just as easily get their crypto from any other country that does not restrict cryptographic exports.

Critics of the Administration's policy had expected to gain little support through the subcommittee's recommendations. William Crowell, the subcommittee's chairman, is currently President and CEO of Cylink Corporation, an internet security firm, but previously served as Deputy Director for the National Security Agency. Several committee members also had ties to law enforcement or other government agencies; Stewart Baker, an attorney with the Washington-based Steptoe & Johnson, is former general counsel to the NSA and is a vocal opponent of loosening restrictions on encryption. Steve Walker is former president of Trusted Information Systems (now owned by Network Associates), a leading producer of key escrowed encryption products, which the FBI has lobbied to make mandatory even for domestic use.

Despite these ties, however, the subcommittee cited a need for the U.S. government to "recognize market realities" and reverse its course on encryption policy. Among its recommendations:

- License-Free Zones: Recognizing that the European Union is planning to drop all cryptographic export rules between member countries, the US should likewise identify a list of countries which do not pose any major terrorist threat, and allow encryption export (hardware and software products) without a license.

- On-Line Merchants: On-line merchants based in other countries will be added to the list of business types permitted to have encryption products exported to them from the US. Banks and a limited number of other financial institutions currently enjoy this license exception.

- Mass-market hardware and software: Mass-market products which utilize up to 128-bit key length triple DES will enjoy license exception. "The US government should recognize the difficulty of controlling mass-market products once they are allowed to be exported to even limited sectors".

The subcommittee also suggests eliminating cumbersome reporting requirements for manufacturers of encryption products, as well as removal of source code, cryptographic Application Programming Interfaces and devices such as encrypting routers from the list of restricted technologies.

So cypherpunks across the nation will soon be free to export their code at will? Subcommittee chairman William Crowell is hesitant to say yes. "The Administration will have its own ideas about which of these recommendations are implementable. Vice President Gore has said that the administration would consider additional liberalization over what they announced last year, so it was important to get these recommendations to the table while they were thinking about it". He expects that the administration will make further changes to its export policy based on the recommendations sometime in September.

There are other signs of change on the horizon regarding the government's attitude toward encryption. The successor to the current Data Encryption Standard algorithm, which will be used by the U.S. Government for a multitude of purposes, will be chosen by the National Institute of Standards and Technology with the next few months. Four out of the five Advanced Encryption Standard finalists were developed, at least in part, by cryptographers based overseas or holding foreign citizenships. The fact that such decisions could be made by NIST requires the acknowledgement, at least on some level, that good encryption can be produced in countries not affected by U.S. export law, and hence, can be made available around the world.

However, one prominent activist is still skeptical about the potential effect this announcement may actually have on U.S. policy. "This doesn't change policy, this is just yet another group that has come forward and said 'the U.S. policy is abysmal, it needs to be scrapped'" says David Banisar, Deputy Director of Privacy International, and co-author of "The Electronic Privacy Papers". "Many distinguished groups in the past have made similar recommendations...the Clinton Administration has thus far rejected any attempts to dramatically reform export control laws".

Banisar likened the potential influence of the PECSENC recommendations to those of a report published by the National Research Council in 1996. Much more conservative than the PECSENC subcommittee's suggestions, "Cryptography's Role In Securing the Information Society" was written by a committee comprised of government officials, representatives from the computing industry, and academics. The NRC committee's recommendation that 56-bit DES encryption took two years for the Bureau of Export Administration to implement, and many of the other valuable points in the report have never been implemented. The NRC report suggested that U.S. policy should take into account the "nonconfidentiality uses" encryption has to offer. U.S. policy still does not support the use of encryption for the purposes of authentication, which the committee identified as an "important crime-fighting measure". Indeed, one would think that the F.B.I. and the Department of Commerce would hasten to encourage the use of such technologies.

Banisar also expressed concerns about the provisions favoring online merchants. "The e-commerce exports have already been promised to online merchants...they will get what they want, which helps the Clinton Administration divide and conquer their opposition". Banisar stated that civil libertarians lost a powerful lobbying ally when banks were granted the same licensing exemptions now promised to entrepreneurs online. "When a wealthier group gets what they want, they stop fighting, and the everyday users get screwed."

It also seems that the recommendations do not go far enough to help the people who need encryption technology most. Barbara Simons is President of the Association for Computing Machinery and one of the members of the PECSENC committee. "It appears that the recommendations don't address the needs of people working for human rights in countries with repressive regimes," she says.

The human rights issue is a valid one within the debate on U.S. encryption policy. The American Association for the Advancement of Science's Cryptography, Scientific Freedom, and Human Rights program trains human rights workers to use encryption technology in countries like Guatemala and China, where oppressive governments have a way of making insurrectionists disappear. A letter from AAAS to the House or Representatives Committee on International relations states that "human rights activists are killed, tortured, disappeared and jailed for trying to expose horrendous abuses...[they] use encryption to protect themselves, the victims and eyewitnesses they are interviewing, and human rights colleagues around the world when they communicate sensitive information on grave abuses of human rights".

It would be wise and compassionate for the Clinton Administration to authorize a new class of license exceptions for human rights workers travelling into countries that don't fall under the "favored nations" exemptions for encryption exports. If national security were really a concern in these cases, they could add strict guidelines describing who the software could legally be distributed to within those countries. Unfortunately, PECSENC seems to have overlooked this important issue.

Despite these shortcomings, there are some definite gains to be made by following PECSENC's recommendations. Net activists will be keeping their fingers crossed when the White House reviews them next month. Progress has been far too slow in coming, and if there's ever been a time for our government to start making some positive decisions, this certainly is it.

James Morris writes "NIST has announced the AES finalists for round two. (AES is new data encryption scheme intended to replace DES). The finalists are MARS (IBM), RC6 (RSA), Rijndael (Joan Daemen and Vincent), Serpent (Ross Anderson, Eli Biham and Lars Knudsen) and Twofish (Bruce Schneier and friends). " While this is the second round, the choosing of a finalist it still quite aways off.

15 companies are competing to try to be the company that provides the new encryption standard for the US government. The new project, Advanced Encryption Standard will be the one to replace the broken-as-Russia's-stock-market DES standard. For information check out this site.

Gregory Seidman wrote in to ask " I would like there to be a public (web) database of open source programs searchable by task/niche in particular." I can think of several, but I'm curious what people's opinions are of these. Some are fairly comprehensive, others are easy to use. Is there a clear winner? There are gold nugget applications out there, but so often they are things you stumble upon... it would be nice if they could be found simply.

ray jones writes "Bruce Schneier's company, Counterpane Systems, has released a description and source code for a new block encryption algorithm, Twofish. Twofish is their submission to the NIST's Advanced Encryption Standard process. Twofish is unpatented/uncopyrighted, much like its predecessor, Blowfish. Crypto is an area that's long used a model similar to open source to ensure that ciphers are safe. Ciphers developed in secret (such as Skipjack) are considered unreliable by default."

ray jones writes "Bruce Schneier's company, Counterpane Systems, has released a description and source code for a new block encryption algorithm, Twofish. Twofish is their submission to the NIST's Advanced Encryption Standard process. Twofish is unpatented/uncopyrighted, much like its predecessor, Blowfish. Crypto is an area that's long used a model similar to open source to ensure that ciphers are safe. Ciphers developed in secret (such as Skipjack) are considered unreliable by default."