Talk:Advanced Encryption Standard/Archive 1 Source: en.wikipedia.org/wiki/Talk:Advanced_Encryption_Standard/Archive_1

This is an archive of past discussions about Advanced Encryption Standard. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

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

Which experts?

— Preceding unsigned comment added by The Anome (talk • contribs) 10:29, 10 November 2001 (UTC)

---

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)

Should the fact that NSA has "approved" this code for open use give us any pause? We have all the source, and it's thus far from a black-box implementation. What I'm worried about is simply that the stakes are too high in this matter for the NSA not to have in their absolute, fundamental interest to promote a cipher that they have some sort of abyss-like knowledge of; some kind of ultra-optimized compute-cluster in the depths of the black bunker that they built specifically for this. Again, the stakes are too high not to be curious if this obvious incentive is utilized.

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)

(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.

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)

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)

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)

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)

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)

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)

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

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.orghttps://demo.azizisearch.com/lite/wikipedia/page/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)

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)

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)

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)

"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)

In no way does the use of "GPL license" negatively affect the readibility, actual or percieved quality of the page - in fact, it should aid readibility for those that are unaware of the meaning of the acronym. —Preceding unsigned comment added by 83.100.209.37 (talk) 11:30, 13 July 2008 (UTC)

Section seems to be missing the Initialization Vector for the given key and data.

Or am I missing something?

-- Dracorat (talk) 22:28, 19 September 2008 (UTC)

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)

You can fix things like this yourself, if you want, using the page history (History tab) if it was a recent change, or if you can't find it there, you can use WikiBlame. Shinobu (talk) 17:23, 28 October 2008 (UTC)

In the US and other countries, export of cryptography is controlled. It would be very helpful to give specific information about AES software in this regard, for example what is its ECCN (see [2]) and under what conditions can it be exported or reexported. Reference #2 in export of cryptography on publicly available software does not seem to apply, because the AES key length is greater than 64. Note that publishing software on the web constitutes exporting, so the implementations linked to in this article have already been exported, whether their authors are aware of it or not. CLandau (talk) 19:50, 7 December 2008 (UTC)

The article says the pronunciation is [rɛindaːl]. However, there seems to be no such symbol as ɛi in the IPA. Reference 4 ("'Rijndael' pronunciation") is currently offline. Should it be [reɪndaːl]? Isidore (talk) 17:15, 31 January 2009 (UTC)

there is no symbol "ɛi" in the ipa because ɛi is two symbols:ɛ and i.79.68.126.53 (talk) 19:51, 8 February 2009 (UTC)

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

I've started looking into this implementation, which was recommended to me personally, for use in a semi-secure (more DRM-like) implementation on the iPhone, for obfuscation of source material (html pages), and decryption in-transit: [[3]] Is this somewhat vetted code? Can someone expert in this field take a look at it? avocade 18:08, 7 March 2009 (UTC)

If you need vetted code then you might look for code that has passed the FIPS validation (links are in the article) or some other form of validation. There are several freely available implementations that have passed this program. On the other hand, if an implementation just has a link on wikipedia then this does not mean that the code satisfies any quality standards or that the code is even correct. Since anyone can edit wikipedia there are often links to poor implementations. The code that you mention looks inefficient. I wouldn't use it. 62.203.15.196 (talk) 10:32, 8 March 2009 (UTC)

I am not a cryptographic expert, so could someone please work this attack on AES 256 discussed at http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html into the article? Thanks. Jesse Viviano (talk) 03:04, 2 July 2009 (UTC)

Done. It's a related key attack with 2^119 complexity that needs something like 2^65 chosen plaintexts. This is an academic attack; the only people who would have to worry about this are people doing AES-hash with a 256-bit key size (If you don't know what that means you don't have to worry about it; Bram Cohen actually proposed this before he took over the world with BitTorrent). It may or may not affect Whirlpool; I'm not sure if Whirlpool uses a more complex key schedule. Samboy (talk) 05:15, 2 July 2009 (UTC)

See this blog post by Bruce Schneier. AES-256 is becoming dangerously close to being broken (theoretically and practically), while AES-128 is still fully secure. It is kind of ironic that the smaller key versions of AES are more secure than the larger key versions. Could some crypto expert throw this into the article if appropriate? Jesse Viviano (talk) 20:30, 30 July 2009 (UTC)

I'm not so sure the sky is falling with AES yet. Schneier was right that we would discover an academic attack against Rijndael, but I would say he is somewhat biased against Rijndael because his own Twofish did not win. The attacks being discovered may affect the security of Whirlpool, but I don't see how they affect AES' security in practical real world use. Indeed, the latest attack Schneier blogged about doesn't affect AES, but affects reduced-round versions of AES. Anyway, off my soapbox, WP:NOTAFORUM and all that. Samboy (talk) 14:36, 3 August 2009 (UTC)

I disagree on Jesse's comment: "It is kind of ironic that the smaller key versions of AES are more secure than the larger key versions". AES-256 has a key-schedule that is designed to give security with 14 rounds. AES-128 has a key-schedule that is designed to give security with 10 rounds. Even if AES-256 were practically and completely broken up to 13 rounds, this would not imply anything on the security of the full AES-256. So, assuming the blogged attacks work (I'd wait for 1) publication on a highly prestigious scientific Journal AND 2) computattional tests by third parties), we still have AES-256 with a security margin of 2^119, which is about the same as AES-128. VanceIII (talk) 11:12, 21 November 2009 (UTC)

On Cryptology ePrint Archive website there is a new report about "A Diagonal Fault Attack on the Advanced Encryption Standard" --Morte (talk) 23:24, 7 December 2009 (UTC)

The article and it's external resources don't appear to mention the procedure for encrypting ~64 bits within a 128-bit segment, such as when you are encrypting a file that doesn't have a clean number of bytes. Is there a procedure for this (preferably a documented one), or is this simply a nasal demon? --Sigma 7 (talk) 00:16, 26 May 2010 (UTC)

I think some clarification is required here. I.e., what the hell is a known-key distinguishing attack? JulesH (talk) 11:16, 20 September 2010 (UTC) I think they mean single-key.

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)

it actually is. practical implementation: Bringing Access-Based Cache Attacks http://eprint.iacr.org/2010/594.pdf —Preceding unsigned comment added by Dmitriid (talk • contribs) 09:20, 25 November 2010 (UTC)

Has anybody had a look at this?

http://arxiv.org/abs/1011.2644

Not sure whether their findings make any sense. —Preceding unsigned comment added by 80.11.75.198 (talk) 16:57, 15 December 2010 (UTC)

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

Remember to sign your comments with four of these: ~ On US and Europe keyboards they are typically located left of the 1 in the top row. If you have a European layout and ~ is a dead key it can be produced by following the keystroke with a space instead of a letter. As for your comment; replace the pronunciation with an IPA transcription if you know how. Your concern is a valid one; even regional North American dialects, like Texan and Boston, will pronounce it incorrectly. I'd fix it myself if I had the time to bother. Take a look at wp:IPA if you've got the time. 216.82.142.13 (talk) 00:52, 27 December 2010 (UTC)

Regional variations in pronunciation and/or accents are not "wrong." They are simply regional variations. See WP:PRON for a guideline on how to handle this in various situations. I just added IPA-nl pronunciation; please review and correct as needed, especially if your native language is Dutch. Guy Macon 09:40, 27 December 2010 (UTC)

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).

Explain. How could you make such a topic any less technical and still have a use? —Preceding unsigned comment added by 72.136.214.96 (talk) 17:09, 9 October 2008 (UTC)

Although I consider myself an expert, I agree that the presentation could be improved. As pointed out by 72.136.214.96, the experts would need to know precisely where the greatest technicalities are felt. VanceIII (talk) 15:40, 22 November 2009 (UTC)

The problem in part is that almost every sentence in the article is filled with undefined technical jargon. The article needs to be re-written in plain English. It's OK to use jargon, but define your terms right there in the article, rather than relying so much on links to yet other articles filled with yet more jargon. For example, compare this to the articles on U.S. Federal taxation -- a highly complex subject. The Wikipedia articles on taxation are written without most of the technical tax law jargon that would befuddle most people. Famspear (talk) 20:45, 17 December 2012 (UTC)

Example, from the article:

In the SubBytes step, each byte in the state matrix is replaced with a SubByte using an 8-bit substitution box, the Rijndael S-box. This operation provides the non-linearity in the cipher. The S-box used is derived from the multiplicative inverse over GF(2⁸), known to have good non-linearity properties. To avoid attacks based on simple algebraic properties, the S-box is constructed by combining the inverse function with an invertible affine transformation. The S-box is also chosen to avoid any fixed points (and so is a derangement), and also any opposite fixed points.

For a normal person, this passage is meaningless gobbledygook. Almost every term in this passage needs to be defined with its specific meaning as used in the context of the passage. Examples: SubByte. "State matrix". Substitution box. What does "non-linearity in the cipher" mean? I know what a multiplicative inverse is (in math) but many people probably don't remember that term. What is an "attack on a simple algrebraic property"? What is an "invertible affine transformation"? What does the phrase "to avoid any fixed points" mean? What is an "opposite fixed point"? What is such a point "opposite" to?

It's OK to use jargon, if you define your terms.

I am a tax practitioner. Suppose someone walks into my office and hands me a notice from the Internal Revenue Service, and asks me what it means. Suppose I respond by saying "Hey, this CP504 could mean that there is a 6321 lien in place, although it would not be valid as against a third party secured creditor who has perfected prior to the filing of any 6323(f) notice by the Secretary. But, hey, that's not your main problem, pal; the real problem is that you may start seeing 6331(a) action after the 6331(d)(2) period expires."

Is the average person going to know what I'm talking about? I'm being a little unfair, because even tax practitioners don't really talk this way, but I'm trying to make a point here.

As much as is reasonably practical, try to explain the subject in plain English. Famspear (talk) 21:11, 17 December 2012 (UTC)

I think the first sentence is rather misleading about where and how the look-up tables are used. The first sentence states: "On systems with 32-bit or larger words, it is possible to speed up execution of this cipher by combining the SubBytes and ShiftRows steps with the MixColumns step by transforming them into a sequence of table lookups." It also claimed that the total lookup table size was 4 kiB. A while back when I wrote my own implementation in C++, I combined the SubBytes and ShiftRows steps into a single operation, then I used the 4 kiB lookup tables to speed up the MixColumns step. The current text makes it seem like you can perform the SubBytes, ShiftRows, and MixColumns steps all at once with a 4 kiB lookup table.

I highly doubt that those three steps could be combined, but I wanted to double-check before I changed the wording in that section. If there is a way to combine SubBytes, ShiftRows, and MixColumns all in one table, I'd love to know about it, so if there is a way, please enlighten me or point me to a relevant source.

The9375 (talk) 07:14, 22 December 2012 (UTC)

I agree that something is a bit off. Would a 4Mbit table be enough to combine all 3 steps? That seems totally independent of the first paragraph in that section. And calling it a "byte-oriented approach" seems a bit odd. Skippydo (talk) 19:06, 23 December 2012 (UTC)

What is being combined in the byte oriented approach is the three steps into a single function by carefully tracking the input and output indicies through the functions. It's pertinent to low-footprint applications that need a small AES routine. The 4K tables infact combine the three round steps into a single table lookup per round. Please see the seminal paper on AES for details. karl m {{User electrical engineer}} (talk) 00:44, 24 December 2012 (UTC)

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)

AES is not Rijndael, it is possible to encrypt something with Rijndael which cannot be decrypted by AES. Not only does Rinjdael allow additional block sizes (160, 192, 224, 256), it also supports additional key lengths (160, 224) see Range of key and block lengths in Rijndael and AES. Real world implementations like in Microsoft's .Net also indicate the difference. So, while the two terms are often used interchangeably by uniformed bloggers, AES is in fact a subset of Rijndael with different uses by cryptographic professionals. If anything, the AES page should be merged into the Rijndael page as a subsection. This of course does not make sense, as the majority of people will be searching for AES and will not care at all about Rijndael. As a result I suggest separating the two pages so Rijndael has its own history, a list of differences from AES, and a link to the AES page for details on the algorithm steps.Trisped (talk) 21:48, 22 February 2013 (UTC)

This section seems to imply that on-the-fly disk-encryption software that uses AES and an invariant key is useless against an attacker who can login to the computer. That attacker could trigger an arbitrary number of encryptions using known plaintext and -- apparently -- discover the key very quickly. Is this interpretation correct? Therealdp (talk) 12:47, 5 October 2013 (UTC)

Strictly speaking, AES is the name of the standard, and the algorithm described is a (restricted) variant of Rijndael.

I don't think this is true. Bruce writes in Applied Cryptography: If the security of an algorithm is based on keeping the way that algorithm works a secret, it is a restricted algorithm. Since AES has open implementations/specifications, it is not restricted.

Pieterverberne (talk) 19:06, 16 March 2012 (UTC)

No, what it means is: Original Rijndael allowed for more different key and block sizes, than AES does. AES is only a subset of Rijndael. Rijndael does all, that AES does, but it does more. AES is Rijndael, restricted to only three key sizes (128, 192 and 256 bits) and one block size (128 bits), yielding a total of 3 AES variants, while "full" Rijndael allows both for five different key sizes (128, 160, 192, 224 and 256 bits) and five different block sizes (128, 160, 192, 224 and 256 bits), both of which can be chosen independantly, yielding a total of 25 Rijndael variants. Of these 25 variants, that Rijndael supports, only 3 are "allowed" for AES. So AES is Rijndael which has been restricted to only allow for three key sizes and one block size. 87.149.78.8 (talk) 01:23, 23 September 2014 (UTC)

From

http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html

and

https://cryptolux.org/FAQ_on_the_attacks

"Q.: Does it mean that AES-256 is weaker than AES-128?

A.: Theoretically, yes. Practically, they both still provide a comfortable level of security."

Is this well-enough established to add to the article? Some of te present language implies it, but nowhere is it clearly stated. Guy Macon 12:01, 16 December 2010 (UTC)

No, AES 256 isn't weaker than AES 128. Schneier had always been biased regarding AES, and in this case he was blogging about reduced round related key attack that has no practical implication on full AES and how it's used. By the way, that article is from 2009. It's almost 2015 now and there is no evidence AES is any weaker today, six years later. AES isn't broken. 2605:A601:754:1101:71:B640:BE58:1A38 (talk) — Preceding undated comment added 13:49, 30 December 2014 (UTC)

The article says that AES is a substitution–permutation network, but it's not made clear why: i.e., which parts form the substitution and which the permutation. The MixColumns operation in particular seems to be neither a pure substitution (it works on many bytes together) nor a pure permutation (the output bytes are not simply the input bytes in a different order, but a linear combination of the input). --Taejo|대조 12:32, 15 June 2015 (UTC)

my inquiry into this revealed that the original use of the term was that we have two phases, one is a bit-permutation and one is an s-box. but this was later widened, and now it is used more liberally. now it includes every cipher that has two phases, one linear for fast mixing, and one nonlinear because it is necessary for the whole thing to be nonlinear. in aes, the linear phase is composed of shiftrows and mixcolumns, while the nonlinear is subbytes. rather confusing. Krisztián Pintér (talk) 12:39, 17 May 2016 (UTC)

"At present, there are no known practical attacks that would allow anyone to read correctly implemented AES encrypted data." (this found in Security/Known Attacks (last sentence) First, "at present" is USELESS in a document which may be 5 or 10 (or more) years old. Remove it. Second such a claim cries out for an authoritative reference. If someone wants to find a recent (2017 or 2016) expert who claims that, then rewrite it with the date that the claim was made. Duh40.142.183.194 (talk) 23:46, 22 February 2017 (UTC)

As Wikipedia isn't a print encyclopedia, it's not a 5 or 10 year old document, so the statement that at present there are no known practical attacks does make sense. This statement follows a list of the known attacks that are better than brute force, so I could see replacing it with something like "None of these attacks are practical and so do not currently allow anyone to read correctly implemented AES encrypted data." Jbeyerl (talk) 02:18, 24 February 2017 (UTC)

The post-quantum cryptography page says that AES is resistant to quantum computer attack, and I found an 2015 article on arXiv (not read it yet) about applying Grover's algorithm to AES. [Grassl, Markus; et al. (2015). "Applying Grover's algorithm to AES: quantum resource estimates". arXiv:1512.04965. A bot will complete this citation soon. Click here to jump the queue] Does anyone who knows about Q-crytanalysis have anything more to say? Jimw338 (talk) 19:44, 18 March 2017 (UTC)

Hello fellow Wikipedians,

I have just modified 2 external links on Advanced Encryption Standard. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20071103105501/http://findarticles.com/p/articles/mi_m0IKZ/is_3_107?pnum=2&opg=90984479 to http://www.findarticles.com/p/articles/mi_m0IKZ/is_3_107?pnum=2&opg=90984479
• Added archive https://web.archive.org/web/20120905154705/http://research.microsoft.com/en-us/projects/cryptanalysis/aesbc.pdf to http://research.microsoft.com/en-us/projects/cryptanalysis/aesbc.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 19:54, 18 April 2017 (UTC)

Every wikipedia article should include a definition that a non-expert in the field can understand. The expansive introduction is nothing more than a social-political-historical background. Since AES is the most popular method a general definition should be used, but if not then at least a link to block cipher and Substitution–permutation network should be in the first sentence. At least the first paragraph of the "description" should be moved to the introduction. But even that paragraph has a big problem by using "Rijndael" in the definition. That's a problem because wikipedia redirects to this article if the hapless reader tries to look it up. Ywaz (talk) 10:47, 30 April 2017 (UTC)

Yes, and please state what type of encryption algorithm it is! I assume it's symmetric (private key) but I have to read the algorithm to figure that out. Consider what issues a user of the method would want to know before delving into the implementation details. Learjeff (talk) 19:55, 25 April 2018 (UTC)

In the following paragraph for MixColumn:

The multiplication operation is defined as: multiplication by 1 means leaving unchanged, multiplication by 2 means shifting byte to the left and multiplication by 3 means shifting to the left and then performing xor with the initial unshifted value. After shifting, a conditional xor with 0x1B should be performed if the shifted value is larger than 0xFF.

The last sentence fragment I highlighted in bold appears to be a mistake. In other implementations I've seen, the conditional xor 0x1B is performed when the value you're shifting has its left-most bit equal to 1. Or in other words when the value is >= 0x80. — Preceding unsigned comment added by 69.181.136.110 (talk) 12:41, 24 January 2012 (UTC)

It is not a mistake. You can either check the result >= 0x100 after shifting left one bit, or the operand >= 0x80 before shifting left one bit.

karl m {{User electrical engineer}} (talk) 19:09, 26 April 2018 (UTC)

I went through and cleaned up the obsolete HTML tags. I think that it is fine now. I will remove the clean up banner if no one objects. - Tystnaden (talk) 01:10, 26 February 2019 (UTC)

I looked through it. You seem to have done a thorough job. Leopoldhausen (talk) 22:57, 1 March 2019 (UTC)

Thank you. - Tystnaden (talk) 07:56, 2 March 2019 (UTC)

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)

The link is now dead. Also, any block cipher with fixed block size ${\displaystyle b}$ can be broken in constant i.e. O(1) time theoretically by using a proportionality constant that is at least ${\displaystyle 2^{b-1}}$. This is why big-O notation is essentially meaningless with regards to most block ciphers, and you instead need to calculate the number of operations on some type of abstract machine and then relate that to brute force search. Only in this way, a meaningful statement about an algorithm's merit can be made. Aragorn2 (talk) 10:59, 24 June 2019 (UTC)

http://en.wikipedia.orghttps://demo.azizisearch.com/lite/wikipedia/page/Advanced_Encryption_Standard#Libraries says: "Care should be taken when implementing AES in software. Like most encryption algorithms, Rijndael was designed on big-endian systems. For this reason, little-endian systems return correct test vector results only through considerable byte-swapping, with efficiency reduced as a result."

I've spent several hours googling and haven't found much details on the issue. Does this return different results on big vs. little endian systems?

http://74.125.113.132/search?q=cache:QzXSa4SyBKEJ:www2.mat.dtu.dk/people/Lars.R.Knudsen/papers/rijndael-statement.pdf+rijndael+AES+%22big+endian%22+%22little+endian%22&hl=en&ct=clnk&cd=2&gl=us says "Absence of arithmetic operations: the description of Rijndael does not make any (hidden)assumptions on the coding of integers as a sequence of bits. One of the advantages of thisis that Rijndael is immune for so-called big endian/little endian confusion and conversionproblems."

So does AES/rijndael return different results or run at different speeds on big vs. little endian? Are you ready for IPv6? (talk) 14:57, 13 January 2009 (UTC)

A little update on this question: All operations are byte granular (except AddRoundKey which is bitwise). If ShiftRows is implemented as a sequence of 32-bit rotations, endianness will need to be taken into account, but only the offset rsp. (equivalently) rotation direction will differ. Moreover, contemporary little endian processors of dominant vendors, starting from Intel's Westmere (2010) rsp. AMD's Jaguar architectures (2013), support AES-NI and handle any potential endianness concerns internally. Aragorn2 (talk) 11:59, 24 June 2019 (UTC)