1
$\begingroup$

When I want to use encryption only for challenge-response exchange and not for hiding the contents of an encrypted message, is it still a threat to me not changing IV for new encryption?

For easier understanding why I ask this here is my situation:

I'm using two Arduinos with LoRa transceivers to communicate with each other. One is a bridge connected to the internet and the other is connected to servos and sensors.

I don't care if the potential attacker knows that some packet is for example rotating servo to right and another packet is sending data from the humidity sensor to the bridge.

The only thing I care for is that attacker cannot imitate any of these commands so he can't spin my servos and send bad values that don't come from my humidity sensor.

That's why I use challenge-response exchange so that I can verify if my bridge sent the packet and etc.

But there is no way (at least one I know of) for me to exchange IV to the other Arduino, so it can decode the challenge.

My questions are:

Can not changing the IV be in my case somehow exploited? If yes. How and what it means for me?

Is there any better way to do it?

Improve this question
$\endgroup$
4
  • $\begingroup$ CBC-MAC is fine for fixed size messages. You can bring it down to 64 bits if you may run out of space. $\endgroup$
    – Maarten Bodewes ♦
    Nov 11, 2021 at 23:55
  • $\begingroup$ IV is not exchanged, IV is generated locally then transmitted with the ciphertext, usually as $IV|Ciphertext|AuthenticanTag$. IF you don't care that the attacker knows your data, maybe you need only integrity and authentication. You can use simply the HMAC. Keep in mind that the replay attacks might be possible in your case. $\endgroup$
    – kelalaka
    Nov 11, 2021 at 23:56
  • 2
    $\begingroup$ HMAC is supported out of the box it seems, with a recent library. But for CBC-MAC you'll need the legacy CBC mode implementation (and do bit-padding yourself). It might be faster though, it depends a lot on implementation detail. HMAC-SHA-1 should be speedy and secure enough for most purposes. $\endgroup$
    – Maarten Bodewes ♦
    Nov 12, 2021 at 0:07
  • $\begingroup$ And, the more detail of the IV reuse catastrophe of AES/GCM is here $\endgroup$
    – kelalaka
    Nov 12, 2021 at 19:13

1 Answer 1

Reset to default
3
$\begingroup$

You must change the IV every time.

It has been noted in various places (see for example Joux "Authentication Failures in NIST version of GCM" section 3) that a single repeated IV is very likely to give an a attacker the ability to compute authentication tags for themselves. Together with the malleability of counter mode, if the attacker knows the XOR of two responses and the authenticated encryption of one they would then freely be able to forge the other.

As noted in the comments, keyed HMAC provides a very good alternative. A simple challenge response exchange might be:

  • Bridge: "I wish to give you an instruction"
  • Servo: nonce
  • Bridge: command,HMAC(Secret key,nonce|command)

Servo checks the HMAC value against its own computation and, if they are equal, executes the command. Provided that the servo does not repeat nonces and key remains secret, this should work. The nonces can even be from a counter (provided that the counter cannot be forced to repeat).

Improve this answer
$\endgroup$
1
  • $\begingroup$ Well, actually, a zero IV can be used for a long time with deterministic construction provided that there is no system crush. NIST already suggests this type of usage. Still risky for OP and GCM has many pitfalls, the HMAC is better to be used since it has lets pitfalls. $\endgroup$
    – kelalaka
    Nov 12, 2021 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.