Why is the AES traces different simpleAES/mbedtls


I am currently working on a project with CTR, i’ve implemented this with mbedtls. I saw in the thread " Setting up an AES-256 with CTR mode" that it is two different implementations of AES in TINYAES128C and mbedtls? How can this be, my believes was that AES was the same anyways.

When I run ecb with mbedtls I get this trace:

But if i run with TINYAES128C I get this trace:

Why aren’t they exactly the same, both should be running AES-128 with ecb.

Also, do you now why the mbedtls traces seems to be “unpredictable”, the TINYAES128C seems more legitimate.

1 Like

Great post, I would like to ask another relatable question.

Is there any way to get a similar trace like this

with MBEDTLS, so one can see the different rounds of AES working in the trace? Or is this just only possible with TINYAES128C?

If possible with MBEDTLS, how??

1 Like

MBEDTLS and TINYAES are both legitimate. The reason TINYAES and MBED look so different is that
TINYAES uses a simple, 8-bit only implementation, while MBEDTLS uses 32-bit lookup tables (called T-Tables) to speed up execution. Both implementations are exactly as valid and both can be broken with a CPA attack.

Ahh I see.

But is it possible to perform an attack with CTR-mode with AES-128 and AES-256, in the same way as in Lab 2_1 - CPA on 32bit AES(which was done with ECB-mode), i.e.

just using these cwa-functions?

And exactly what do I need to do in order to do so?

1 Like

If it is not possible to do it with the inbuilt chipwhisperer library, do you have any recommendations for us to be able to do the side channel analysis on AES-CTR?

Tried a bunch of stuff without any success so far.

Best regards,

The counter+nonce is the same as the plaintext in the ECB mode, so if you’ve got that, you can attack the same as a normal CPA attack with the counter+nonce replacing the plaintext. The normal sbox leakage model works for both TINYAES and MBEDTLS, so if your attacks haven’t worked using that leakage model, there’s probably something else wrong in your setup. Have you verified that the cipher is operating correctly (i.e. do you get the same ciphertext if you use pycryptodome for the encryption)?


Attacking CTR is possible with ChipWhisperer. I don’t think there would by any dedicated software for attacking CTR, as the block cipher itself is the same. The only thing an attack really cares about is that you know what’s being fed into the block cipher (or, depending on the attack, what’s coming out).

If you look at the various modes of operation on this page: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#CBC, the only thing that matters is the arrow going into or out of the block cipher.

Thank you.

I changed the ecb mode to take in nonce and counter instead of plaintext. Since it is only the last byte that is changing because of the counter I am only able to retrieve one byte of the master key with CPA.

You can see this here when preforming the attack:

How can I be able to get the full key?

Best regards,

Hi Fridthoy,

Sorry, that wasn’t something I had considered. You’ll need to attack the encryption from the other end,
so you’ll need both the plaintext and the ciphertext. I’ve only quickly skimmed it, but I think you
can also try implementing this attack: https://tches.iacr.org/index.php/TCHES/article/view/8392/7776, since it should just be the normal AES-CTR situation with an unknown nonce.


1 Like

Thank you for the help!

I was able to implement side channel analysis on CTR now and I was able to get the master key. I am now trying to implement AES256, I have been able to calculate round key 1 and round key 2. Is it possible to use this to get the full 32 byte key? Or do I need the 14 round key and 13 round witch are done in the tutorials?

When using 32 byte key I am able to extract the 16 byte key with just the normal setup as you probably know. Would appreciate some help to get on the right tracks.

Best regards,