Recently I had an opportunity to speak with Vincent Rijmen, co-author of the Rijndael ("Rhine Dahl") proposed AES algorithm. Rijndael was selected on October 2, 2000 from fifteen candidates submitted to the National Institute of Standards and Technology in 1997.
Rijndael takes its name from its creators' last names, and beat out finalists including those from IBM, RSA, Counterpane, and the Serpent algorithm developed by a group of European cryptographers. AES will soon replace DES as the standard algorithm for encrypting sensitive data. It has been reported that even a machine capable of breaking the old DES standard in a second would take some 149 trillion years to crack the proposed AES's lowest level of security.
LinuxSecurity.com: Can you describe your background? What did you first do when you discovered your algorithm was selected?
Vincent Rijmen: I am an electronics engineer. I have a PhD in applied sciences. The NIST press release site has my bio.
When the phone call from NIST came, I told my wife and my collegues and we went out for a drink.
Like so many young boys, I was fascinated by computers. And then I happened to study at the university K.U.Leuven, which happened to have one of Europe's leading research groups in cryptography and I got the opportunity to get a scholarship there... It all happened without really considering all the consequences on my `career path'.
LinuxSecurity.com: What applications do you forsee it being used?
Vincent Rijmen: Many many applications. Protection of sensitive files of the US government (mandatory). Email encryption. Mobile phones. Smartcards.
LinuxSecurity.com: What makes it so suitable for such a wide variety of applications?
Vincent Rijmen: That is because of the design. We only use processor instructions that are available on all existing processors, and that are also fast on all processors. We have lots of parallellism that can be exploited by parallel platforms.
LinuxSecurity.com: How long did it take to develop the algorithm that will provide security for the digital economy well into the 21st century?
Vincent Rijmen: It depends on how you count. Our research is a continuous process, and it's not easy to say when we started on Rijndael. About a year or two, I would estimate.
LinuxSecurity.com: Did you develop the algorithm for the specific purpose of the NIST entry, or was it something you were working on previously and then submitted it?
Vincent Rijmen: We had previously made something that cam very close to the requirements listed in the NIST call, so we started changing it a bit and submitted that.
LinuxSecurity.com: What significance does this new encryption standard have on commerce on the Internet and security in general?
Vincent Rijmen: It's a very strong cornerstone, but it's not the complete answer. I sometimes compare it to a new engine that can be used in a car. But you also need brakes, a steering wheel, ...
LinuxSecurity.com: What do you mean here? What are the other specific pieces that are necessary for successful commerce?
Vincent Rijmen: You need an operating system that is less vulnerable to viruses and trojan horses. The best encryption won't help you if a hacker can read every key stroke you type. You need a system to distribute keys. You need to ensure that people don't use weak passwords.
LinuxSecurity.com: What is it about your algorithm that you think made the difference in the eyes of NIST? Certainly none of the finalists had a security weakness...
Vincent Rijmen: They indicate that the flexibility was an important factor. Incorporating Rijndael into applications comes at a low cost in terms of hardware resources, and still it's very efficient on most platforms. Rijndael gives you good security for a very low cost.
LinuxSecurity.com: Why isn't DES a suitable solution any longer?
Vincent Rijmen: Because the key length is too short, it becomes possible to try out all keys. Because the cost to do this search decreases every year, it makes no sense anymore to build in DES in new products.
LinuxSecurity.com: How "free" is the algorithm? Large-scale securing of open source systems with cryptography has been hindered until recently. This was due to the widespread use of the RSA algorithm, which was patented. Will there be any patents, copyright or other intellectual property issues with the Rijndael algorithm?
Vincent Rijmen: NIST specified that the AES candidate designers should release all IP claims. This has been done. Furthermore, NIST asked all interested parties to make any applicable patents known. No patent applying to Rijndael was invoked. To the best of my knowledge, the answer to your question is "no".
LinuxSecurity.com: Now that Rijndael has been selected as the winner, the amount of academics and also black hats scrutinizing the algorithm will surely skyrocket. How confident are you that the algorithm will survive this scrutiny without any issues?
Vincent Rijmen: I'm relatively confident, but in fact, I don't know. A designer inevitably has a biased view of his own algorithm, so Joan and I are not the persons you should ask to answer this question.
LinuxSecurity.com: How cool it must be to know you now have the admiration of the global computer security community. Have you had an opportunity to ever talk or meet with other applicants for AES?
Vincent Rijmen: I know many of them personally, because I met them at cryptographic conferences. There were also three AES conferences, attended by most of the submitters.
LinuxSecurity.com: How do you think the state of security on the Internet has changed since you first got involved? What do you think is going to change in the near future to protect the privacy and security of those of us on the Internet? (What do you see as the most significant trends or developments in computer security in the next few years?)
Vincent Rijmen: The security has been improved from "no security" to "a little bit security": there is now protection against casual hackers, but not yet against people determined to break in. An important trend is the spread of strong cryptographic primitives (e.g. with keys longer than 40 bits). However, more is needed to get a decent level of security.
LinuxSecurity.com: I understand you are an avid fan of Linux, based on some of the comments on your website. Do you think Linux has a place in the data center as a secure platform for commerce in the state that it's currently in?
Vincent Rijmen: I think Linux is among the best available platforms available today, also in the field of security and ecommerce. However, a Linux system needs to be managed by a competent administrator.
LinuxSecurity.com: What are some of the biggest challenges you face when dealing with security?
Vincent Rijmen: Me personally?
I think there is an important challenge in making the distinction between complexity and security. Some people still believe that added complexity increases automatically security. This belief should be erased. We should keep on working towards secure and simple systems, that are as easy to understand for the people as a door lock, a sealed envelope, etc.
LinuxSecurity.com: Do you believe the open source nature of Linux provides a superior vehicle to making security vulnerabilities easier to spot and fix?
Vincent Rijmen: Yes. Not only because more people can look at it, but, more importantly, because the model forces people to write more clear code, and to adhere to standards. This in turn facilitates security reviews.
LinuxSecurity.com: What is the Belgium government position on crypto export? What do you think of the restrictions the US government have placed on crypto export?
Vincent Rijmen: No comment.
LinuxSecurity.com: How was the process of choosing the applicants different for AES than it was in the past?
Vincent Rijmen: It was public.
LinuxSecurity.com: Have you written any other crypto algorithms that you consider noteworthy? What do you plan to do with cryptography in the future?
Vincent Rijmen: We also made `Square', the predecessor of Rijndael (this was the algorithms that we had when the NIST call came out, to which I referred previously).
LinuxSecurity.com: Given that most security systems fail for reasons rooted in implementation, would you comment on rfc2692 which says:
An SPKI certificate should be described in as simple a method as possible, relating directly to the kind of structures a C or PASCAL programmer would normally write. No library code should be required for the packing or parsing of SPKI certificates. In particular, ASN.1 is not to be used. A certificate should be signed exactly as it is transmitted. There should be no reformatting called for in the process of checking a certificate's signature (although one might canonicalize white space during certificate input, for example, if the format is text). For efficiency, if possible, an SPKI certificate should be encoded in an LR(0) grammar. That is, neither packing nor parsing of the structure should require a scan of the data. Data should be read into the kind of structure a programmer would want to use without touching the incoming bytes more than once. For efficiency, if possible, an SPKI certificate should be packed and parsed without any recursion.
Vincent Rijmen: I have no comment.
LinuxSecurity.com: Thanks very much for the opportunity to speak with you, and wish you all the best.
Vincent Rijmen: You're welcome
- Commercial Encryption Export Controls -- This is the Bureau of Export Administration U.S. Department of Commerce home page.
- Advanced Encryption Standard home page -- Information on AES, Rijndael, Crypto whitepapers, and other AES entries.
- RSA Security Cryptography FAQ -- This section provides some information on AES.
- AES FAQ -- Answers to questions including information on NIST, the algorithm itself, implementation dates, more info on why Rijndael was selected, and export information.
- The Rijndael Home Page -- Pointers to source code, description, quick FAQ, and more.
- Linux Encryption HOWTO -- Information on implementing disk, network and kernel encryption.
- Report on the Development of the Advanced Encryption Standard -- This document describes the AES and Rijndael in great detail, including the selection process and technical details.