Talk:Advanced Encryption Standard

From Wikipedia, the free encyclopedia

WikiProject on Cryptography This article is part of WikiProject Cryptography, an attempt to build a comprehensive and detailed guide to cryptography on Wikipedia. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks.
WikiReader Cryptography It is intended that this article be included in WikiReader Cryptography, a WikiReader on the topic of cryptography. Help and comments for improving this article would be especially welcome. A tool for coordinating the editing and review of these articles is the daily article box.
To-do list for Advanced Encryption Standard: edit · history · watch · refresh

None listed.
Priority 3  

Contents

[edit] what doubts? what experts?

The article says 'some experts doubt that it is really as secure as it should be for important applications'.

Which experts?

-- The Anome

Bruce Schneier and Rich Schroeppel are two who come to mind. A few others seem to have vague doubts. I should point out that Rijndael has not actually been broken, and in fact it has been proven mathematically that some of the more popular methods can't break it. The main worry is that the whole thing looks too simple, and has more algebraic structure than is normal for a block cipher. There is a possibility that some new kind of algebraic attack might exist.

If you trawl through the AES website, you can find the public comments, and quite a few there thought Rijndael was too simple. (Note that not all the comments are by experts though :-) When the final choice was announced, Schneier said

"I believe that within the next five years someone will discover an academic attack against Rijndael. I do not believe that anyone will ever discover an attack that will allow someone to read Rijndael traffic. So while I have serious academic reservations about Rijndael, I do not have any engineering reservations about Rijndael."

which is not the most ringing endorsement you could hope for.

I have seen a draft of a paper by Ferguson, Schroeppel and Whiting, pointing out all sorts of interesting algebraic properties of Rijndael, of a kind that make some people nervous, but without actually finding a break. Not sure if they managed to get it published yet, or if so where.

So my statement in the article might be just slightly too strong as it is, but we should probably convey somehow that not all the experts find Rijndael completely convincing.

When did Bruce Schneier raise doubts about AES? Is there a published paper about this that you can point me to? To my knowledge, Schneier even recommends AES to be used instead of his very own Blowfish in new designs, despite the fact that, to date, there are no known vulnerabilities to the Blowfish. --K1 11:14, 21 Jun 2004 (UTC)
Ferguson and Schneier are cool about the algorithm in Practical Cryptography (2003), if I remember correctly. I'll try and look it up. — Matt 12:55, 21 Jun 2004 (UTC)
p56: "We have one criticism of AES: we don't quite trust the security"; p57, discussing possible algebraic cryptanalysis: "This is an extremely unfair criticism of AES. We don't have an attack on AES. And every cipher, including AES, could be attacked in the future. Yet the simple algebraic structure of AES opens it up to an entirely different class of attacks."; p58: "In the end, everybody will use AES because it is the U.S. government standard. We even advise people to use it, because it is the standard and using the standard avoids lots of discussions and problems...the aggressive design coupled with the clean algebraic structure just makes us uneasy." — Matt 13:12, 21 Jun 2004 (UTC)

[edit] more pronounciation problems

You have to say "Rhine doll" like a North American, or it is just wrong.

[edit] merge w/ Rijndael?

Would anyone object to making this article about the AES standard (i.e. a general term description, listing of the finalists, etc.) and kept all the stuff specifically about Rijndael in the Rijndael encryption algorithm article ? --Imran 02:35, 1 Feb 2004 (UTC)

Hmm...AES is now essentially synonymous with Rijndael; the a minor technical difference isn't worth having two pages (Rijndael has a wider range of block sizes specified). My suggestion would be to merge Rijndael and AES, and the discussion of the competition and other finalists can remain in AES competition. — Matt 03:32, 14 Jul 2004 (UTC)
Matt, Imran's got the right of it here, I think. AES =/= Rijndael quite. There are permitted block length differences if nothing else. That sort of thing probably doesn't belong in AES, aside from a note about the not quite exact identity of the two, but does belong in Rijndael. Reactions? ww 19:42, 14 Jul 2004 (UTC)
The difference is hairsplitting, really, and since Rijndael has been adopted as the AES, they are used synonymously in practice. I don't think it's sustainable to have two separate articles based on a small technicality when a single sentence in the lead section of AES would suffice. — Matt 20:01, 14 Jul 2004 (UTC)

[edit] "GPL license"

"GPL license" makes as much sense as "LCD display". I'll leave it to the native speakers to get rid of this "General Public License license". How about:

  • just "GPL"
  • "GPL-licensed" (if this is English ;-)
  • "GP license" or "GP License" (unfamiliar)
  • "General Public License"


80.237.206.93 02:54, 19 Jan 2005 (UTC)

Reply: Something that is commonly used is just: "Licensed under the GPL) 75.100.253.249 04:45, 12 April 2007 (UTC)

[edit] Comparison to other algorithms

This might be out of scope of the article but how does AES 256 compare to blowfish and other algorythms in issues such as encryption time, hypothetical security etc

Regarding encryption time, Rijndael was chosen as AES over a number of other candidates in part because of its good performance over a range of platforms (this should, at some stage, be explained in the AES process article). To be honest, you'd probably want to compare Twofish with AES in this regard, rather than Blowfish. Blowfish has a very complex key schedule, which means that it takes a lot of time to process the key before encryption can take place — Rijndael is faster in this respect.
No problems with the security of any of AES, Twofish or Blowfish have been established. — Matt Crypto 13:06, 14 Mar 2005 (UTC)

[edit] Other AES candidates

Mention of and comparison to other AES candidates particularly such as CAST-256, DFC, E2, LOKI97, MAGENTA, MARS, SAFER+, SERPENT, Crypton, DEAL, Frog, RC6, Twofish, and HPC would seem appropriate. For example the paper presenting results of Randomness Testing of Advanced Encryption Standard Candidate Algorithms, is one comparison that was used in making the decision. I'm sure there are many others. If someone wants to find the appropriate place to plug this information in. Phil 16:31, 9 March 2006 (UTC)

That's *all* the other AES candidates you've listed there :-). Such a discussion might be appropriate in Advanced Encryption Standard process. I don't know why you've picked that paper out in particular - at a brief glance, I'm pretty sure it must be flawed since a practical distinguisher for Twofish would be big news. — ciphergoth 17:18, 9 March 2006 (UTC)

[edit] DJB's attack

I just spent a good deal of time removing POV from DJB's cache timing attack on AES. Yes, in theory this attack can work. However, I feel strongly that, in practice, this attack isn't an issue. Samboy 22:58, 30 Apr 2005 (UTC)

[edit] More detail?

Do other editors feel it is worthwhile to describe AES in enough detail for a programmer to be able to implement Rijndael/AES without referring to any other documents. Samboy 01:39, 17 May 2005 (UTC)

OK, I'm beginning the work on this. I am doing this by creating a series of sub-articles which describe various aspects of AES' algorithm in more detail. I have already written articles on the Rijndael Galois field and Rijndael S-box. I need to write an article on Rindael's key schedule, write a Rijndael test vectors article, and a Rijndael Mix column article. Samboy 08:56, 18 May 2005 (UTC)
I agree that we should be describing the algorithm entirely. However, I'm not sure I agree on how we should best do this — in particular, I'm not sure we should be describing it from a view for implementation (as in, "here's some C code for multiplying in a Galois Field" etc). Perhaps that might be better in Wikibooks? Similarly, test vectors might be better off given within Wikisource. I think we could fit the entire description onto one page. Anyway, I'm not totally sure what I think, but I'm glad you're interested in helping improve this article ;-) — Matt Crypto 10:53, 18 May 2005 (UTC)
Thanks for the input. I agree that C examples have the following two issues:
  • They are useless to someone who doesn't know C. There are at least two different public domain implementations of C out there for people willing to work with C code.
  • They may violate the Genre of an encyclopedia. Actually, I'm hitting a similiar Genre problem with the article for Bell numbers. A lot of math articles in Wikipedia are written for people who have a BS or higher in Mathematics; however the underlying concept of a Bell number (and even a method for calculating one) is simple enough that an intelligent elementry school kid can understand what is going on if the information is presented correctly. Unlike history or a lot of social sciences, a lot more care should be made to make a given concept accessible to an average reader.
I think psudo-code will work better. In the case of multiplying two number's in AES' Galois Field, I already have psudo-code that does this (in the article, no less).
Anyway, I won't have time to address these issues until this weekend. In the meantime, I'll explain that AES can be speeded up on a 32-bit computer with 4k (or even 1k) of table space by table lookup on the main Rijndael article. Samboy 18:28, 18 May 2005 (UTC)
One thought that occurred to me: rather than integrating implementation-specific information for each component of the cipher, how about collecting it all in an "Implementation aspects" section? If it gets too large, we might consider splitting it out into an Implementation aspects of AES article. — Matt Crypto 01:25, 19 May 2005 (UTC)
That sounds like a good idea. Merges are always a good thing. The only thing is that we should move it to the Implementation aspects of AES article if this article becomes bigger than 32k. As an interesting aside, XTEA and Blowfish have faster speeds on PCs than AES does, but AES kills them on 8-bit smart cards (and, presumably, dedicated hardware; AES killed RC6 with the NSA did their hardware speed tests PDF file; I assume that XTEA and Blowfish will have similar problems). Samboy 04:49, 19 May 2005 (UTC)
I just checked; we're not even halfway to the 32k point. Samboy 09:04, 19 May 2005 (UTC)

[edit] AES standard

(Copied from User talk:Matt Crypto)

I appologise for not discussing the changes I made to the Rijndael article (Rijndael); I'm new to Wikipedia and didn't realise this was what I should/could do (plus I didnt see your comments that I should discuss this). Anyway, I suppose your right that it sounds better as "AES standard", but its still redundant. The term "GPL license" was changed on the same article (to "GPL-licensed") due to it being redundant, so I dont see why this shouldn't be. Agiain, please accept my appologies for the changes that I made. Thanks.

Thanks for dropping me a note! Almost always if there's disagreement about the content, the best thing to do is to enter into discussion, usually on the talk page (Talk:Advanced Encryption Standard) — I'll copy this here so that other editors will see it too. At least to me, the phrase the AES standard sounds better, and it's used even by NIST (the standards body that specified AES): [1]. — Matt Crypto 20:15, 21 January 2006 (UTC)

The article states "The largest publicly-known brute-force attack has been against a 64 bit RC5 key by distributed.net (finishing in 2002; Moore's Law implies that this is roughly equivalent to an attack on a 66-bit key today)." It does not say if it was against AES, when i began, how many hosts or how much processing power was used. with these details this passage means nothing. i came to this article look for something to that effect but did not find it.

[edit] Bernstein and POV

I don't think it's POV to say that Bernstein's demonstration of his timing attack was artificial - in fact, I'm sure he'd agree, since it was meant as a proof of concept. It's the thing you'd do first to demonstrate such an attack. You'd then move on to try to demonstrate it on a real protocol, or over a longer network link, or similar. That hasn't been done yet, but that's no proof that it's impossible. I think the article represented the current state of knowledge and discussion about the attack very well as it was. — ciphergoth 09:54, 6 May 2006 (UTC)

[edit] Too Technical

This article is far too technical for the average reader to understand. And it's not that it deals with technical concepts, it's that none of the concepts are remotely explained and an amazing knowledge is assumed.

☭ Zippanova 07:13, 31 May 2006 (UTC)
I agree, I went through various similar articles discussing encryption techniques and whatnoy and quickly got discouraged. —The preceding unsigned comment was added by Judmen (talk • contribs) 21:26, 8 January 2007 (UTC).

[edit] Questionable usefulness of List_of_applications_that_use_AES

There seems to be a consensus in the discussion of List_of_applications_that_use_AES that such a list is "useless and dangerous because it might lead to the mistaken conclusion that the crypto used is in itself proof that the implementation of the product is secure." I'd welcome your comments over there whether or not it should be deleted or fixed. --Ministry of Truth 07:01, 9 June 2006 (UTC)

I agree. I also note that such a list would be potentially endless. I'd vote to scrap it. Shinobu 05:20, 13 June 2006 (UTC)

[edit] Implementation Description Problem

Minor point, but I used the article to help me write an implementation in C# (and yes, I know there's one built into the .NET framework).

In the "The ShiftRows Step" Section:

"... In case of 256 bit block first row is unchanged and the shifting for second, third and fourth row is 1 byte, 2 byte and 4 byte respectively."

This demented me while trying to get the 256 bit version working. It would appear from my limited and humble studies (i'm not a cryptographer) that this is simply not true. According to the known ciphertexts for known values and keys (fips-test-vectors.txt -see this page) the algorithm only produces the known CTs when the 256-bit case is treated the same as the 128 and 192 cases. Besides, there's only 4 bytes - shifting left or right 4 places would leave the bytes in their original positions, like the first row.

--Tomcully 16:59, 13 December 2006 (UTC)

It looks like you're confusing key size and block size. Changing the key size does not change the shift row operation; changing the block size (which makes Rijndael non-AES) does. Samboy 21:53, 13 December 2006 (UTC)
Hmm, yes, you're absolutely right. Told you I wasn't a cryptographer :) Do you mind if I make a change to clarify this - the article is about AES (being a specific use of Rijndael), If there is consensus I could add a small note that the change in the ShiftRows step only applies to the general algorithm with different block sizes - and not to AES in particular. --Tomcully 11:55, 14 December 2006 (UTC)
Go ahead, change it. It's an encyclopedia that anyone can edit and all that.  :-) Samboy 02:43, 15 December 2006 (UTC)

[edit] Grouping of round steps

FIPS 197, and the book by Rijndael's designers, present the round steps in a different but equivalent way. Basically, they say AES consists of AddRoundKey, then rounds consisting of (SubBytes, ShiftRows, MixColumns, AddRoundKey), then a final round (SubBytes, ShiftRows, AddRoundKey). Might be a good idea to adopt that presentation, since it seems the more popular one. Trevp 09:47, 4 January 2007 (UTC)

[edit] Spamming

Please stop adding commercial external links to AES implementations. If they're not notable enough to have a wiki page of their own, then they're not notable enough to link to here. Tomstdenis 16:22, 24 January 2007 (UTC)

I could understand deleting all links to products in the article. Although in my opinion hardly a wise move it would be at least consistent. Tomstdenis, however, has deleted just some links to products he deems "commercial". The criterion used is very murky: a site of a company that sells products is apparently inherently bad, while the site of a person who sells services (like XySSL, http://xyssl.org/about/) is apparently OK. Tom, I would really appreciate you clarifying your selection of links to cull. As is, it simply looks like you have decided to delete all links to products that compete with the ones you work on at Elliptic. If this is indeed the case, I suggest a reversion. Dimawik 02:47, 26 January 2007 (UTC)
If the link doesn't lead to something a reader can freely access (e.g. GPL, Public Domain, BSD) then it should be removed. XySSL gives the code out under a free license. Think about it, you're linking to something that is a reference for future readers (say in 15 years time). Some product that a company keeps under a proprietary NDA license is not material appropriate for an encyclopedia. Wikipedia != Geocities. Tomstdenis 11:32, 26 January 2007 (UTC)
This is not strictly correct; please see Wikipedia:External links for the actual policy. -- intgr 12:50, 26 January 2007 (UTC)
I suggest you actually read the guidelines yourself. Under "links normally to be avoided," rules #1, #3, and #4 clearly support the edits I performed. The IPcores (and other) commercial links were neither unique nor non-commercial in nature. There are FREELY available well documented AES implementations that would better serve the target audience than a proprietary CLOSED SOURCE link. think about it. What use is a proprietary link? Thy don't give out AES source code (C, HDL, Java, whatever). Their pages only mention they sell AES modules. Well big deal. Wikipedia is not an advertisers board. Tomstdenis 13:14, 26 January 2007 (UTC)
Take no offense, I am not defending Dimawik or commercial links here. I was merely pointing out that your criteria is quite different from the actual policy; whenever debating things on Wikipedia, point out the official policy instead of your personal interpretation of it. The policy does not discriminate software links based on the license they are available under. -- intgr 13:22, 26 January 2007 (UTC)
Just in case this wasn't clear enough, I was particularly contesting your claim "If the link doesn't lead to something a reader can freely access (e.g. GPL, Public Domain, BSD) then it should be removed." -- intgr 13:29, 26 January 2007 (UTC)
I should add that I find it offensive that you think this is because I work for a competitor. I'm not putting up articles or links about my employer (and in fact haven't even mentioned their name in our debates yet). I suggest you check out http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Tom_St_Denis if you question my objectivity. I also removed other commercial AES links as part of the cleanup. Tomstdenis 11:35, 26 January 2007 (UTC)
I am sorry if I have offended you. Ummm, however, after witnessing a person who in a middle of a workday from the computer that (s)he also uses for his paid job goes on a brief Wikipedia purification quest almost entirely devoted to deleting links to the competitors of his/her employer - while keeping other product links in place - it is hard not to question this person's ulterior motive... Dimawik 15:33, 26 January 2007 (UTC)
I found the ipcores links by using the search function then removed them from the pages it turned up. If you know of other wiki-spam feel free to go about it. The fact that you bring up competition issues shows you don't get what Wikipedia is about. Also I should remind you that I have not put up pages about my company, nor do I support their creation until notability can be justified. There is no double standard here. Tomstdenis 16:30, 26 January 2007 (UTC)
Hi folks, I'm the one who added the link (check my IP). Anyway, feel free to remove it if it doesn't conform to Wikipedia's guidelines, I won't mind ^_^. This AES code is certainly not anything like a reference, it's mainly something people can use for free. If it's redundant, it should go -- there are other implementations out there (hint -- LTC ;-) —The preceding unsigned comment was added by 88.191.21.42 (talk) 21:18, 26 January 2007 (UTC).
Just to be more precise, I meant the link to the XySSL site (which has some AES source under the LGPL). —The preceding unsigned comment was added by 88.191.21.42 (talk) 21:22, 26 January 2007 (UTC).
For the record, I agree with Tom here. There are plenty of Public Domain, BSD, and (L)GPL AES implementations out there. To add commercial implementations just makes this articles more useful for one person--the commerical implementor in question listed here--and less useful for everyone else who would otherwise download a free AES implementation. Samboy 15:13, 20 June 2007 (UTC)


[edit] When You May Want a Commercial Vendor: FIPS 140

Recently I saw the comment: "There are FREELY available well documented AES implementations that would better serve the target audience than a proprietary CLOSED SOURCE link. think about it. What use is a proprietary link? Thy don't give out AES source code (C, HDL, Java, whatever)."

The short answer to the "when is a proprietary link useful" question may be tied to whether or not the code you're writing will be used for high security applications. If you're downloading an AES library to encrypt your CD collection, anyone's random free code might be fine. However, if you're looking for something to use in an application that requires FIPS 140-level security (e.g. military applications), you're usually better served embedding a component that has already been through FIPS validation (which includes a source code review). Most of these components are commercial components because it takes a lot of time and effort to qualify code to this level of fidelity.

I guess what I'd like to propose is TWO "Implementation" sections here: one for people who want to tinker with the source (the existing links) and a new "FIPS-Validated Implementations" section for those people who just need something that works and that the federal government already stands behind. (The specific AES FIPS number is "FIPS 197", as mentioned in the article, but FIPS 140 covers a wider range of cryptographic goodness...)

Make sense?

Jonathan.lampe@standardnetworks.com 19:31, 3 July 2007 (UTC)

If you need a FIPS validated AES implementation, then I'd propose that you go to NIST's web cite and look up the list of FIPS validated AES implementations. This list currently contains about 600 entries. It doesn't make sense to copy that list into wikipedia. Also, wikipedia is not a directory. So links to implementations without source code or implementations that do not distinguish themselves from the bulk of existing implementations should simply be left away. 85.2.102.22 20:44, 3 July 2007 (UTC)
I think we agree. Go back to the main article and see if what I did with the new "FIPS Validation" section accomplishes this. Jonathan.lampe@standardnetworks.com 21:26, 3 July 2007 (UTC)

[edit] Mobile

Is this implemented on any client code? I'm hoping there is a JSR in J2ME? Mathiastck 19:55, 25 May 2007 (UTC)


[edit] Alleged Break

Warren D Smith at Temple has a paper (I'm not sure if it's yet published or where) that claims to prove the existence of a constant (albeit very large constant) time attack against AES. The abstract can be found at http://www.math.temple.edu/~wds/homepage/wdsAES.abs and the full text is also available on his website.

At the very least this deserves a mention. 70.53.121.116 12:39, 7 August 2007 (UTC)

Mmm...I'd recommend we don't, for now. People can claim lots of things, and this is not the first time someone has claimed, falsely, to have broken AES (Eric Filiol, for example). If it's not published in somewhere peer-reviewed, then we should be hesitant in reporting its claims. In addition, if it has also not made any waves outside of academia, then it doesn't really satisfy notability for Wikipedia. Having skimmed the paper, I observe that it's rambling, chatty, and more than a little bit kooky; if there's any solid results in there, the author is not exactly going out of his way to establish his credibility. After making the claim that AES is "plausibly" broken, Smith states that, "we do not actually write down this cracking algorithm, and do not know what it is. We merely argue nonconstructively that it probably exists", and "In short, almost every secret key cryptosystem yet proposed is now busted or at least suspect." Let's take this one with a pinch of salt for the time being. — Matt Crypto 19:29, 7 August 2007 (UTC)

[edit] open source C++ implementation

I'd also add Botan library to the list of AES implementations in C++. Foxius 10:30, 10 August 2007 (UTC)

[edit] Randomness?

Does anyone know where information about the "randomness" of the output of AES? For example, if I were to encrypt the sequence 1,2,3,..., would the output be "random"

-Eric —Preceding unsigned comment added by 208.65.175.197 (talk) 23:06, August 28, 2007 (UTC)

If it wasn't "random", then nobody's going to use AES by now... Shin-chan01 (talk) 22:45, 21 January 2008 (UTC)

it depends on what you mean by random, if you encrypt the same message with the same key at two different ocasions you will get the same result, there is no randomness (as in using random numbers), because that would most likely result in a message that was impossible to decrypt--RichoDemus (talk) 09:48, 29 May 2008 (UTC)

Well, AES could be used as a pseudorandom number generator (see CSPRNG#Designs_based_on_cryptographic_primitives), but, as RichoDemus points out, it's not actually random random. If you could show that AES had some statistical bias in its outputs, that's more or less saying that you've found a weakness in the cipher. — Matt Crypto 18:04, 30 May 2008 (UTC)

[edit] Table look up for ShiftRows?!

I'm definitely only just learning this <disclaimer>so excuse me if I'm just being brain dead here</disclaimer>, but I can't imagine how ShiftRows can be accelerated with a look up table -- especially a byte-wise look up table (i.e. one with 256 entries). If tables truely can accelerate ShiftRows the article ought to have a reference that demonstrates this strategy in more detail. Acolombi 00:23, 30 August 2007 (UTC)

I've found that ShiftRows is not turned into a table look up. I changed the text slightly to better reflect (I hope) how this works. —Preceding unsigned comment added by 209.213.198.25 (talk) 21:00, August 30, 2007 (UTC)

[edit] cockup

under Side channel attacks it says

In October ojoooiojoijojoj9087][pl[ giklh2005

I dont know wikis so could someone fix/revert this? —Preceding unsigned comment added by 219.89.58.122 (talk) 11:23, 8 January 2008 (UTC)