I upgraded the firmware RAK3172 from RUI3_5_3 to RUI4_0_6. I now get an error when using AT+ENCKEY=1122334455667788 AT+PARAM_ERROR
The latest AT COMMAND indicates 8 HEX characters (16 characters).
Has this command changed? Why is this generating an in error RUI4_0_6?
Does it requires 16 HEX characters (32 characters) ?
Thank you
Welcome back to the forum @frank_r
Actually this is a bug fix. In older RUI3 versions the encryption key was only 8 bytes long, but the encryption algorithm requires 16 bytes. The bug inside RUI3 was that the 8 bytes were just used twice to get the 16 bytes.
Since RUI3 V4.0.6 this is fixed and now you have to give a full 16 byte encryption key.
Documentation needs still to be updated, but it is already mentioned in the changelog
This is worth a reminder – and a congrats to the RUI3 team. The bugs I had identified last year in the AES implementation have been finally fixed, and it has TWO implications:
• The key length is 16 bytes – the implementation was using 8, repeated… 
– so you need to pass 16 bytes in code or 32 hex bytes in the AT firmware.
• The AES implementation is AES-CBC. Which means it requires a new IV every time. The fixed IV has been removed and you have to supply it yourself with service_lora_p2p_set_crypto_IV or AT+PIV. Do NOT reuse the same IV. Set a new one every time you want to encrypt something. The reason to remove the fixed IV was exactly that: it is an egregious breach to reuse an IV, as it defeats the very purpose of an IV.
I am producing a patch for the service_lora_p2p.* files to help with that and add a layer of protection. And a good practices tutorial.
Thanks Bernd,
That’s what I thought.
Its funny that this bug permeated for so long, since the beginning.
I’m really glad for this bug fix.
Yes that’s I thought that it needed 16 bytes for the full encryption key.
Regards,
Frank
