@lood29 That is correct, assuming the same radio technology is used. Typically, you set up a separate gateway because you want to run a sensor network on a different radio family due to longer distances or similar.

@Yoshu it is possible. When you have two gateways, the networks will be completely isolated so you can run one of them secured while the other is not.
You might need to distinguish the nodes on in your controller by giving them static unique ID:s unless your controller ties the identifiers to each gateway or it might be difficult to determine which mysensors network a node belong to.

@skywatch not really, depending on the algorithm

@Puneit-Thukral yes but for full/specified function, atsha, atmega and any sensor circuitry also need to be operational at that level.

@Puneit-Thukral but will the peripherals still work at that level? No use to lower the BOD if radio/security/sensors stop working at a higher voltage.

Beautiful work 👍

@skywatch that depend on the key size you choose, and how you deploy the implementation (like block chaining and random initialization).
Symmetric ciphers are even quite secure in the quantum world given large enough key sizes.

@skywatch are you implying they recommend AES without an IV or block chaining enhancement? I don't think so ;)

@TheoL AES is not complicated to implement in hardware and the docs suggest they have it but the technical detail is low.

@alexelite they do not, however, state exactly which variant of AES they use. If they do not generate an initialization vector and are not using some block chaining variant, AES is quite weak.

@joaoabs it is not directly signing related anyway. The parent search is not signed (the NREQ messages) as it does not at that point "know" what the signing capabilities of the parent are. But Atmega328p is short on the ram when signing is used so in some situations with signing enabled combined with other features, stack might get trashed due to how the tool chain manages ram VS stack. Typically if ram usage crosses around 70%. But if you are at 50% or below I think signing can be ruled out as a factor here.

@joaoabs I am not at a pc so cannot check the code but it looks like signing configuration has been altered since personalization since it prints TAMPERED.

@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.

@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 I don't remember actually but just greping on the define should reveal that.

@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".

@172pilot no, and this is why I have advocated signing over encryption. Signing gives entropy, authenticity and replay protection. It does not give obfuscation but the need for that is lower in my opinion than the other three. Yes, someone could sniff what states your locks are in, but they can also just try the handle to achieve the same thing.

@172pilot without a chip, the key for signing (and encryption) is entirely unprotected. So if your kode is stolen, it is trivial to extract it. And since it is shared on the network, that network is completely compromised until you change the key on all nodes that rely on it (which would be all in the network if encryption is used). Furthermore, in the case of encryption, the signing chip is not involved, so the encryption key is never physically protected.
So signing (with a atsha chip) is the only fully protected communication mechanism.

@NeverDie I would say that combined with signing (preferably hw based) the security solution should be good enough for personal use.
As always, with open source projects, deploying to sensitive environments are every person's own responsibility. To me the biggest issue with the existing signing solution is ease of use and efficiency. Removing the need for personalization and allowing less handshaking would be a good thing. A concept for this can be seen in the github issues tagged with security v3 but alas, time is not a luxury I have for this in recent years. Kids, house and so on takes its toll.
But technically, sha256 and hmac are still strong algorithms. But the shared static key is my biggest concern (which would be solved by ecdh key exchange).

@NeverDie well, post quantum cryptography is already a reality so the introduction of quantum technology won't prevent secrets staying secret if you so desire. But in most cases, the effort of breaking modern algorithms will still be so high it won't be readily doable since if the solution is designed clever enough, timeouts will be involved that force an attacker to derive the necessary keys in a limited time frame which require significant computing power.