Skip to main content

Is safe to use AES-256 to encrypt data with small variations? [Resolved]

I have two nodes that need to communicate, A is sending data to B. We just assume that AES-256 key is already shared across the nodes.

The only data being sent from A to B are a few bytes commanding a light bulb:

  1. Light ON: 08 09 0A 01 [8 byte counter]
  2. Light OFF: 08 09 0A 00 [8 byte counter]

Now, to protect the communication against replay attacks, I have appended that counter which is being incremented with step by 1 every time a command is sent.

The whole packet including the counter is being encrypted with AES-256 using the shared secret key and then it is being send to B.

Is this kind of protocol safe to be used in practice? Assuming that the attacker can see the encrypted traffic and its effect (light ON/OFF), is there any chance that he can generate a new valid command/string given that he don't posses AES key?

Later clarification:

  1. The counter will never be repeated.

  2. A potential bad actor knows everything about my system except private key used to encrypt the string that I am writing on the wires.

  3. Node B will only accept commands only if the counter is incremented in respect to the last one received.

  4. We assume that implementation is ok.

  5. I don't want to append a MAC or a random nonce to the packet. I only want to keep the packet as it is.

Question Credit: caffeine
Question Reference
Asked September 10, 2019
Tags: aes
Posted Under: Security
3 Answers

Is safe to use AES-256 to encrypt data with small variations?

In principle, yes. In fact, the construction used in CTR mode depends on this being secure -- it encrypts a series of sequential values to generate pseudorandom data.

In practice, there is a usability issue with the protocol you are describing. If a message is lost or corrupted in transit, the counter on the transmitter will get ahead of the expected value on the receiver, preventing any further messages from being processed. Consider using a rolling code protocol to account for this possibility.

credit: duskwuff
Answered September 10, 2019

I introduce you to Kerckhoffs's principle. A system is only safe if it is safe even if everything is known about the system (except the encryption keys).

If an attacker can see the traffic, knows how you issue commands, and knows that you added a counter, then yes, an attack can issue commands. An attack can simply recreate the commands and guess at the counter value.

So, your answer has nothing to do with AES. Your overall design is prone to unauthorised commands.

credit: schroeder
Answered September 10, 2019

I'd suggest AES-256 CBC. Even if a predictable counter is used, it would be non breakable. Each time you would generate a new IV. But you say you don't want to use random part. If you agree to generate IV, then AES-256 CBC can be a good solution.

credit: mentallurg
Answered September 10, 2019
Your Answer