Decrypt AES encoded payload?

Hi there,

Probably a very basic question, I’ve successfully created an Arduino Pro Mini + RFM95 node that sends data.
I used the sample here:

The payload is encrypted, but is there any way to have it decrypted on TTN directly so I can actually view the values in the data tab while testing?

E.g. a decoder function for the payload formats tab?

Thanks a lot!

Unless you’re not giving us all details, you’re wrong when thinking the data is still encrypted when using TTN Console. See Decrypting messages for dummies.

1 Like

Thank you for the reply.

I’m sending a simple string “TTT” to the gateway, and what I receive in the payload is: 8E EF 60

It’s sent here:

The only change that I did in my sketch is adjusting the keys and change


Is there anything I missed on the TTN side?
The sample uses AES encryption.

Thank you,

The answer is in the topic I linked too, so you’ll need to read that first before asking for more help.

If you still think so after reading the other topic: where’s the code for that?

1 Like

I read the topic, what exactly are you referring to?
If it would be HEX only when arriving on TTN it would be 3 times the same if I send TTT, or not?

The encryption is done here:

The sample is from:

That’s in the gateway. When looking at your device’s data in TTN Console, TTN will have decrypted for you, like explained in the other topic.

And true, the LoRaWAN libraries will encrypt (but your own sketch won’t), but TTN will decrypt for you when using TTN Console.

1 Like

I’m not sure if I follow. 8E EF 60 is in the TTN console, under the data tab.
The sketch I use uses LORA_Send_Data() as shown above, and LORA_Send_Data() as in my last message contains Encrypt_Payload().

So I assume it is encrypted (hence I do get 3 distinct values in TTN if I send “TTT”) I guess?

That’s weird. Unless the specific sketch is doing additional encryption, that should not happen when using TTN Console to administer applications and devices. I think sprintf(msg,"TTT"); should not cause that either.

Sorry, I’d use a different example then. Examples that send text are not a good start anyway, as to save bandwidth a LoRaWAN node should not send text.

When using ABP, then I guess TTN Console cannot know if the correct Application Session Key (AppSKey) was used.

For uplinks, the Message Integrity Code (MIC) is calculated using the secret Network Session Key (NwkSKey), not the AppSKey. But even when TTN determines the packet’s MIC is valid, decryption of the application payload (using the secret AppSKey) might will still silently fail when using different secrets for encryption and decryption. (So: will show different results when the AppSKey in TTN Console and the node do not match.)

You can see for yourself with your own data or an example in the “FRMPayload decrypted” part of the online decoder: just play with the AppSKey to see you’ll get different decrypted data, without any clue if the right key was used. Changing the NwkSKey will get you an error though, as for the MIC we know the expected value from the LoRaWAN packet.

So: are you sure you used the correct AppSKey in your node? See also Hex, lsb or msb?

Thanks for the pointers. I forgot to mention that I use msb - the reason being that with lsb I did not see any data at all . With msb I actually received.
However, I now saw in your link that lmic requires lsb, which is confusing as I don’t receive anything then.

Do all of the values need to be in either msb or lsb? If so I’m not sure why msb gives me data…
I’m not sure if:
is related.

I think:

  1. If you see packets in a gateway’s Traffic page then you only know it’s connected; you don’t know if the keys are okay. (Though maybe peeking into the “trace” part might give you some hints about TTN knowing the recipient.)

  2. If you see data in a device’s Data page, then the DevAddr and NwkSKey in the node are okay. And:

    • For OTAA you can then assume all keys in the device are okay.
    • For ABP, if you see the correct data, then the AppSKey is okay too. (So, all keys are okay.)
    • For ABP, if you see the wrong data then check the value for AppSKey in the node, or maybe try to revert it in the node.

I’ve now switched to this tutorial:
Here it works without problems, after re-wiring the module as outlined - must be the other lib.

Just a quick question: I read that OTAA sometimes takes longer for the initial connection. Is it better to use ABP for battery (low)powered nodes?

Thanks a lot for your help!



Thanks a lot!

1 Like

Hi Christoph,
The tutorial that you were using originally probably has a bug in the Encrypt_Payload function. The function in Encrypt_V30.cpp encrypts the payload with:
This should be:


Nice find, @Javastraat. Care to comment at ? (Otherwise I’ll copy your post there.)

Thanks for the suggestion. I just left my comment there.

Thanks a lot! I did not see that. I will check out the code and give it another try.

I’m not sure about the different libraries, some are trying to reduce power consumption, others reduce sketch size, might be outdated though as well.