how to decrypt AES-ECB-Nopadding data?

[Milan]

Hi Team,

Can anyone help me on this?

How to decrypt AES-ECB-Nopadding Encrypted frame?

I am not getting desired output. In fact, I am not getting how to proceed in this case.

[endnode]

Hi,

Original post is not very clear from my point of view so let's summarize it:

• AES is symmetric (block) cipher which means that there is 1 shared key which is used for both encryption (ENC) and decryption (DEC).
• But ENC and DEC functions are inverse and in general these are mathematical completely different when it comes to actual computation. So NO, you cannot use the same function for going there and back unless it implements both encrypt and decrypt mode (e.g. with some flag in the call).

If I understand it correctly nRF51 HW and SD API supports encryption only. However (and this is I guess hinted in the quoted thread, but I do see it neither properly implemented nor explained) there are "modern" methods how to bypass such limitation and use another stream function which is basic XOR to make it working both ways. One example of this concept is called AES Counter (CTR) mode where you use AES encryption only to generate intermediate "stream" which is then applied with XOR (stream cipher) on clear data. And because inverse function to XOR is again XOR on the other side you do exactly the same on top of cipher text to get clear data.

Please note that while this is elegant it does not necessary mean that it is immediately secure and that you cannot screw it up during implementation (e.g. if you do not apply also integrity check by independent key/method, if you cannot guarantee unique usage off each counter with given key etc.). For details see e.g. en.wikipedia.org/.../Block_cipher_mode_of_operation or other specialized crypto articles.

Cheers Jan

Update 03-06-2015

Reaction to repeated question down this thread:

Hi Dave, you are actually incorrect in the same way Milan was. See another post with very same question and another variant of "NO" answer here: devzone.nordicsemi.com/.../ .

To make the allegory even simpler let's imagine AES encryption as basic addition ("+") mathematical function and decryption as subtraction ("-"):

• If your plane text is 3 and key is 2 then 3 + 2 = 5 (this is cipher text) and on the other side you need to use inverse function with the same key so 5 - 2 = 3 (which is correctly decrypted clear text).
• Here on nRF51 chip you have only one of these functions (encryption) and trying to reverse the inputs will not help you (putting cipher text 5 to the encryption function will make 5 + 2 = 7 which is definitely not your clear text 3).
• Yes, documentation to the API might be misleading on the first look but after digesting this there is pretty much no way how to help you.
• And yes, there exists "cryptographic" functions where encryption and decryption are mathematically identical functions (e.g. XOR) but that's very rare and definitely not the case of AES.
• Of course you can implement proper AES DEC function (there are plenty of open source examples - starting with reference code in the spec up to some optimized versions in ASM). However you will probably experience much slower processing then ENC which is in HW.

Cheers Jan