XSL attack on AES
Sep. 17th, 2002 04:18 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ciphergothYou may have heard of a new attack on AES which substantially reduces the security it offers. Here's my reaction.
This was going to be a comment in![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
skx's journal but it got a bit long. I've heard of this attack for a while, but it's been hard to tell if it's the Real Thing; I've basically been waiting to hear what people like Schneier (who really understand Rijndael cryptanalysis very well) think of this attack.
As far as practical purposes go, AES and Serpent are still unbreakable - we'd have to imagine alien computing technology to describe details of how one might implement such an attack. And we should still rely on it to be secure. It's counterintuitive but generally true that a system designed to offer some security in the case that the cryptographic primitives are weak is often, perhaps usually, less secure than one that depends much harder on the strength of its primitives but is much simpler; with professionally designed ciphers, even "broken" ones, complexity is generally a much greater enemy of security than cryptanalysis.
I think I would still recommend AES with 256-bit keys for new applications. At the last AES panel before they made a decision on which cipher to choose, Schneier said that if Rijndael was chosen, it should be extended to 18 cryptographic rounds for a larger "safety margin"; when it was chosen without the extra rounds, he predicted that a that a theoretical attack against AES would be found within five years. But he then went on to emphasise that he still thought it was a good choice and that people should use it, because he thought that a practical attack was much less likely.
It's interesting to note that the Serpent team warned about a scenario exactly like this in their closing summary for why Serpent should be chosen: they said that they were confident that no practical attack would ever be found against any of the Final Five, but that if a theoretical attack was found, it would bring the standard into disrepute and cause panic. Of course, they (and everyone else) thought that Serpent's enormous safety margins meant that even a theoretical attack would be impossible.
On the other hand, NIST might decide to open a new competition because of possible bad publicity coming from this attack, which would certainly be exciting; I don't know enough about how standards bodies behave to make a guess on this one. In some ways, I hope they do, but that they give the community longer this time. A great deal was learned about block cipher cryptography and cryptanalysis during the AES process, and we could use that knowledge to build a better cipher this time around. I know of at least one design decision in AES that the authors wished they'd done differently to make it more efficient in hardware.
This was going to be a comment in
skx's journal but it got a bit long. I've heard of this attack for a while, but it's been hard to tell if it's the Real Thing; I've basically been waiting to hear what people like Schneier (who really understand Rijndael cryptanalysis very well) think of this attack.As far as practical purposes go, AES and Serpent are still unbreakable - we'd have to imagine alien computing technology to describe details of how one might implement such an attack. And we should still rely on it to be secure. It's counterintuitive but generally true that a system designed to offer some security in the case that the cryptographic primitives are weak is often, perhaps usually, less secure than one that depends much harder on the strength of its primitives but is much simpler; with professionally designed ciphers, even "broken" ones, complexity is generally a much greater enemy of security than cryptanalysis.
I think I would still recommend AES with 256-bit keys for new applications. At the last AES panel before they made a decision on which cipher to choose, Schneier said that if Rijndael was chosen, it should be extended to 18 cryptographic rounds for a larger "safety margin"; when it was chosen without the extra rounds, he predicted that a that a theoretical attack against AES would be found within five years. But he then went on to emphasise that he still thought it was a good choice and that people should use it, because he thought that a practical attack was much less likely.
It's interesting to note that the Serpent team warned about a scenario exactly like this in their closing summary for why Serpent should be chosen: they said that they were confident that no practical attack would ever be found against any of the Final Five, but that if a theoretical attack was found, it would bring the standard into disrepute and cause panic. Of course, they (and everyone else) thought that Serpent's enormous safety margins meant that even a theoretical attack would be impossible.
On the other hand, NIST might decide to open a new competition because of possible bad publicity coming from this attack, which would certainly be exciting; I don't know enough about how standards bodies behave to make a guess on this one. In some ways, I hope they do, but that they give the community longer this time. A great deal was learned about block cipher cryptography and cryptanalysis during the AES process, and we could use that knowledge to build a better cipher this time around. I know of at least one design decision in AES that the authors wished they'd done differently to make it more efficient in hardware.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2002-09-18 03:05 am (UTC)no subject
Date: 2002-09-18 08:47 am (UTC)Maybe they should have a goal of setting a new algorithm 10 years after announcing Rijndael, and treat it like a normal replacement the way AES replaced DES? If they start the process now, they could give cryptographers more than 18 months to develop an algorithm meeting their specification. Remember that when the call for candidates went out, there were *no* existing ciphers that met NIST's spec, and precious few 128-bit block ciphers - practically all the new ciphers being invented were 64-bit block ciphers.
It would be especially good if they called for a tweakable block cipher, of course!
no subject
Date: 2002-09-18 09:17 am (UTC)