Start using IV in AES encryption?
-
As for compatibility, there is no worries. Any development is done on the development branch which is currently so volatile that the next major release will be 2.0.0.
As for the IV, is this something that needs to be handshaked, or is it just part of the encrypted payload?
Code should use the MAX_PAYLOAD to determine the permitted size of a payload (signing backend also uses MAX_MESSAGE_LENGTH as it claims all available message space).
If encryption (RF24 variant that is) is used, I think it should just adjust these definitions accordingly to accommodate for the IV. However, in doing so, IV will be put last in the RF payload and will not be signature covered (if signing is used) so some more logic will be needed in the signing backends to handle that. But as there is a preprocessor definition indicating if RF24 encryption is used, I see no big technical challenge in handling it.
I don't unfortunately have the time to do that myself at the moment however. But I will gladly review any code in due course and give feedback. I try to limit my focus to signing and leave encryption up to others :) -
The IV is sent in clear text. No handshake needed. However, the IV is supposed to be 64 bits and stealing 8 bytes from the signature would weaken the signature significantly, wouldn't it?
If signing isn't enabled, sending the IV isn't much of a problem I think. There should be enough headroom to just add it as you suggest.
If signing is enabled, maybe we ca re-use the nonce as IV. The nonce is already there, and it is authenticated, so we might as well re-use it. I'd have to read up on the signing protocol first though.
I totally agree with prioritizing signing higher than encryption. Encryption isn't on top of my priority list either. I just thought I'd start the discussion since I found a problem. In the end, we might very well agree to leave encryption as it is until someone is interested enough to dig further.
-
Using the nonce is an option then. But it should then only be used if a message is successfully validated using that nonce. And I suppose after that be cached for encryption use since not all messages are signed, but all are encrypted.
-
And if it is static, it can just be done during an init phase, right? So it should then not steal any more payload after that. Or does it have to be part of every message, and unique for every message?
-
I think it can be done in the init phase. (See https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_.28CBC.29 - the IV is only used for the first block.)
However, the gateway would then need to remember the state for all nodes. If a packet is lost, the encryption/decryption get of of sync. If the gateway or a node is restated without saving+loading the state to/from reliable storage, the encryption/decryption gets out of sync. I think it can be done, but it will require some thinking.The current implementation avoids having to keep state by starting from zero for each packet. That's also what's lowering the security.
-
Hm. Wonder how rf69 solves that. By always including IV in the payload?
-
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.
