So I have been reading this book called "Implementing SSL/TLS using Cryptography and PKI" While going through it, this snippet of code got me baffled

    static void compute_key_schedule ( 
    const unsigned char *key, int key_length, unsigned char w[ ][ 4 ] ) { 
    int i; int key_words = key_length >> 2; 
    unsigned char rcon = 0x01; // First, copy the key directly into the key schedule 
    memcpy( w, key, key_length ); 
    for ( i = key_words; i < 4 * ( key_words + 7 ); i++ ) { 
        memcpy( w[ i ], w[ i - 1 ], 4 ); 
        if ( !( i % key_words ) ) { 
            rot_word( w[ i ] ); 
            sub_word( w[ i ] ); 
            if ( !( i % 36 ) ) { 
                rcon = 0x1b; 
            w[ i ][ 0 ] ^= rcon; 
            rcon <<= 1; 
        else if ( ( key_words > 6 ) && ( ( i % key_words ) == 4 ) ) { 
            sub_word( w[ i ] ); 
        w[ i ][ 0 ] ^= w[ i - key_words ][ 0 ];
        w[ i ][ 1 ] ^= w[ i - key_words ][ 1 ];
        w[ i ][ 2 ] ^= w[ i - key_words ][ 2 ]; 
        w[ i ][ 3 ] ^= w[ i - key_words ][ 3 ]; 

The text says that in case of 128-bit key, round constant is shifted every 4 iterations (of forming single word of key for key schedule), making up total of 10 shifts, but at 8th shift, the round constant would be 0, and AES mandates that whenever it overflows, you should XOR it with 0x1b. So I get it that's why we did that if (i%36) rcon = 0x1b It makes sense, but if key_length is 192-bit, it would be problematic, since at iteration 36, it will pass the check if ( ! ( i % key_words)) and would proceed to change rcon to 0x1b, though there won't be any overflow at all! (I believe that key would be 0x10 at that time this shift will occur in case of 192-bit).

So it just doesn't makes sense to me and I wanted to know if there is something I am missing out on. At first I thought maybe it's necessary to rotate it every 4 iteration irrespective of key size but reading text and reading rest of code, I don't think that was an intention ever. Thanks a lot!

  • $\begingroup$ @fgrieu I am not very good with terminology so I didn't consult the official standards documentations, I will surely do in future as I learn more and more. So, is if((!(i%36)) && (key_words == 4)) enough to get it running well? $\endgroup$ Commented Mar 24, 2020 at 12:50

1 Answer 1


The question's code works for AES-128 and AES-256, but indeed does not for AES-192, for the reason pointed in the question.

Yes changing if ( !( i % 36 ) ) into if((!(i%36)) && (key_words == 4)) as suggested in comment by the OP is enough to make it (and the rest of the code) pass the example of appendix A.2 and C.2 of FIPS 197 (as well as A.1, A.3, C.1, C.3).

Reminds me of the book Security for Computer Networks by D.W. Davies (not the same Davies) and W.L. Price (May 1987 edition), which has a typo in the last constant for S4 of DES, causing failures for some test vectors. That drove me nuts for a while in the late 1980s. From that point on I implemented crypto on the basis of the standards.

  • 1
    $\begingroup$ Not that that always helps if you're too early, the first official Skein test vectors had a bug as well :) Actually, I send them the second set of test vectors before they released them (they were understandably a bit twitchy about that). $\endgroup$
    – Maarten Bodewes
    Commented Mar 24, 2020 at 16:12
  • 1
    $\begingroup$ I would like to add that, during my Ms.C. my advisor gave me a book published by Birkhäuser. When I start to read, I was lost. When I had contacted to my advisor and showed the mistakes I'd found they did not believe that the Birkhäuser can publish such a book. Sorry, Birkhäuser, I don't remember the book, give me your list of the book I can found it. So the lesson, don't trust any source, validate all claims. Always look for the errata when you by a book. $\endgroup$
    – kelalaka
    Commented Mar 24, 2020 at 17:58
  • $\begingroup$ Although there are (SSL/)TLS ciphersuites using AES-128 and 256 but none using 192, so for that purpose this code works. But if you're going to depend on horrible hacks like that you absolutely should comment them. $\endgroup$ Commented Mar 25, 2020 at 2:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.