how to decrypt AES-ECB-Nopadding data?

RE: how to decrypt AES-ECB-Nopadding data?

endnode — Wed, 03 Jun 2015 20:16:59 GMT

Hi Dave, hitting limit for simple comment so I'm amending my answer above. Please read it. Cheers Jan

RE: how to decrypt AES-ECB-Nopadding data?

Dave_couling — Wed, 03 Jun 2015 18:16:52 GMT

So if I call nrf_ecb_crypt ( uint8_t * dst, const uint8_t * src ) with cleantext it will encrypt.

If I call this function again with the same Key and using the encrypted data, it should return the original cleantext data no?

RE: how to decrypt AES-ECB-Nopadding data?

endnode — Wed, 03 Jun 2015 07:49:08 GMT

Hi both, I've thought it's crystal clear in provided link but in case it's not: NO, there is no AES decryption function in Nordic SDK (because there is no HW acceleration for it on nRF51 chip). The SDK documentation is confusing when mentioning word "decrypt" but if you go deeper you see that there is actually no way how call this decrypt functionality.

Cheers Jan

RE: how to decrypt AES-ECB-Nopadding data?

Dave_couling — Wed, 03 Jun 2015 00:55:40 GMT

I second this question

RE: how to decrypt AES-ECB-Nopadding data?

endnode — Thu, 16 Apr 2015 09:08:35 GMT

Oh, it was definitely not clear that you are asking about decryption of packets captured by Nordic BLE Sniffer in Wireshark. Just quickly looking into "nRF_Sniffer_User_Guide_v1.1.pdf" and there is pretty clear how you should proceed in all 3 cases ("Just Works", "Passkey" or "OOB" mode). Am I missing something? Or are you using some applicative AES encryption and you wish to have it decrypted on the fly in Wireshark?

Cheers Jan

RE: how to decrypt AES-ECB-Nopadding data?

Milan — Thu, 16 Apr 2015 04:45:07 GMT

I have captured data in wireshark. Data are encrypted using AES/ECB/NO-PADDING. I know the key then how to decrypt them?

RE: how to decrypt AES-ECB-Nopadding data?

endnode — Tue, 31 Mar 2015 13:16:35 GMT

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

RE: how to decrypt AES-ECB-Nopadding data?

Milan — Tue, 31 Mar 2015 12:38:26 GMT

I read following in the documentation:

bool nrf_ecb_crypt ( uint8_t * dst, const uint8_t * src )

Encrypt/decrypt 16-byte data using current key.

The function avoids unnecessary copying of data if the point to the correct locations in the ECB data structure.

Parameters dst Result of encryption/decryption. 16 bytes will be written. src Source with 16-byte data to be encrypted/decrypted.

Return values true If the encryption operation completed. false If the encryption operation did not complete.

if I set key using " nrf_ecb_set_key" function, provide AES ECB encrypted data in "src", will "nrf_ecb_crypt" function decrypt it in "dst"?

RE: how to decrypt AES-ECB-Nopadding data?

Alex — Tue, 31 Mar 2015 07:41:27 GMT

This should help you devzone.nordicsemi.com/.../

RE: how to decrypt AES-ECB-Nopadding data?

Bouke — Tue, 31 Mar 2015 07:35:22 GMT

Can you link to the question that you don't understand? What did you try yourself? Where do you get stuck?