@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.
@NeverDie it is generally the view that because something is not easily understood by the general public, it does need securing. In other terms; security by obscurity.
To secure something properly, you need to view things from a more paranoid standpoint, assuming someone will actively try to bypass any mechanism put in place to prevent it. And always assume these mechanisms will be constantly challenged. The best approach (in my opinion) is to have as little obfuscation as possible and have the mindset that "even if you can access almost everything, you still cannot hack it".
@NeverDie in security engineering it is all about being ahead of the curve. Alas, personally I have not had the time to evolve the security solution further beyond the draft state as seen on github.
@NeverDie remember that mysensors encryption has a static IV so it is repeatable. Two identical messages will also be identical when encrypted. And therefore subject to replay attacks. Only when combined with signing do you get decent grade security.
@sundberg84 Hi, I'm not using level converters becuse I use a ProMini with 3,3V (with W5100 and rfm69hw).
Maybe I have a small clue: The Interrupt Pin is high all the time. It seems that the interrupt request from the RFM Module is not processed. I cant see interrupts when I start a node. (With a working setup with ESP8266 and RFM69, the pin is low most of the time except when new packets arrive from a sensor).
@sundberg84
It does not work for me with softspi too. Although the debug output does not look that bad..
MCO:BGN:INIT GW,CP=RPNGA---,FQ=16,REL=255,VER=2.3.2<\n>
4 TSM:INIT<\n>
5 TSF:WUR:MS=0<\n>
8 TSM:INIT:TSP OK<\n>
10 TSM:INIT:GW MODE<\n>
12 TSM:READY:ID=0,PAR=0,DIS=0<\n>
14 MCO:REG:NOT NEEDED<\n>
577 GWT:TIN:IP=192.168.178.203<\n>
1581 MCO:BGN:STP<\n>
1583 MCO:BGN:INIT OK,TSP=1<\n>
1585 TSM:READY:NWD REQ<\n>
Hello,
thank you scalz for the very good clarification.
@sundberg84 I can confirm that it does compile with the #define MY_RFM69_NEW_DRIVER option. AFAIK Arduino changed the way setDataMode should be called (see links in first post). I'm not a SW-Expert but I think Someone would have to change the coresponding SoftSPI calls in the old RFM69 (old) driver if you want to use it. I currently use an ATMega2560+W5100+NRF24PA with SoftSPI which is working (but I do not know with which Arduino Verison it was compiled).
I will go with the new driver. I think it takes some time until I really do the change in HW, because I have to change several productive nodes. As we have big heat at the moment and my lab is under the roof my motivation is currently not that high... 
