4
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Of course. As long as you're re-transmitting exactly the same bytes, it's just a copy. $\endgroup$ – Awn Oct 23 '17 at 8:34
  • 1
    $\begingroup$ Microwavesafe, you may want to look at this help page to merge your accounts. $\endgroup$ – SEJPM Oct 23 '17 at 13:08
  • $\begingroup$ Related: What happens if a nonce is reused in ChaCha20-Poly1305? $\endgroup$ – e-sushi Nov 24 '17 at 16:06
  • $\begingroup$ Actually I think using a new nonce in a resend scenario would give attackers more information, at least if it can be deducted from traffic that it is a duplicate. $\endgroup$ – eckes Nov 25 '17 at 15:04
4
$\begingroup$

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.

$\endgroup$

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.