Talk:AES key schedule

message: 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 .  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)
replies: text:  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)
thread_title: Alternate keyschedule

message: 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)
replies: text: 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)
thread_title: Expert needed

message: 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)
thread_title: Details on how to calculate rcon 

message: 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)
replies: text: 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)
thread_title:  Lies about rcon 

message: 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 rconi/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:
 Key expansion for AES-256 (N=8)
Round	Words                            	Words          	Words          	Words
1    	W0 = K0                          	W1 = K1        	W2 = K2        	W3 = K3
2    	W4 = K4                          	W5 = K5        	W6 = K6        	W7 = K7
3    	W8 = W0 ⊕ Sub(Rot(W7)) ⊕ rcon1   	W9 = W1 ⊕ W8   	W10 = W2 ⊕ W9  	W11 = W3 ⊕ W10
4    	W12 = W4 ⊕ Sub(W11)              	W13 = W5 ⊕ W12 	W14 = W6 ⊕ W13 	W15 = W7 ⊕ W14
5    	W16 = W8 ⊕ Sub(Rot(W15)) ⊕ rcon2 	W17 = W9 ⊕ W16 	W18 = W10 ⊕ W17	W19 = W11 ⊕ W18
6    	W20 = W12 ⊕ Sub(W19)             	W21 = W13 ⊕ W20	W22 = W14 ⊕ W21	W23 = W15 ⊕ W22
7    	W24 = W16 ⊕ Sub(Rot(W23)) ⊕ rcon3	W25 = W17 ⊕ W24	W26 = W18 ⊕ W25	W27 = W19 ⊕ W26
8    	W28 = W20 ⊕ Sub(W27)             	W29 = W21 ⊕ W28	W30 = W22 ⊕ W29	W31 = W23 ⊕ W30
9    	... ⊕ rcon4                      	...            	...            	...
10   	...                              	...            	...            	...
11   	... ⊕ rcon5                      	...            	...            	...
12   	...                              	...            	...            	...
13   	... ⊕ rcon6                      	...            	...            	...
14   	...                              	...            	...            	...
15   	... ⊕ rcon7                      	...            	...            	...
✌Boudewijntalk 12:31, 11 April 2023 (UTC)
thread_title:  Larger keys use ''fewer'' round constants, despite requiring ''more'' rounds 

message: 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)
thread_title: Confusing rcon Description

message: 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)
thread_title:  Clarification needed under key schedule description