Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I am looking into an article about 32bit CPU/MCU software implementation of AES and there are some weird changes over there. Like shift-rows. It seems that the shift-rows in the 32bit implementation is shift columns instead.
So my guess is that the 32bit implementation returns different output than the 8bit implementation (the original).
Can you correct me ? or at least explain why it is still equal ?
The article : "Efficient Software Implementation of AES on 32-Bit Platforms"
So my guess is that the 32bit implementation returns different output than the 8bit implementation (the original). Can you correct me ? or at least explain why it is still equal ?
Of course, it's equal. The AES function (for a specific plaintext, key) is well defined; and if you generate any other result, you're not doing AES correctly.
Of course, while processing, the implementation may decide to lay things out in a different order than what you might naively expect; as long as it generates the same final output, all is well (and, in fact, that is what they did)
It seems that the shift rows in the 32bit implementation is shift columns instead.
No, in their implementation, they decided to lay the 4x4 matrix in memory so that a 32 bit value contains the 4 bytes in a specific row (and not a column). That is, the matrix is 'transposed' compared to the representation you would normally expect. This means that a 'shift row' operation involves rotate operations within the individual 32 bit values (or three of them; the top one remains unchanged), and that the 'mix columns' operation involves logical operations over all 4 32 bit row values.
They did that because doing that made things somewhat more efficient for them than the alternative ordering. As long as they handle the plaintext->matrix, the matrix->ciphertext operations correctly, and the transpose the key schedule bytes appropriately, everything works precisely as expected. At every point, the bytes in their transposed state are precisely the same model as the corresponding bytes in the (nontransposed) AES state.
