RE: [PATCH] tipc: prevent GCM nonce reuse on peer key changes

[Tung Quang Nguyen]

>Subject: [PATCH] tipc: prevent GCM nonce reuse on peer key changes
>
>TIPC can encrypt traffic between nodes using a different transmit key for each
>node. In this mode, the AES-GCM nonce for a packet sent to a known peer
>consists of a 32-bit prefix (a per-key salt XOR the peer's
>address) followed by a 64-bit counter. That counter is stored in the peer's RX
>crypto object. When the peer reports a change in which key it uses to receive
>packets, TIPC resets this counter. The sender can still be using the same TX key
>and salt, so subsequent packets reuse earlier nonces. This nonce reuse breaks
>confidentiality and exposes GCM's authentication key. This makes forgeries
>trivial: an attacker can exploit CTR malleability to alter captured ciphertexts
>and use the recovered authentication key to compute a valid tag for the
>modified ciphertext, under the same key and nonce.
>
>Use the TX key's existing aead->seqno counter instead. All encryptions using
>that key object share the same atomic counter, so concurrent encryptions get
>distinct nonce counter values. The counter survives key activation and peer
>reconnection, and peer key-status reports cannot reset it. This prevents those
>transitions from causing nonce reuse while the same TX key remains installed.
>
>The nonce format is unchanged, and receivers do not require consecutive
>counter values, so sharing the counter across peers remains compatible with
>existing receivers. A pre-existing check still invokes key revocation in the
>unlikely event that the counter wraps to zero.
>
>Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
>Assisted-by: LLM
>Signed-off-by: Jérémy Jean <Jeremy.Jean@xxxxxxxxxxxxxxxxx>
>

Next time, please add 'net' to [PATCH] for bug fix.

Reviewed-by: Tung Nguyen <tung.quang.nguyen@xxxxxxxx>