Skip to main content
added 44 characters in body
Source Link
ilkkachu
  • 913
  • 6
  • 13

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 itthe 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.

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.

Speaking of power-outs, your transmitters would need to have some persistent storage for the counter so that it doesn't reset in case it 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.

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.

Source Link
ilkkachu
  • 913
  • 6
  • 13

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.

Speaking of power-outs, your transmitters would need to have some persistent storage for the counter so that it doesn't reset in case it 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.