Как минимизировать размер вывода AES?

Я работаю над проектом о шине CAN и хочу зашифровать данные между узлами, но у меня есть проблема, потому что узлы шины CAN получают и отправляют 8 байтов между собой, и я знаю, что размер вывода AES точно такой же, как и ввод . Я сбит с толку.Насколько я знал, AES работает блоками по 16 байт. Мой вопрос:

Как я могу уменьшить размер выходного aes, чтобы узлы шины CAN правильно получали 8 байтов (фактическое сообщение, поступающее от любого узла)?

Когда вы работаете с этой жестко ограниченной средой, это, вероятно, более сложно, чем то, что вы можете получить, слушая некоторых незнакомцев на stackexchange; вам, вероятно, нужно либо следовать некоторым существующим стандартам шифрования шины CAN (написанным экспертом), либо нанять профессионального разработчика - проблемы идут значительно дальше, чем «как мне использовать AES»

Я рассмотрю некоторые из очевидных вопросов:

• Каковы цели безопасности? Значит ли это, что кто-то, кто прослушивает CAN-шину, не может прочитать сообщения? Или это просто для того, чтобы убедиться, что любое полученное сообщение исходит от авторизованного отправителя? Например, кто-то еще на шине CAN не может вставить свои собственные команды, будь то случайные команды (DOS-атака), выбранные команды или повторная подача предыдущих действительных команд? Значит ли это, что кто-то не может изменять команды во время полета (что возможно, если они могут получить зашифрованный текст, каким-то образом помешать получателю получить исходный зашифрованный текст, а затем повторно выдать измененный зашифрованный текст)?

• Вы утверждаете, что зашифрованный текст должен быть 8 байтов - соответствующий открытый текст также 8 байтов? Проблема в том, что кто-то может ввести 8-байтовый зашифрованный текст, и он расшифрует какой-нибудь действительный открытый текст.

• Использование AES предполагает, что отправитель и получатель имеют общий секретный ключ; Это правда? Как делится ключ? Это предусмотрено на заводе или во время установки? Или это как-то согласовывается (и если да, то каковы подробности)?

• Я предполагаю, что отправитель и получатель не гарантированно останутся «синхронизированными»; то есть получатель может пропустить действительное сообщение от отправителя. Я также предполагаю, что система должна работать «по максимуму»; то есть отказ системы от действительных сообщений недопустим (например, вы не хотите игнорировать сообщения педали тормоза «Меня только что нажали» только потому, что криптосистема только что перешла в неправильное состояние). Если это предположение неверно, есть несколько полезных методов, которые возможны.

Теперь, учитывая вероятные ответы на приведенные выше ответы, моим первым побуждением для режима шифрования было бы использовать шифрование с сохранением формата, такое как FF1 (который использует AES для шифрования сообщения произвольной длины, такого как 64 бита). Однако FF1 требует больших вычислительных ресурсов (оно использует около 10 вычислений AES для шифрования/дешифрования 64-битного сообщения) и в лучшем случае является лишь небольшой частью всего решения.

Если вы используете AES в качестве потокового шифра, вы можете использовать режим CTR и отправлять не больше, чем размер сообщения. Однако это не обеспечит аутентификацию сообщения, и вам необходимо убедиться, что отправитель и получатель синхронизированы. Работа с такими дополнительными требованиями неизбежно обнаружит, что вы отправляете больше данных, чем необработанное сообщение.