question for devs, aes source code

I was looking at this aes source code.
https://tls.mbed.org/aes-source-code
It is the implementation used in TLS.
Scroll down to the key schedule section of the code and the switch.
Its been a while since I did any coding and im a little hazy on the -> operator so please correct me if I am reading this wrong.

ctx is the context meaning 128, 192 or 256?
nr is the number of rounds
so into the switch, if we are using aes 256 it is going to switch to case 14 ?
14 rounds being the correct number of rounds for aes 256
but in case 14, the for loop is only 7 iterations, not 14.

aes 128, which should have 10 rounds should switch to case 10 and the case 10 for loop does have 10 iterations?

 

Code:

typedef struct
{
   int nr;                     /*!<  number of rounds  */
   uint32_t *rk;               /*!<  AES round keys    */
   uint32_t buf[68];           /*!<  unaligned data    */
}
mbedtls_aes_context;

this is the type of ctx. Given that ctx is just a pointer code is using "->" instead of . (dot) to access a member of struct.

I am not a C/C++ developer nor cryptographer, but I also think there are only 7 iterations. However body of for loop looks different. I guess one iteration of loop == 2 rounds, but it is only a guess. I am not familiar of how AES algorithm works internally.


If still in doubt, use debugger.

Given that I am not a C/C++ developer I would also like that somebody could explain this code further.

Edit:
Here is a code for current LibreSSL implementation of AES:
https://cvsweb.openbsd.org/cgi-bin/....c?rev=1.13&content-type=text/x-cvsweb-markup

Code:

/* This should be a hidden type, but EVP requires that the size be known */
struct aes_key_st {
    unsigned int rd_key[4 *(AES_MAXNR + 1)];
    int rounds;
};
typedef struct aes_key_st AES_KEY;

Code:

    if (bits == 128)
        key->rounds = 10;
    else if (bits == 192)
        key->rounds = 12;
    else
        key->rounds = 14;

 

@RockLobster The for loop does indeed go through 7 iterations (0-6), but the operations seem to be performed twice within the loop compared to case 10. Case 12 however seems to do it a little differently. Not being intimately familiar with the code nor the operations performed however, I cannot say for certain whether the code adheres to the AES specification.

Code:

 case 14:

            for( i = 0; i < 7; i++, RK += 8 )
            {
                RK[8]  = RK[0] ^ RCON[i] ^
                ( (uint32_t) FSb[ ( RK[7] >>  8 ) & 0xFF ]       ) ^
                ( (uint32_t) FSb[ ( RK[7] >> 16 ) & 0xFF ] <<  8 ) ^
                ( (uint32_t) FSb[ ( RK[7] >> 24 ) & 0xFF ] << 16 ) ^
                ( (uint32_t) FSb[ ( RK[7]       ) & 0xFF ] << 24 );

                RK[9]  = RK[1] ^ RK[8];
                RK[10] = RK[2] ^ RK[9];
                RK[11] = RK[3] ^ RK[10];

                RK[12] = RK[4] ^
                ( (uint32_t) FSb[ ( RK[11]       ) & 0xFF ]       ) ^
                ( (uint32_t) FSb[ ( RK[11] >>  8 ) & 0xFF ] <<  8 ) ^
                ( (uint32_t) FSb[ ( RK[11] >> 16 ) & 0xFF ] << 16 ) ^
                ( (uint32_t) FSb[ ( RK[11] >> 24 ) & 0xFF ] << 24 );

                RK[13] = RK[5] ^ RK[12];
                RK[14] = RK[6] ^ RK[13];
                RK[15] = RK[7] ^ RK[14];
            }
            break;

 

Hmmmm encryption source code is way up there when it comes to complexity that's for sure.
I have coded some curve fitting algorithms for statistical analysis, I thought that was difficult but it has nothing on this encryption voodoo.