Is AES-GCM safe if same key is used for both uplink and downlink, assuming last IV bit tells the direction

Question

I have designed a cryptographical protocol which uses AES-GCM with a single key.

I have gone to great lengths to ensure the same initialization vector is never reused. The first bits of the initialization vector are transported over the wire and chosen by the sender according to a very sophisticated mechanism which combines a random bit prefix (renewed with more randomness when the counter runs out, persistently stored, collisions prevented), a counter suffix (persistently stored in a safe manner in which even a power outage can't result in IV reuse), and the entire thing is XORed by a random fixed value (persistently stored).

The last IV bit tells the direction: 0 (uplink) and 1 (downlink). This is fixed, so an uplink message can't have 1 and a downlink message can't have 0, they are always validated and invalid messages are rejected. (Obviously the counter field ends in the second last bit, as the last bit is reserved for direction.)

While planning how to add ephemeral keys with key negotiation for perfect forward secrecy, it was advised in Can Curve25519 shared secret be safely truncated to half its size? that a single key shouldn't be used for both uplink and downlink.

However, if the last IV bit fixes the direction, a reflection attack shouldn't work, right? An uplink message can never be a valid downlink message and a downlink message can never be a valid uplink message, alone based on the differing last IV bit. Reusing the same key for two client or server devices obviously is discouraged and with key exchange and ephemeral keys, would be almost impossible even with invalid configuration.

Is key reuse safe in this manner, if IV bit tells the direction of the message, and this is enforced by not allowing invalid packets (in which case we don't even try to decrypt a packet with invalid IV)? Are there other reasons to avoid sharing key for uplink and downlink than IV reuse (which I prevented) and reflection attack (which I think I also have prevented by using the last IV bits as direction indicator).

Answer 1

In the end this is about validity of protected messages in a protocol rather than GCM. Even with two keys for up- and downlink, all of the keys are still shared, so it won't have much influence on key management in general.

It would be nicer if the system would reject messages even if the bit in the IV is not checked. The system of checking may be disabled by some kind of trick or bug (e.g. configuration file overwrite, swapping client and server) or simply by developer error in the future. However, there certainly are ways to mitigate the chance of this happening, such as integrating strong access control to the configuration file and documenting the code well.

But otherwise: yes, you can use symmetric keys for communicating in both directions. There aren't any cryptographic / mathematical reasons for not doing so; it's "just" against best practice. I'd file it under "comply or explain and justify".

---

Notes:

• GCM defaults to a 12 byte nonce, which is already pretty small in case a random nonce is used. Beware that using bits of the nonce does make the nonce space even smaller, which increases the chance of a collision for a specific direction.
• For developers sake I use the first rather than the last / rightmost bit for the direction. This makes it stand out from the bits in the counter, and it makes it easier to handle the counter into the remaining bits (I'm presuming you're using a big endian representation of the counter).
• Beware that keeping state such as a counter in itself is possible attack vector. Such a protocol is vulnerable if an adversary is able to reset the counter, e.g. by cycling the counter or by cycling the power to the system.