3
$\begingroup$

I'm building a low power wireless network and need to transmit very small packets at regular intervals (10 bytes every minute or so). In order to secure the communications I'm considering using Chacha20 and a pre-shared key.

The problem I have is communicating the IV. I could just broadcast it at the start of each message, but that results in almost doubling the message length and therefor the power usage during transmission.

I considered agreeing upon a method of calculating the IV (i.e. using the transmitter address as a nonce and a simple transmitted packet counter) but this gets risky if messages are dropped for any reason.

Before I go down the path of defining an ad hoc method of solving this issue I thought I'd ask and see if anyone has solved it previously and what recommendations you all had.

My fall back method is to use the address to generate a nonce, then use a packet counter and transmit only the lowest order byte. This adds only a single byte to the message length and allows me to theoretically miss 255 messages and still 'resync' packet counters. Not as robust as I'd like but better than anything else I've come up with myself.

Improve this question
$\endgroup$
6
  • $\begingroup$ I would consider using either unbalanced Feistel or swap-or-not, so that the nonce is part of the PRP's input. ​ ​ $\endgroup$
    – user991
    Commented Sep 14, 2016 at 6:16
  • 1
    $\begingroup$ Do you have an accurate clock on both ends? You could use the current time rounded to some predetermined precision and enforce that it is always larger than the previous nonce. $\endgroup$
    – otus
    Commented Sep 14, 2016 at 6:35
  • 1
    $\begingroup$ You need not send full 8-byte nonce; ex if the total number of messages is less than $2^{32}$, 4-byte nonce is enough. $\endgroup$
    – kludg
    Commented Sep 14, 2016 at 6:43
  • 1
    $\begingroup$ another possible idea is to use incremental counter and send only 1 (last) byte of the counter; to get out of sync the receiver must miss 256 sequential messages. $\endgroup$
    – kludg
    Commented Sep 14, 2016 at 6:51
  • $\begingroup$ @otus I have an accurate clock at the receiver, not the transmitter, but have considered using it to do as you say. $\endgroup$
    – miket6000
    Commented Sep 14, 2016 at 8:24

1 Answer 1

Reset to default
1
$\begingroup$

If I remember correctly, ChaCha doesn't need an unpredictable IV, so a simple counter will do. (Combined with sender id if you have multiple senders using the same key.) If you had a totally lossless link, you wouldn't need to send the counter value at all.

But as some packets can be lost, you need to send at least part of the counter. The least significant 8 bits should do fine against random packet loss, just make sure to increment the next bits when overflowing the sent part, so you don't end up repeating the same 256 IV values. Even if each packet had an independent 90 % chance of being lost, the odds of losing 250 packets in a row would be less than $10^{-11}$.

Non-independent packet loss would be another thing, but with one message per minute, you'd need to lose four hours worth of packets in a row to lose synchronisation. Might happen if there's a power-out at the receiver during the night but the transmitter keeps sending.

Speaking of power-outs, your transmitters would need to have some persistent storage for the counter so that it doesn't reset in case the device loses power. A real-time clock as a counter would also do, as @otus commented.

Also note that you don't seem to have any authentication for the messages, so you're only protected against passive attackers.

Improve this answer
$\endgroup$
3
  • $\begingroup$ You're correct about the suitability of the counter as part of the IV, and combining it with the sender is both exactly what the reference implementation does and what I was planning on doing. The non-independent packet loss is what I was concerned about. I had considered a negotiation of some sort to reset the packet counter but that has its own raft of complexities, your idea of storing the counter in NVS is much cleaner. Your answer and @otus comment are the reinforcement I was looking for that I hadn't overlooked anything too obvious and was on the correct track. Thanks. $\endgroup$
    – miket6000
    Commented Sep 14, 2016 at 8:31
  • $\begingroup$ @miket6000, non-volatile storage doesn't help if the other end of the transmission loses power and can't receive, while the other end still keeps on sending and incrementing its copy of the counter. Though if you have two-way communication, you could detect the fact that replies are missing for a long time, and slow down or stop sending until you receive something again and know the other end is alive. I was mostly thinking of a dumb sensor that just sends data at even intervals, without much of a two-way interaction. $\endgroup$
    – ilkkachu
    Commented Sep 14, 2016 at 9:41
  • $\begingroup$ (Also, in general you may want to wait a while before accepting an answer, in case others will be written. Though I'm glad if the answer was useful, of course.) $\endgroup$
    – ilkkachu
    Commented Sep 14, 2016 at 9:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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