Talk:Rijndael key schedule

From Wikipedia, the free encyclopedia

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)

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)

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.

[edit] Expert needed

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)

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)

[edit] Details on how to calculate rcon

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

[edit] Lies about rcon

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)

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)