This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Cryptography: Computer science Low‑importance This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography Low This article has been rated as Low-importance on the importance scale. This article is supported by WikiProject Computer science (assessed as Low-importance).

If I understand correctly, you can, instead of expanding a 128 bit key using the supplied algorithm, fill the whole keyschedule with random bytes and there will be no reduction in security. Then your channel for distributing the whole key will need to be large enough to distribute the whole keyschedule. -- Nroets 6 July 2005 19:56 (UTC)

Yes, this will give more security. However, I don't think one is going to get more than 300 bits or so of security for 10-round 128-bit Rijndael, since extensions of the square attack and what not can probably break this Rijndael variant with less than 2 ^ 1408 (the number of bits in a 10-round expanded key) work [1]. Also, this Rijndael variant is insecure when used as the compression function for a cryptographic hashing algorithm (I don't have a reference handy, alas) Samboy 7 July 2005 02:23 (UTC)

Well, yes. That's effectively a one-time pad, as far as I know. SoulSkorpion 10:49, 23 April 2006 (UTC)[reply]

Not if you used the same key schedule for each block you encrypt. Using a random key schedule would not weaken the security, but it's not at all clear how much it would increase it. For instance, doing the same for DES buys you very little extra security against differential cryptanalysis (something like 64 bits instead of 56, iirc). — Matt Crypto 12:25, 23 April 2006 (UTC)[reply]

hey, I'm not sure what I'm doing here. I don't have enough time to check how this wikipedia syntax work so, I'm really sorry if I made any mess around here. I have a easy-and-commented C code on AES. If you happen to see this message and would like to have a copy of the code let me know. Perhaps it would be handy to put parts here and there. my e-mail address is savio.sena gmail.com, feel free to send message any time.

I've added an Expert tag because the last edit by 124.243.132.148 on 23:20, 1 September 2006 changed the text vectors. I'm not sure what to do about that. Can anyone verify which version is correct?--agr 23:46, 4 September 2006 (UTC)[reply]

Done. Check out my Rijndael Key Schedule article (which is what this article is derived from; yes I did GFDL my contributions to the article and all that). Samboy 17:57, 16 December 2006 (UTC)[reply]

I'm trying to figure out the rcon operation and how to implement it. As far as I've understood it all you have to do is take a number i and do a 1 SHL (254 + i) modulo 283 (0x11B) Right? So I've written some code do that for me:

int rcon(int i) {

   int runs =  i + 254;
   int current = 1;
   int devisor = 0x11B;
   for (int k = 1; k < runs; k++)
   {
       current = current << 1;            
       if (current >= devisor) 
          current = current % devisor;
   }
   return current;

}

I'm not getting the rcon(1) = 1 at all here so please tell me what I'm misunderstanding/doing wrong here...

I might be completely misunderstanding rcon, but I was using this Java code: (modExp is a method for calculating modular exponentiation; in this case, (x ^ (254+1)) mod xnum

public int rcon(int i, int x) {

int xnum = (int)(Math.pow(x, 8) + Math.pow(x, 4) + Math.pow(x, 3) + x + 1);

return modExp(x, 254+i, xnum);

}

Humanperson0 (talk) 22:50, 14 February 2009 (UTC)[reply]

Removing sentences that says only rcon[1] to rcon[7] are need because they are incorrect. For 128 bit each round uses an additional rcon (so up to rcon[10]) is needed. Additional bits need even more. Acolombi 01:07, 30 August 2007 (UTC)[reply]

So what is the needed range? The Rijndael reference C implementation rijndael-dos-refc for the AES submission, in file boxes-ref.dat, has an rcon table that has 30 entries. Cmcqueen1975 (talk) 01:42, 15 January 2008 (UTC)[reply]

I removed step 4 of the key schedule description because it was redundant with step 3. Humanperson0 (talk) 22:51, 14 February 2009 (UTC)[reply]

Indeed, if you have more rounds you will NEED to have a higher rcon number. I don't know who thought it should be smaller, but that is completely wrong. It isn't even logical. Whoever posted this should have just asked themself the simple question "If I'm doing more rounds of something, does more require a bigger number or a smaller number? Obviously, quite logically, 'more' requires 'bigger'." and after thinking this to themself should have refrained from posting this blatantly wrong information. As for how much bigger for each increase in key size, I'm not 100% certain, but I believe that for a 192 bit key it requires rcon[11], and for a 256 bit key it requires rcon[12]. Until somebody can confirm exactly what the correct rcon numbers are for keys bigger than 128, I'm going to completely remove the currently posted rcon numbers for the 192 and 256 bit keys, as whatever the correct number is, it certainly is NOT what is currently posted. Benhut1 (talk) 12:29, 6 January 2016 (UTC)[reply]

There's a lot of confusion about why you need fewer round constants at larger key sizes, and the current article doesn't explain this well.

AES-256 uses 15 rounds instead of 11, so it seems you also need more round constants.

However, the value of rcon_i/N increases every N words (at multiples of the key size), not per round (which is always 4 words).

I partially worked out a table for AES-256:

✌Boudewijn^talk 12:31, 11 April 2023 (UTC)[reply]

Computing rcon is described as both 2^(i+254) and 2^(i-1). Are these equivalent? Wouldn't i-1 and i+255 be equivalent? This may be me misunderstanding finite fields. —Preceding unsigned comment added by 173.70.42.150 (talk) 14:36, 17 May 2010 (UTC)[reply]

The key schedule has one unclear point. Under point 3.1.2, "We assign the value of the previous four bytes in the expanded key to t", what are the "previous four bytes"? Initially, we only have the original 16, 24 or 32 byte key. Does it mean the four most significant bytes or least significant bytes or something entirely different? Some matrix notation or a diagram could also be useful in explaining the line "We exclusive-OR t with the four-byte block n bytes before the new expanded key. This becomes the next 4 bytes in the expanded key", because that is unclear as well 83.94.24.33 (talk) 13:13, 1 March 2017 (UTC)Someone who needs a more clear description.[reply]