Start using IV in AES encryption?
-
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.
-
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.
-
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...
-
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.