This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
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)
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)
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...
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)
I removed step 4 of the key schedule description because it was redundant with step 3. Humanperson0 ( talk) 22:51, 14 February 2009 (UTC)
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)
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:
Round | 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 | ... | ... | ... |
✌ Boudewijn talk 12:31, 11 April 2023 (UTC)
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)
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.