As Bram Cohen put it:

...

.> The selection of Rijndael was actually quite predictable - the round 2 ..> report made it pretty clear that the only real contenders were Rijndael c.> and Twofish, and hey, that last coin toss is free with 20/20

hindsight :)

Actually I had the clear impression that there were three real contenders: Rijndael, Serpent, and Twofish, in this order.

Not to take anything from Rijndael, which is both popular and widely respected among many critical professionals, but I suspect that one of the more long-lasting (pseudo-conspiratorial) theories about the selection of Rijndael as the AES will be built around the fact that Rijndael's design apparently allowed it -- and it alone of the final five -- to escape the scope of a current US patent issued to Hitachi (which is said to cover the use of data rotation in encryption.) (Thus -- as the tale may be told -- did the "inadequacies" of the US Patent and Trademark Office define US and world crypto standards for the 21st Century;-) I can't (for the life of me;-) figure out which of Hatachi's US crypto patents this claim is based upon, but the formal Hitachi warning to NIST -- dated last April -- that Hitachi had IP (US patents) which covered AES candidates is at: http://csrc.nist.gov/encryption/aes/round2/comments/20000407-sharano.pdf. I noticed, Paulo, that you were one of those who were (unsuccessfully) nagging NIST for information about their reaction to the Hitachi IP claims. Any thoughts -- or additional information to offer -- in the aftermath of the coronation? Surete, _Vin

On Wed, 04 Oct 2000, Vin McLellan <me> wrote:

...

Not to take anything from Rijndael, which is both popular and widely respected among many critical professionals, but I suspect that one of the more long-lasting (pseudo-conspiratorial) theories about the selection of Rijndael as the AES will be built around the fact that Rijndael's design apparently allowed it -- and it alone of the final five -- to escape the scope of a current US patent issued to Hitachi (which is said to cover the use of data rotation in encryption.)

(Thus -- as the tale may be told -- did the "inadequacies" of the US Patent and Trademark Office define US and world crypto standards for

the

...

21st Century;-) <snip>

Paulo S. L. M. Barreto replied: <snip>

I certainly noticed the fact that Rijndael was not mentioned in the Hitachi claim. However, so did Bruce Schneier, and he pointed out that Rijndael's ShiftRow operation is in fact a rotation, and so it should be also be covered by Hitachi's claims. Therefore, all AES finalists were seemingly equally endangered. I personally find Hitachi's claims absurd, and I wanted to know whether NIST thought the same way as I did.

I just found Schneier's 5/14 note: "AES Comment: the Hitachi patent," (on Sci.Crypt, via dejanews.) I was not aware that Rijndael's ShiftRow op was a rotation. That was a great letter. The TwoFish authors (among many others;-) obviously agree with your analysis.

However, I think you might use the 21st century US legal system to manifest your concerns, if indeed you have any, that Hitachi's patent hindered the choice of any other algorithm (as this was rumoured a few days ago in this list -- I wonder who posted it, don't you, Vin?), against NIST's own statement on the contrary, made in the final report available from NIST's web site.

Oh, come on! I do think the Hitachi claim should be challenged and disputed. I also don't think it is surprising -- particularly when the AES website's IP forum spins around the Hitachi patents and the relevance of the Hitachi claims is, in that forum, left unresolved -- that unaligned and wholly objective curious observers might bring up the question now. As the basis of an AES conspiracy theory, the two Hitachi patents strike me as pretty frail. (Rijndael is clearly a powerful and elegant algorithm, fully a peer if not the Obvious Choice among the five great cryptographic creations matched in the AES Finals.) OTOH, far more specious allegations have entangled millions in Byzantine mystery scenarios, on far less obtuse topics. My impression is that NIST covered itself with glory in its handling of the AES competition, but -- really! -- who in their right mind is gonna take the word of a US federal agency that the existence of issued US patents, and the scope of the patent-owner's claims, was irrelevant to their deliberations. (Even if it is true;-)

I'll bet most people that were committed (perhaps financially) to any other of the finalists will show a reaction similar to yours. Well, this reaction is not unexpected anyway -- just remember that saying about Greeks and Trojans.

My comment was simply that the Hitachi patent claims set the stage for rumors that may shadow the AES choice for years. I think that is unfortunate. Personally, I think it is embarrassing that the Hitachi patents were ever issued. My impression is that -- despite their vigorous competitive impulses -- the cryptographers who carried their work into the AES Finals all showed a great deal of respect for each other's work. They all shared the Pantheon of their Craft, and even the contenders were ennobled. In the aftermath of the NIST decision, I haven't heard sour grapes comments from any of them -- and I would be very surprised if I did. All the grumbling is just background noise from the wee folk, and I suspect it would be pretty much the same tenor, no matter which algorithm was chosen. Suerte, _Vin Vin McLellan The Privacy Guild Chelsea, MA USA

At 5:43 AM -0400 10/5/2000, Vin McLellan wrote:

...

As the basis of an AES conspiracy theory, the two Hitachi patents strike me as pretty frail. (Rijndael is clearly a powerful and elegant algorithm, fully a peer if not the Obvious Choice among the five great cryptographic creations matched in the AES Finals.) OTOH, far more specious allegations have entangled millions in Byzantine mystery scenarios, on far less obtuse topics.

My impression is that NIST covered itself with glory in its handling of the AES competition, but -- really! -- who in their right mind is gonna take the word of a US federal agency that the existence of issued US patents, and the scope of the patent-owner's claims, was irrelevant to their deliberations. (Even if it is true;-)

...

My comment was simply that the Hitachi patent claims set the stage for rumors that may shadow the AES choice for years. I think that is unfortunate. Personally, I think it is embarrassing that the Hitachi patents were ever issued.

Maybe I am missing something, but what would be the big deal if NIST did take patent claims into account? There were five excellent candidates. If NIST picked Rijndael in part because it least likely to be tied up in court for the next N years, does that diminish their glory?

My impression is that -- despite their vigorous competitive impulses -- the cryptographers who carried their work into the AES Finals all showed a great deal of respect for each other's work. They all shared the Pantheon of their Craft, and even the contenders were ennobled. In the aftermath of the NIST decision, I haven't heard sour grapes comments from any of them -- and I would be very surprised if I did. All the grumbling is just background noise from the wee folk, and I suspect it would be pretty much the same tenor, no matter which algorithm was chosen.

Quite right. There is plenty of credit to go around. I was particularly pleased that NIST had the guts to pick a non-U.S. design. That's risky in Washington. Arnold Reinhold P.S. What is the licensing status of the other finalists? For example, I seem to recall reading that RC6 would be licensed to the public at no charge if it won the competition. What now?

That a Belgian cryptosystem was eventually selected as the American AES may make it easier to dismiss those fears overseas, and may hasten the adoption of AES internationally. Full AES standardization and interoperability, a good thing, should come more quickly.

Not so, inprepid Vin. A Belgian cipher was chosen simply because the NSA was able to operate with relative impunity in that region, in which it has huge per-capita deployment, compared to a similar actions on its own soil. Cheers, Julian.

Arnold G. Reinhold asked:

What is the licensing status of the other finalists? For example, I seem to >recall reading that RC6 would be licensed to the public at no charge if it won the competition. What now?

Since April, RC6 has being commercially licensed as part of RSA's BSAFE Crypto-C 5.0 and BSAFE Crypto-J 3.0 software developer toolkits. I don't expect that will change. (RSA said, however, that by the end of the year its regular support and maintenance procedures will add Rijndael to both of those SDKs. RSA also said it will adopt the AES as "a baseline encryption algorithm" for its Keon family of digital cert products.) Given RSA's market share, the eight BSAFE toolkits could be a major channel for distributing AES code to the developer community, particularly among OEMs. http://www.rsasecurity.com/products/bsafe/ Of the other three who made the finals in this "Crypto Olympics." MARS, while patented, is available world-wide under a royalty-free license from Tivoli Systems, an IBM subsidiary. (See http://www.tivoli.com, although the Tivoli site doesn't seem to have anything but the press release.) Serpent is public domain, now under the GNU PUBLIC LICENSE (GPL), although Serpent website warns that "some comments in the code still say otherwise." http://www.cl.cam.ac.uk/~rja14/serpent.html Twofish is "unpatented, and the source code is uncopyrighted and license-free; it is free for all uses." http://www.counterpane.com/twofish.html Suerte, _Vin

At 01:44 PM 10/10/00 -0400, Arnold G. Reinhold wrote:

Thanks for the summary. My only problem with Rijndael is that it is still rather young. I recall reading that NSA takes seven years to qualify a new cipher. It took at least that long for the open cryptographic community to trust DES. If someone asked me what cipher to use today in a new, very high value application, I would have a hard time choosing between Rijndael and 3DES. Rijndael appears to be a far superior design, but 3DES has enjoyed a lot more scrutiny.

I was thinking it might be useful to define a "Paranoid Encryption Standard (PES)" that is a concatenation of all five AES finalists, applied in alphabetical order, all with the same key (128-bit or 256-bit). ...

To be truly paranoid, shouldn't you use independent, unrelated keys? What if the "outermost" cipher falls to an attack that allows the key to be computed, thus allowing the same key to be plugged into all the "inner" ciphers? To put this suggestion into perspective, consider that in the real world, pure cipher strength is rarely the weakest link in the security chain, provided that a reasonable key length and cipher are chosen. Having done that, go for it if you still think you can afford the extra time, space, and key management with (probably) no measurable increase in overall system security. _______ Michael Paul Johnson mpj@eBible.org http://ebible.org/mpj

At 03:59 PM 10/10/00 -0600, Michael Paul Johnson wrote:

...

I was thinking it might be useful to define a "Paranoid Encryption Standard (PES)" that is a concatenation of all five AES finalists, applied in alphabetical order, all with the same key (128-bit or 256-bit). ...

To be truly paranoid, shouldn't you use independent, unrelated keys? What if the "outermost" cipher falls to an attack that allows the key to be computed, thus allowing the same key to be plugged into all the "inner" ciphers?

And the Ultra-Paranoid ES, which adds random salt to each stage between ciphers...

At 8:13 PM -0400 10/11/2000, John Kelsey wrote:

-----BEGIN PGP SIGNED MESSAGE-----

At 01:44 PM 10/10/00 -0400, Arnold G. Reinhold wrote:

...

...

I was thinking it might be useful to define a "Paranoid Encryption Standard (PES)" that is a concatenation of all five AES finalists, applied in alphabetical order, all with the same key (128-bit or 256-bit). If in fact RC6 is the only finalist still subject to licensing by its developer, it could be replaced by DEAL (alphabetized under "D"). Since DEAL is based on DES, it brings the decades of testing and analysis DES has received to the party.

This basic idea is discussed in Massey and Maurer's ``The Importance of Being First'' paper. There are a couple issues:

I read the Massey and Maurer paper (One can find it at http://www.isi.ee.ethz.ch/publications/isipap/umaure-mass-inspec-1993- 1.pdf ) and I have a couple of comments on it. As I understand it, their argument goes like this: Let the concatenated cipher C1*C2 applied to plaintext P be C2(C1(P)). If C2 is subject to attack when the plaintext it gets has certain statistical properties, then it is possible for C1's ciphertext to have those properties and the concatenated cipher to be less resistant to statistical attack than either component. Massey and Maurer give a very simple example to show this can occur. Here is a bit more realistic example: Suppose C1 simply permutes the input bits and that in doing so it takes the high-order bit of each plaintext byte and moves it to the first two bytes of the cipher text. Suppose further plaintext blocks that have the first two bytes zeroed are weak for C2. Then if C1 is fed ordinary printable ascii text with no parity, the first two bytes of C1-ciphertext will be zero, exposing the weakness of C2. On the other hand, if C2 were used alone on the same ascii plaintext it would never see zeros as input bytes and thus would not be subject to attack. However in the case of a chosen-plaintext attack, Massey and Maurer's argument does not work. In fact the proof they give of their "Proposition" can easily be adapted to prove that a concatenated cipher C1*...*Cn is always at least as difficult to break by chosen-plaintext as *any* cipher in the concatenation. Here is an outline of the proof. Note, as they do, that the worst case is when you can easily determine the key to every cipher except one. In their case it is the first cipher, in ours say it is Ci, 1<=i<=n. Then any set of chosen plaintext, ciphertext pairs (PTj, CTj) that results in a break of the concatenated cipher C1*...*Cn can be converted in to a set of chosen plaintext, ciphertext pairs (PT'j, CT'j) that results in a break of Ci as follows (I'll use CCk to denote the inverse cipher of Ck): PT'j = (C1*...*Ci-1)(PTj) CT'j = (CCi+1*...*CCn)(CTj) One might ask why this proof works in the chosen-plaintext attack but not the statistical attack. The reason is that in the later, while you can still compute each PT'j, there is no reason to expect that they will have the same statistical properties as the original PTj. However PT'1 is always equal to PT1, so the proof does work for the first cipher in the statistical attack case. That is where "the importance of being first" comes from. My main question is how much weight should we give to this result in designing a crypto system by combining AES candidates? Remember that the AES candidates were designed to resist chosen-plaintext attack. Resistance to chosen-plaintext attack is a far more stringent demand on a cipher than resistance to statistical attack. And I have just shown that a concatenated cipher is at least as strong as any of its components against chosen-plaintext attack. So why should we even consider Massey and Maurer's result? The one argument I can think of goes like this: Suppose we are wrong and all the component ciphers are subject to chosen-plaintext attack and, even worse, so is the concatenated cipher. The component ciphers might still be resistant to statistical attack and often this is the best attackers can do, so we would like the extra insurance. But in the real world of AES candidates I claim even that argument should be discarded. Massey and Maurer worry about the possibility that the output of one cipher may have statistical properties that cause weakness when that output is fed into the subsequent ciphers. The AES candidates were designed to have outputs that appear uniformly random and have all undergone extensive statistical testing http://csrc.nist.gov/encryption/aes/round1/r1-rand.pdf. The have also been studied for weak inputs. Thus the first cipher in the concatenation can be expected to destroy patterns in the plaintext, not create them. While not a mathematical proof, the results of the AES candidate analysis and testing to date make it overwhelmingly more likely that the concatenation of AES-candidate ciphers will in fact be more resistant to statistical attack than any of the individual ciphers.

a. The keys need to be independent. (Otherwise, imagine if cipher #1 is DES encryption, and cipher #2 is DES decryption.)

I don't think it is quite that clear. It might well be easier to prove, say, that Twofish is not the inverse of MARS for the same key than it is to prove the same result for separately hashed keys. But again, the likelihood of two different ciphers being accidental inverses is even lower than the likelihood of guessing the key correctly (there are (2**n)! bijections on n-bit blocks). And NIST has just released SHA-2 which provides 256 bit hashes, so I suppose we might as well use it here.

b. There order of the ciphers matters for the kind of security proof you can do. If you do Twofish, then Rijndael, you can prove that a known-plaintext attack on this system = a known plaintext attack on Twofish and a chosen-plaintext attack on Rijndael. (That is, the combined system can be no easier to break than the easier of a known-plaintext attack on Twofish or a chosen-plaintext attack on Rijndael.)

Is this the Massey and Maurer result or is there something specific about these two ciphers?

A smarter way to do this is to do OFB-mode or counter-mode with all N ciphers. That way, you can prove that breaking the resulting cipher is equivalent to breaking OFB mode encryption under all N of the ciphers.

The problem with OFB is that what you get is a stream cipher and that, in turn, means a unique IV for each message is required. I have spent a lot of effort in my CipherSaber project teaching people how to do that, and the risk of implementors getting it wrong is high. I've even seen commercial products that claim to use RC4 but don't do IVs. Note that IV reuse is far more catastrophic in a stream cipher than it would be in a block cipher used in a feedback mode. Also OFB means that ciphertext is always bigger than plaintext (if you include the IV). That prevents encryption in place, for example. I'd rather have a block cipher if at all possible. So here is my draft proposal for the Paranoid Encryption Standard, PES: (P is a plaintext block and K is the user key.) PES(P) =Twofish(Serpent(MARS(DEAL(AES(P))))), where: the key for AES is SHA2(K||"Rijndael") the key for DEAL is SHA2(K||"DEAL") the key for MARS is SHA2(K||"MARS") the key for Serpent is SHA2(K||"Serpent") the key for Twofish is SHA2(K||"Twofish") The character string constants are 8-bit ascii with zero parity bit. The order of each cipher is determined alphabetically, except that I obviously could have chosen to put Rijndael under "R" instead of "A." By putting it first we can take advantage of Massey and Maurer's result and state the PES is at least as strong against statistical attack as AES. The second cipher, DEAL, is based on DES, which has received the most public scrutiny of any cipher. I am not aware of any statistical attack on DES inputs or any statistical weaknesses in DES output that might compromise MARS. And, as we have shown above, PES is at least as resistant to chosen plaintext attack as any of its components. PES is intended to address concerns that AES might have a design flaw or deliberate, hidden weakness. Confidence that neither exist can only come from additional years of testing and analysis. PES, because it is at least as strong as AES and incorporates the strengths of four other AES design teams and the decades of work on DES, might be a better choice for very high value messages, where encryption time is not an issue. Some other comments I have received urged the use of salt. Salt is very important is overall system design, but it is not part of the cipher per se. As I mentioned in my earlier post, RC6 is not being used because it still requires licensing. No criticism of RC6 or its owner's decision to retain commercial licensing rights is intended. FWIW Arnold Reinhold

-----BEGIN PGP SIGNED MESSAGE----- At 02:26 PM 10/20/00 -0400, Arnold G. Reinhold wrote:

At 8:13 PM -0400 10/11/2000, John Kelsey wrote:

...

I read the Massey and Maurer paper (One can find it at http://www.isi.ee.ethz.ch/publications/isipap/umaure-mass-inspec-1993 1.pdf ) and I have a couple of comments on it.

Okay. I think it's a lot easier to understand their result and all its implications like this: Suppose we have two ciphers, E_{K}(X),F_{K}(X), and we encrypt by computing C[i] = E_{K1}( F_{K2}( P[i] ) ) Now, suppose I can break this composed cipher, when you choose E and F's keys independently, in a known plaintext attack. I have some algorithm, A(), into which I feed my known plaintexts and the corresponding ciphertexts, and it churns on them for awhile, and returns the keys K1,K2. This algorithm can be used to break E in a known plaintext attack as follows: You encrypt a bunch of messages under E_{K1}(X). I know nothing of K1, but I know the plaintexts and their corresponding ciphertexts. I randomly choose a key K2, encrypt all those ciphertexts with F_{K2}, and then feed the original plaintexts and my ciphertexts into my algorithm for breaking the composed cipher E_{K1}(F_{K2}(X)). That means that a known plaintext attack on E(F()) leads to a known plaintext attack on E(). I can also mount a chosen plaintext attack on F, when you choose a random key K2. I randomly select a key K1, randomly select a bunch of plaintexts, and encrypt them all under E_{K1}. I then send you the ciphertexts and ask you to encrypt them under F_{K2}. You do so, and send me back the results. I now send my original plaintexts and the ciphertexts you sent me into my algorithm for breaking the composed cipher E_{K1}(F_{K2}(X)). That means that a known-plaintext attack on E(F()) leads to a chosen-plaintext attack on F(). All the result is saying is that you can always convert breaking both ciphers to breaking either cipher individually. The cool part of this isn't the worry about which cipher comes first, it's the fact that, with independent keys, you can show that composing the ciphers gives you a cipher no weaker than the stronger of the two ciphers. The reason the keys have to be independent is because otherwise, the proof doesn't work. If the keys are chosen so that K1 == K2, then I can't build these attacks for my proof, because I can't choose F_{K2} without knowing K1. Now, we can also come up with examples of places where choosing K1 and K2 to be related is a bad idea. For example, imagine the following ``game:'' You define some structure for putting N block ciphers together, and then I get to choose the N ciphers, with the constraint that at least one of the N must be strong against all attacks. Now, in this model, it's clear that if the keys are all equal, I can choose the ciphers so that a structure like E1(E2(E2(X))) is easily broken. (Let E1 = 3DES encryption, E2 = 3DES decryption, and E3 = the identity cipher.) In this model, it's also clear that when the keys are independent, I can't choose the ciphers to include one strong cipher and N-1 ones specially designed to me to make the composition weak. If I could, I could always convert the algorithm into a chosen-plaintext attack on the strong cipher. But these are different arguments. The Massey and Maurer argument, at least as I've understood it, is that the keys have to be independent because otherwise the proof doesn't work, and so we can't say anything about their security. The game example I just gave argues that it's clearly possible to choose strong ciphers that fit into this multiple-encryption structure, and combine them in a way that's weak, when the keys are not independent. (But it's been five years or so since I read their paper, so I may be forgetting some of what they said.) ...

However in the case of a chosen-plaintext attack, Massey and Maurer's argument does not work. In fact the proof they give of their "Proposition" can easily be adapted to prove that a concatenated cipher C1*...*Cn is always at least as difficult to break by chosen-plaintext as *any* cipher in the concatenation.

Right. This falls out of the basic argument really nicely. If you want to use an algorithm to break E1(E2(X)) to break E1(X), it has to use a chosen-plaintext attack on E1.

My main question is how much weight should we give to this result in designing a crypto system by combining AES candidates?

Probably not too much, in terms of worrying about known-plaintext vs. chosen-plaintext attacks. Though honestly, I think designing your PES is like providing really effective padlocks for screen doors. (But you could say the same thing about AES with 256-bit keys.) ...

...

a. The keys need to be independent. (Otherwise, imagine if cipher #1 is DES encryption, and cipher #2 is DES decryption.)

I don't think it is quite that clear. It might well be easier to prove, say, that Twofish is not the inverse of MARS for the same key than it is to prove the same result for separately hashed keys. But again, the likelihood of two different ciphers being accidental inverses is even lower than the likelihood of guessing the key correctly (there are (2**n)! bijections on n-bit blocks). And NIST has just released SHA-2 which provides 256 bit hashes, so I suppose we might as well use it here.

See above. The important part of the Maurer and Massey proof, IMO, is that it shows that you do get at least the strength of the strongest component cipher against chosen-plaintext attacks. But that proof falls apart when you don't have independent keys, which means you can't really say anything about the strength of the composed cipher. And the game argument shows that it's possible to choose those ciphers with non-independent keys badly enough to make the composed cipher weaker than any of its components.

...

b. There order of the ciphers matters for the kind of security proof you can do. If you do Twofish, then Rijndael, you can prove that a known-plaintext attack on this system = a known plaintext attack on Twofish and a chosen-plaintext attack on Rijndael. (That is, the combined system can be no easier to break than the easier of a known-plaintext attack on Twofish or a chosen-plaintext attack on Rijndael.)

Is this the Massey and Maurer result or is there something specific about these two ciphers?

It's the Massey and Maurer result. ...

The problem with OFB is that what you get is a stream cipher and that, in turn, means a unique IV for each message is required.

Hmm. It seems like you're going to need an IV for any chaining mode. Using a superstrong block cipher, but then not bothering to use a chaining mode, is just silly. The IV reuse problem *is* a lot worse for OFB and counter modes than for any other mode. Though once you decide you're going to use CFB- or CBC-mode, and choose a random IV, nearly all attacks end up being chosen-plaintext attacks, so maybe that's another reason not to worry too much about which cipher is first.

So here is my draft proposal for the Paranoid Encryption Standard, PES: (P is a plaintext block and K is the user key.)

PES(P) =Twofish(Serpent(MARS(DEAL(AES(P))))), where:

the key for AES is SHA2(K||"Rijndael") the key for DEAL is SHA2(K||"DEAL") the key for MARS is SHA2(K||"MARS") the key for Serpent is SHA2(K||"Serpent") the key for Twofish is SHA2(K||"Twofish")

Just an aside: What properties are you assuming for SHA2? Because you're going to all this trouble to build a paranoid encryption standard, but then you're doing this weird construction to derive keys for everything, and it's not clear that you can prove anything about the structure when SHA2 is just a collision-resistant hash function. ...

Arnold Reinhold --John Kelsey, Counterpane Internet Security, kelsey@counterpane.com PGP Fingerprint: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF

-----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use http://www.pgpinternational.com Comment: foo iQCVAwUBOfSD3iZv+/Ry/LrBAQFBoAP+Jeq0bc9cA36WxnxOl+rz3O8bOYPkB0cG GLmCSm0gyxTPtfrDiqWW/fGFxOl0/E+Ec6IzG+WPrg7lwy5gjeOEHfzIkfB5dC0E rctkTSTum0lXGD3WKAOc4E+SKPaaU6pQRDZ4YcYkOZXGN9WVO88v7zZSGJvMCay9 ig11jvhdgGc= =Xa+c -----END PGP SIGNATURE-----

On Thu, 26 Oct 2000, Arnold G. Reinhold wrote:

simple way to combine the AES finalists and take advantage of all the testing that each has already undergone. And, IMHO, it is an interesting theoretical question as well. Even if the answer is "yes," I am not advocating that it be used in most common applications, e.g network security, because there are so many greater risks to be dealt with. But it might make sense in some narrow, high value, applications.

What threat model do you propose that would require this? I can't think of anything that isn't contrived and couldn't be served by using 3DES. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org

"Arnold G. Reinhold" wrote:

...

This is just silly. There's nothing wrong with Rijndael. ... Testing is the most expensive part of any new cipher effort. So I

At 2:14 PM -0700 10/20/2000, Bram Cohen wrote: think there is a practical basis for at least asking if there is a simple way to combine the AES finalists and take advantage of all the testing that each has already undergone. And, IMHO, it is an interesting theoretical question as well. Even if the answer is "yes," I am not advocating that it be used in most common applications, e.g network security, because there are so many greater risks to be dealt with. But it might make sense in some narrow, high value, applications.

...which should then use OTPs, no? The whole point of AES was a combination of efficiency versus security. Otherwise, just use TripleDES. Getting Rijndael in use, out on its own, is the best way to verify whether it works well -- as efficiently and as securely as desired. This is the way to gain confidence, by testing. Trust is earned. Cheers, Ed Gerck