2

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.

Improve this question
6
  • I'm seeing an X/Y problem here. It's a big knot of different controls and suggestions that starts getting away from the title question pretty quickly.
    – schroeder ♦
    Commented Sep 6, 2019 at 15:03
  • 1
    Ok, let's back up a little. Is AES-256 safe from what? What are you wanting AES to protect you from?
    – schroeder ♦
    Commented Sep 6, 2019 at 15:08
  • It would be trivial for an attacker to add a counter and guess what the next value would be.
    – schroeder ♦
    Commented Sep 6, 2019 at 15:11
  • Agree. Safe from what? If you are saying can an active bad actor generate a valid encrypted string, without knowledge of the shared secret, that once decrypted will have the next sequence number.... then no, assuming you’ve implemented aes and the counter is encrypted with the bytes correctly. I.e your software can’t be exploited through some other method. If the counter is sent clear text then yes it’s potentially exploitable
    – ISMSDEV
    Commented Sep 6, 2019 at 15:31
  • @ISMSDEV: this was exactly the question: if an actor having all the information except private key can actually generate a new valid encrypted string. In other words, only the one who have the key will be able to generate a new encrypted string. It means that there is authencity. Am I right?
    – caffeine
    Commented Sep 9, 2019 at 7:49

3 Answers 3

Reset to default
3

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.

Improve this answer
2

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.

Improve this answer
5
  • 1
    It should be added that encryption is primarily aimed at protecting content secrecy, not authenticity. A signed cleartext provides no secrecy, but perfect authenticity protection. There's schemes that achieves both, but AES' aim is not authenticity.
    – vidarlo
    Commented Sep 6, 2019 at 16:55
  • How can the attacker issue commands without knowing the key? The protocol should fit in one 128 bit block, and the counter is sufficiently large that it'd be unlikely to repeat itself.
    – Steve Sether
    Commented Sep 7, 2019 at 1:19
  • This is exactly the question: assuming that attacker have all the details except secret key, will he be able to issue new commands, again, without having the private AES key?
    – caffeine
    Commented Sep 9, 2019 at 7:41
  • 1
    @all: I think what everyone were missing is that I am encrypting those sommand before sending them to the other side.
    – caffeine
    Commented Sep 9, 2019 at 8:27
  • @caffeine, as Schroeder points out, encryption does not provide authentication. Yes, an attacker will be able to issue new commands, even if by accident, without knowing the key. Encryption only provides secrecy. Instead, consider that you can send it unencrypted with a signed message that includes your nonce and provide the authentication and resistance to replay attacks. Depending on the threat model, you could probably get away with a very simple HMAC.
    – Ghedipunk
    Commented Sep 9, 2019 at 20:36
-1

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.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .