I have an 8051 microcontroller with a radio that can send packets with up to 32 bytes and I want to have the messages encrypted. It is a sensor network so I really only want to send one packet per message to have the least power usage for the battery operated nodes.

I am trying to figure out how to do something useful and secure, the microcontroller in question has AES acceleration by way of a Galois field calculator so that was my first stop, however the messages are mostly not changing much so ECB mode will expose too much by not changing many times and adding an IV will essentially limit me to 16 byte messages since I'll need 16 bytes for the IV and 16 bytes for the encrypted message.

One option I thought of an believe is insecure except that I don't know by how much is to have 16 bits of a random number and a 16 bit counter in the first 16 bytes, encrypt that as ECB and then chain the output as a bastardized CBC to the second block. This means I will be transmitting 32 bytes all the time and the IV will be faked inside the packet but the internally changing 32 bits do not sound like a good enough protection.

Another option I started to consider is a stream cipher, in this case Salsa20 which seems to have a sufficiently fast and sufficiently small implementation and it only requires 8 byte nonce and I can use it with either 256 bit (32byte) key or a 128 bit (16 byte) key. This means I only lose 8 bytes to the nonce/IV, the block number will always be zero as I never need to send more than 32 bytes out of the 64 byte stream output.

The later sounds like a better compromise overall. I will "lose" the 8 byte nonce from the packet but will probably gain a better security.

I'd appreciate any thoughts on what is preferably between the two and what may be other and better options that I didn't consider.

  • $\begingroup$ github.com/cisco/libfnr will this help ? $\endgroup$
    – sashank
    Commented Jan 6, 2015 at 7:41
  • $\begingroup$ It could be but I from a quick search I can't find any analysis of it by known cryptographers and I'm for sure not good enough to analyze it myself. As replacing the cipher later on means protocol breakage I'd rather use something others have peer reviewed. $\endgroup$ Commented Jan 6, 2015 at 19:24
  • $\begingroup$ Its based on fiestel networks which is very well studied in theory. the original paper was written some twenty years ago. ofcourse independent cryptanalysis is not yet done by anyone $\endgroup$
    – sashank
    Commented Jan 8, 2015 at 2:26

2 Answers 2


Dmitry's suggestion to use AES in counter mode sounds good to me, assuming that you only need confidentiality, and not integrity protection. (Counter mode, like most stream ciphers, is very malleable.)

One trick you can use to save a bit of space is to use the current time as part of the nonce. (Of course, this only works if your devices have fairly well synchronized clocks.) To make this scheme more robust against slight clock skew, you should transmit a few of the least significant bits of the timestamp as part of the message, so that the receiver can adjust their timestamp to match it.

For instance, let's say that your devices have clocks that are assumed to be synchronized to within one minute of each other, that they'll need to transmit at most 256 messages per second, and that there are at most 256 devices communicating with each other. Then you could use the following four-byte header for each message:

  • Byte 1: Sender ID.
  • Byte 2: Receiver ID.
  • Byte 3: Eight least-significant bits of the current time (in seconds since epoch).
  • Byte 4: An 8-bit message counter, reset whenever byte 3 changes.

This header would be transmitted in the clear, at the beginning of each message. The remaining 28 bytes can then contain data encrypted using AES-CTR (or some other stream cipher), with a 16-byte IV constructed as follows.

  • Bytes 1–8: A unique 8-byte identifier for this group of devices.
  • Bytes 9–10: Sender and receiver IDs (from header bytes 1 & 2; included to ensure that IVs are not reused between different pairs of devices).
  • Bytes 11–14: A 32-bit timestamp (seconds since epoch; byte 14 = header byte 3).
  • Byte 15: Message counter (header byte 4).
  • Byte 16: Within-message block counter (really needs just one bit for two-block messages, but using a whole byte leaves some expansion room).

For the sender, constructing this IV is straightforward. For the receiver, the only complication is that they'll need to reconstruct the sender's timestamp for bytes 11–14, by picking the nearest time that matches the 8-bit timestamp in the header. (This might be either in the past or in the future, due to clock skew.) One way to implement that is as follows:

  1. Initialize message timestamp to current time.
  2. Replace lowest 8 bits of message timestamp with byte 3 from message header.
  3. If message timestamp is more than 128 seconds in the past, increment it by 256 seconds.
  4. If message timestamp is more than 128 seconds in the future, decrement it by 256 seconds.

Optionally, if the reconstructed timestamp is off by more than 64 seconds (or so), the receiver may wish to initiate a time resynchronization protocol. Note that, with any time resynchronization scheme that potentially involves adjusting clocks backwards by a full second, either the devide ID or the group ID should be changed to prevent IV reuse.

In cases where the clock skew is only slight, it may be preferable to use a gradual adjustment scheme (i.e. telling the skewed device to count seconds a little slower or a little faster) that doesn't involve sudden time jumps. Or, alternatively, you could always have all the devices adjust their clocks foward to match the fastest-running clock (which might gradually shift them away from "true" time, but would keep them in sync without backwards time jumps). One way to handle this would be to separately track "true time" and a guaranteed monotonely increasing "message time", storing an offset between these.

Of course, you can adjust this header depending on your timing, message rate and device count needs. For example:

  • If you have good clock synchronization, you can increase the clock resolution (to, say, one millisecond) to allow a higher message rate.

  • If all your devices communicate with a single central controller (and not directly with each other), you can replace the sender and receiver IDs with a single device ID and a single direction bit indicating whether the message is to or from the controller. (Technically, you don't even need to transmit the direction bit, since the receiver will always know what it should be; but you do still need to include it in the IV.)

  • If your transmissions are very bursty, you can use more bits for the message counter, and less for the truncated timestamp. Conversely, if your messages are sent at regular intervals, you can use less bits for the message counter, or even eliminate it entirely. (Technically, you only need one or two timestamp bits, while the rest can be part of the counter; however, the higher the resolution of the message timestamps is, the easier and safer it is to recover if, say, your device suddenly loses power and forgets the current message counter value.)

The important thing is to ensure that, no matter what happens, the same IV is never used twice. Also, since CTR mode does not offer integrity protection, you should make sure to design your underlying protocol to be robust against both garbage messages, and messages that might have been deliberately modified by an attacker. For certain critical messages (like time synchronization commands, or other messages that could be used to adjust encryption or other essential operation parameters), this may require the use of a MAC at a higher protocol level.

  • $\begingroup$ I believe I read one requirement for IV is that it will be unpredictable, but it could be a CBC specific requirement and the IV as designed above won't be that unpredictable. I think I'll tend towards the stream cipher method. I'll also need to look at malleability and MACs now. $\endgroup$ Commented Jan 6, 2015 at 19:27
  • 2
    $\begingroup$ @BaruchEven: Yes, counter mode is safe even with predictable IVs, as long as they're never repeated. Generally, only CBC mode (and certain variants of CFB) requires unpredictable IVs. $\endgroup$ Commented Jan 6, 2015 at 19:36

A self-made modification to CBC is a bad idea, since your "IV" will not be random enough, whereas it must be truly random for CBC.

Stream cipher is a good idea. You may use AES in the Counter mode, or you could use Salsa20, or any other eStream portfolio cipher (software and hardware implementations are available for all of them).

Ensure that you have truly random key and satisfy all IV criteria (uniqueness or randomness), and you should be fine.


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.