Start using IV in AES encryption?
-
Well, I was not even aware that message size decresed for rf69 in that case. But is it still >=32B? Else things would probably break for signing as it claims all area up to MAX_MESSAGE_LENGTH (unless that value also adapts)
-
Ok, good. I wonder if they just randomize the IV then and send it as part of the message. I don't see that improves security by much since anyone can listen in and obtain the same IV.
It also makes the solution stateless, but I think there should be a handshaking anyway then. But I don't really know how it should be handled without causing too much trouble. -
It does provide security. Since the IV is XORed with the plaintext before encryption, two different IVs applied to the same plaintext message will result in very different ciphertext. One bit change in the IV should flip half the bits in the ciphertext, on average. Since the attacker doesn't know the plaintext, knowing the IV is useless. That's why the IV is designed to be be sent in the clear.
-
Yes and no. Yes, it does add security. But plaintext can be predictable. Especially during node startup. So an attacker can figure out both IV and plaintext. It is the AES key that is secret and it takes some work to derive it.
-
The attacker doesn't need to figure out the IV, it is always available in plaintext in the radio message.
Yes, timing analysis at startup and other sidechannel attacks can help the attacker figure out what the plaintext is anyway. That's one of the reasons I don't care that much about encryption.
-
Same here. The only usable use for encryption I see is audio/video streams, and the mysensors protocol is suitable for neither.
-
I suggest that, unless someone else chips in in this discussion, we'll just note that the encryption has a (/one more) weakness. I might pick this up later on (it is definitely an interesting exercise), but I have projects that are more fun and useful that I prefer spending time on at the moment.
-
I share your view.
-
Well thanks for identifying the issue and a good explanation on why it is an issue.
Having read through your initial posts once more, however, I think I found a minor detail that you may have gotten wrong.
The message header also contain sender, so although you would be able to recognize ON command from a particular bode, you would not automatically know the command from other nodes as the header would differ. -
I believe the entire message is encrypted. As far as I know the physical parts of both radio are multicast, and all data transfered, that is visible in the MySensors library, is MySensors specific and used for MySensors specific routing and such.
-
No knowledge in this but i appreciate you guys (which know more) are having this discussion.
Not Mysensors, but it could be i guess - yesterday my RFLink (433mhz) told me it found a new device, a code for a on command. A quick search on the internet revealed it belong to a home alarm manufacturer which has 2 items sending 433mhz, their wireless motion detectors and a on/off remote for the alarm...
I guess I could do some damage with this...
Controller: Proxmox VM - Home Assistant
MySensors GW: Arduino Uno - W5100 Ethernet, Gw Shield Nrf24l01+ 2,4Ghz
MySensors GW: Arduino Uno - Gw Shield RFM69, 433mhz
RFLink GW - Arduino Mega + RFLink Shield, 433mhz -
No knowledge in this but i appreciate you guys (which know more) are having this discussion.
Not Mysensors, but it could be i guess - yesterday my RFLink (433mhz) told me it found a new device, a code for a on command. A quick search on the internet revealed it belong to a home alarm manufacturer which has 2 items sending 433mhz, their wireless motion detectors and a on/off remote for the alarm...
I guess I could do some damage with this...
@sundberg84 yet another example of the incompetence of security providers for private homes. They are useless.
-
I am not an expert in encryption but I really like your discussion.
I believe as you have said, signing is the most critical issue to focus on now, and also we can't neglect encryption in the future.
Thanks for your effort.
@ahmedadelhosni signing just underwent a major overhaul recently on development branch. We are also looking into a node locking mechanism when the node suspects it is under attack from someone trying to brute force a signed message or trying to predict nonces calculated from a bad rng implementation. So security is very much being looked at. And even with missing IV, AES encryption would add some obfuscation to the messages and will in combination with signing still deter a lot of potential attackers.
