Can I reuse a nonce to retransmit the same packet using ChaCha20-Poly1305?

Question

I understand the "sudden death" implications of reusing a nonce with ChaCha20-poly1305, but I believe this rule doesn't apply if you are transmitting exactly the same packet.

I'm putting together a small radio protocol where packets can be lost and if an ack isn't received the packet is re-transmitted. In this instance the nonce is reused, but I can't see that an attacker has any more useful information than the initial packet. I would presume that the key is still safe. Is this correct or have I missed something obvious?

EDIT:

It is a custom protocol, based on a resource requirement that prevents going with something like 6LoWPAN.

I was not going to use random nonces, but rather sequential nonces, with the top 32 bits of the 96 bit nonce set to the 32 bit node address that the packet comes from. The problem with this is reliably storing the nonce in flash with limited erase / write cycles. Although I have seen implementations save blocks of nonces, rather than every use.

I can gather entropy from concatenating the lowest bit of multiple reads of the signal strength from the radio, but I would guess that sequential nonces are safer to use, if I can guarantee they are sequential.

I was thinking of using a network registration method where the node, on power up, would have a preshared RX encryption key, but no TX encryption key. The node would ask for network registration where a master node (server) would send a new TX key encrypted and authenticated. If correctly received the new node would use the new TX key and the nonce would start again from 0. This would get around the problem of storing the nonce at the expense of a slight delay in network registration. This network is only designed to be local to a single site, all nodes within reception of each other.

Answer 1

I understand the "sudden death" implications of reusing a nonce with ChaCha20-poly1305, but I believe this rule doesn't apply if you are transmitting exactly the same packet.

There are two aspects to consider here: (a) confidentiality (can an adversary find out anything about the content of the plaintexts) and (b) authenticity (can an adversary forge packets). On the confidentiality front you're unquestionably right. A passive eavesdropper doesn't learn anything new about the plaintext from seeing the same ciphertext twice.

On the authenticity front I think it's trickier, and no verdict should be reached without careful analysis. It's safe to say that authenticating the same message twice with the same nonce doesn't allow the adversary to easily forge any other message, so you're certainly not violating the authenticated cipher's rules. But you do need to think about how this fits in the bigger picture—the protocol level above the cipher level. I would ask myself, for example, whether there are scenarios where an active adversary could defeat some security property by replaying a packet they've eavesdropped on a second time, or suppressing the reception of packets and then feeding them to the recipient out of order.

Protocol design is tricky. Authenticating individual messages doesn't automatically guarantee authenticity of a sequence of interactive session of messages.

Answer 2

packets can be lost and if an ack isn't received the packet is re-transmitted. In this instance the nonce is reused, but I can't see that an attacker has any more useful information than the initial packet.

Correct. Retransmitting the exact same bytes is trivially fine. This happens all the time in practice in other protocols, e.g., when running TLS over TCP (where TCP will retransmit dropped packages.)

In fact, the nonce is not even "reused". Strictly speaking, it's "nonce reuse" if you call the encryption function twice with the same key and the same nonce. But reusing the output of the encryption function is totally fine.

I tend to disagree with Luis' answer. Sure, protocol design is very tricky, and the security of the entire protocol will depend on all of its components. In particular, you need to ensure that there are no replay attacks, i.e., the recipient shouldn't believe the sender intended to send the same message twice when when receiving the same encrypted packet twice. However, this needs to be ensured independently of whether an honest sender will retransmit packets: even if the an honest sender won't retransmit, an active attacker can feed a package twice to the recipient, and the protocol needs to handle this.