difference between encryption with personalization and simple password

[Anduril]

Hey there,

is there any significant difference between the two options for encryption? Does the simple one consumes more flash? Is it safe to use with OTA updates (should be, as all communication is encrypted)? Why should you bother with personalization in the first place or is it only the 'old grown' method?

Thanks for any contribution in advance,
Anduril

[TRS-80]

I see you have been here quite longer than me (2015) so perhaps you are well beyond what I am about to mention, but I could not help but notice you mentioned encryption and not signing, and my understanding is the project have decided that signing is probably more important than encryption?

Further, I have yet to implement any of that myself (although I am sure I will get to it "one day") so again I could really just be not fully understanding the implications of your question due to lack of knowledge.

[mfalkvidd]

@Anduril could you expand on what 2 options you are referring to?

[Anticimex]

@Anduril for encryption, the difference is not significant. With personalization, the key is stored in flash/eeprom and without it is defined in your sketch. So, if you personalize, you can publish your sketch without worrying about being compromised. And encryption works transparently with the OTA solution, IF the software that implement OTA is aware of the encryption scheme. That is, the software that configures the radio (in some solutions that is the bootloader) need to configure the appropriate key to the radio hw or driver (depending on radio).
For bootloader based OTA that require personalization unless you recompile the bootloader with the encryption key and make it configure the radio accordingly.

[Anduril]

@mfalkvidd I mean the two options #define MY_ENCRYPTION_SIMPLE_PASSWD and #define MY_RFM69_ENABLE_ENCRYPTION (with personalization before)

@Anticimex thank you for your answer. In my case I want to implement OTA with the online version with DualOptibootloader. This way, the node will be able to decrypt and store the new firmware in external flash. With the MYS Bootloader that would not be possible as far as I understood the thing...

@TRS-80 signing will also be added. But I want to be able to send messages unseen from the 'public' to my nodes... some of them are text-based and I don't want to be sniffed...

[TRS-80]

^ Well, there is the man, right there (Anticimex). ^

You are in much better hands now, I will go back to trying to follow along and learn, as most of that reply still went over my head.

[Anticimex]

@TRS-80 well thanks the condensed answer is, use personalization if you can, as that is more private than the simple password flag. And if you plan to use OTA, dualoptiboot is the safest approach to leverage mysensors library features such as signing and encryption.

[Anduril]

@Anticimex is there a way to use both methods in one network? So to personalize nodes with the AES key (0x12; 0x34; 0x56; 0x00;...) and use SIMPLE_PASSWD "123456" (or some other derivativ)?

[Anticimex]

@Anduril yes that should be possible. Just make sure that the nodes that are personalized are configured with the same settings the simple flag enable "under the hood".

[Anduril]

wow... to be honest I didn't expected it to be so easy... what flags are those "under the hood" settings?

[Anticimex]

@Anduril I don't remember actually but just greping on the define should reveal that.

[SuperNinja]

@Anduril said in difference between encryption with personalization and simple password:

#define MY_RFM69_ENABLE_ENCRYPTION

@Anticimex
Interesting, I'm going to make a remote control for my gate with an RFM69HCW, obviously I don't want the signal to be sniffed and copied.

I am new to MySensors, Is :

#define MY_RFM69_ENABLE_ENCRYPTION
#define MY_SECURITY_SIMPLE_PASSWD "testpass"

is simply enough?
What to add if not secure enough?

[Anticimex]

@SuperNinja if memory serves me, you only need the simple flag. You can read more in the doxygen site: https://www.mysensors.org/apidocs/group__SecuritySettingGrpPub.html

[Anduril]

@SuperNinja you only need #define MY_SECURITY_SIMPLE_PASSWD "testpass". The other one would be needed for encryption wih personalization (so keys saved in eeprom or atsha-chip)

@Anticimex is there a way to give the SIMPLE_PASSWD in hex? As far as I understand the AES key in the personalizer sketch is a hex and the password in sketch would be ASCII. Therefor even if looking identical they would not match. Or do I have to create a password first and convert that to hex to be used in personalization...

[Anticimex]

@Anduril I do not thing there is a limitation as long as the value of the define is in legal c code initializer format. The preprocessor will "paste" your define where it is mentioned so you can search the code for it to see where it is used. I do not recall there being any logic that assume ascii in the define.

[evb]

In the past, I did several tests about signing and encryption.
The results and my thoughts, you can find them here: https://forum.mysensors.org/topic/10382/security-signing-messages-and-encryption-of-messages-a-guide-or-more-a-summary-of-my-tests?_=1604220215583
Maybe it can help

[SuperNinja]

@Anticimex , @Anduril Thanks for this response
@evb great job, here is an easy to understand summary for beginners like me. Thanks