Score:1

How to minimize AES output size?

us flag

I work on a project about CAN bus and I want to encrypt the data among nodes but I have have a problem because CAN bus nodes receive and send 8 bytes among each others and I know the size of AES output is exactly the same as the input. I am confused. As far as I knew, AES works in blocks of 16 bytes. My question is :

How can I reduce the output aes size to enable CAN bus nodes receiving 8 bytes correctly (the actual message coming from any node) ?

Paul Uszak avatar
cn flag
See https://dev.to/living_syn/can-bus-message-security-3h43 but ignore _"pad that data to 16 bytes for AES 128, 24 bytes for AES 192 and 32 bytes for AES 256"_.
b degnan avatar
ca flag
Here's my short write-up on cryptography on the CANbus https://crypto.stackexchange.com/questions/87751/what-encryption-mode-should-i-use-to-protect-can-bus-communication/87752#87752
Score:3
my flag

When you're working with this severely constrained environment, it's probably more involved than what you can get from listening to some strangers on stackexchange; you probably either need to follow some existing CAN bus encryption standards (written by an expert), or get a professional developer - the concerns go considerably farther than "how do I use AES"

I will go through some of the obvious issues:

  • What are the security goals? Is it so someone listening in on the CAN bus cannot read the messages? Or, is it just to ensure that any received message is from the authorized sender? For example, is it someone else on the CAN bus cannot insert their own commands, either random commands (DOS attack), selected commands, or reissuing previous valid commands? Is it so someone cannot modify commands in flight (which might be possible, if they can receive the ciphertext, somehow prevent the receiver from getting the original ciphertext, and then reissue a modified ciphertext)?

  • You state that the ciphertext must be 8 bytes - is the corresponding plaintext also 8 bytes? The problem with that is that someone could inject an 8 byte ciphertext, and it'll decrypt to some valid plaintext.

  • Using AES assumes that the sender and receiver share a secret key; is this true? How is the key shared? Is it preprovisioned at the factory or installation time? Or, is it somehow negotiated (and if so, what are the details)?

  • I assume that the sender and receiver are not guaranteed to remain "in sync"; that is, the receiver might miss a valid message from the sender. I also assume that the system needs to be 'best effort'; that is, having the system reject valid messages is intolerable (e.g. you don't want to ignore the brake pedal messages of "I've just been pressed" just because the cryptosystem just got into the wrong state). If this assumption is not true, there are some useful techniques that are possible.

Now, given the likely answers to above, my first instinct for an encryption mode would be to use a format preserving encryption, such as FF1 (which uses AES to encrypt an arbitrary length message, such as 64 bits). However, FF1 is computationally expensive (it uses about 10 AES evaluations to encrypt/decrypt a 64 bit message), and is at best only a small part of the entire solution.

Score:0
in flag

If you use AES as a stream cipher you can use CTR mode and send no more than the message size. However this won't give you message authentication and you need to make sure sender and reciever are in sync. Dealing with such extra requirements will inevitably find you sending more data than the raw message.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.