When working with the aes_decrypt example, I compared the results of directly invoking the aes_ecb code (not the encrypted bitmap output, which has an unencrypted BMP file header) against other available implementations, including OpenSSL. After accounting for the standard issues (mostly padding), the results still differed.
After tracing some lightweight implementations and the one provided in the aes_decrypt tree, I discovered that the implementation there assumed that the state matrix is in row major order, so ShiftRows and MixColumns were doing precisely that. However, the state matrix for AES defined to e in column-major order, so ShiftRows and MixColumns were in fact "ShiftColumns" and "MixRows".
The simplest way of correcting this would be to modify the code for ShiftRows and MixColumns so that they operates on a transposed matrix. Thus, the code should be corrected so that operations that act on rows of the state matrix should instead act on the columns of the row-major order matrix that the C/OpenCL code is operating on.
I will be submitting a pull request that contains a fix for this issue.
Hello!
When working with the aes_decrypt example, I compared the results of directly invoking the aes_ecb code (not the encrypted bitmap output, which has an unencrypted BMP file header) against other available implementations, including OpenSSL. After accounting for the standard issues (mostly padding), the results still differed.
After tracing some lightweight implementations and the one provided in the aes_decrypt tree, I discovered that the implementation there assumed that the state matrix is in row major order, so
ShiftRowsandMixColumnswere doing precisely that. However, the state matrix for AES defined to e in column-major order, soShiftRowsandMixColumnswere in fact "ShiftColumns" and "MixRows".The simplest way of correcting this would be to modify the code for
ShiftRowsandMixColumnsso that they operates on a transposed matrix. Thus, the code should be corrected so that operations that act on rows of the state matrix should instead act on the columns of the row-major order matrix that the C/OpenCL code is operating on.I will be submitting a pull request that contains a fix for this issue.