Slashdot must be broken. This was posted two hours ago yet there is no fanatical ranting.

I thought this was a very insightful comment so I sort of cross posted it with attribution to Schneier's blog. No mod points because I have bad karma. :(

http://www.schneier.com/blog/archives/2009/07/another_new_aes.html#c387128

Granted, but Threefish would not be "AES version 2" for use as a general purpose block cipher by NIST. Although as you imply it's sort of standardized indirectly. Still though, 90% of the folks out there that just go with the latest buzz words, trends and standards would not jump for Threefish unless it were standardized specifically for use as a general purpose block cipher by NIST or some other big standards body.

Sorry.. to clarify my own post I said the second stated option for short term fixes would be to create a Double AES standard that "doubles up the key size and per block passes". That was actually partially incorrect; the proposal was to double up the AES passes with a single key, e.g. C = AES(K,AES(K,P)) to encrypt P to C.

http://www.schneier.com/blog/archives/2009/07/another_new_aes.html#c386973

Schneier directly referenced this comment in answering the question at the BlackHat talk.

Small correction; 14 rounds are specified in the AES-256 standard, not 12.

http://en.wikipedia.org/wiki/AES-256

Schneier was asked about this at BlackHat and talked about it further at DefCon.. so I will clarify a few things that are inaccurate/incomplete in the original submitter's story since I was at both..

The new attack is only "completely practical" in the sense that it has a 2^40 complexity for 10 rounds, but... similarly to the other papers it is a related key attack. Related key attacks are almost never applicable to the real world. The only case that I can think of where a related key attack was used in a real attack on a crypto system were the old WEP attacks. See Wikipedia for details: http://en.wikipedia.org/wiki/Related_key_attack

Also don't forget that 10 rounds are less than 14, 14 being the standard for AES-256.

Schneier shed some light in the BlackHat talk on why AES-256 is ironically now considered more secure than AES-128. The new attack builds off weaknesses in the key schedule which is apparently the same for AES-128, 192 and 256. The key schedule seems "good enough" for 128 and potentially 192 bits but when you get to 256 bits there is simply not enough "churning" going on. This will be a great case study for proving "more bits != better" in the future.

So if you have to use AES use the 128 or 192-bit key lengths. This attack does not prove AES is insecure but rather only that the key schedule of AES is not good enough for it's longer key lengths. It certainly does cast AES in a negative light though and could be a premonition of a practical real world break sometime in the future.

Schneier also commented that there are two possible fixes:

1) NIST could amend the standard to "AES-1" or something (similar to SHA -> SHA-1) and apply a very simple quick fix by significantly increasing the number of rounds. Schneier commented that this was probably the easiest and most reliable fix.

2) Similar to Triple DES we could create a Double AES standard which doubles up the key size and per block passes. Schneier commented that he thinks that this _might_ be a good idea but also said that he might change his mind later.

Schneier was also asked in the BlackHat talk when the next AES competition would start and amusingly responded that if you called up NIST and asked them that they would probably hang up on you (because they are so busy with SHA-3 right now). So definitely not until after 2012 when the SHA-3 competition ends at the very soonest.

Or more constructively you could avoid dogmatic thinking like what you described, and arrive at a logical conclusion based on the facts. Java has serious portability problems of it's own (not claiming that's the solution you are referring to). Even beyond the write once debug everywhere debacle, I am told JVMs on certain platforms have such performance problems as to make them unusable for many tasks.

My point is simply that no language will ever be completely interoperable, stable or secure. Based on wide consensus though, I think it is pretty well accepted that C#/.NET is one of the best thought out and implemented managed languages that exist today. Of course if interoperability is your primary concern then C# isn't your language of choice, but there are many other criteria you are ignoring.