Блог

У меня есть приложение, в котором я должен передать зашифрованный пакет через BLE advertisement, длина которого составляет 14 байт. Алгоритм AES ограничивает данные длиной не менее 16 байт, а DES требует, чтобы они были кратны 8 байтам. У меня нечетная длина в 14 байт, которую я не могу изменить. Существует ли какой-либо алгоритм шифрования, который можно использовать для шифрования этих 14-байтовых данных. Также было бы хорошо, если бы кто-нибудь мог указать на какую-либо реализацию алгоритма на основе C?

Предполагая, что вы имеете в виду, что длина открытого текста и зашифрованного текста составляет ровно 14 байт:

Используйте AES в режиме CTR. Это дает одинаковые 16-байтовые фрагменты данных с каждой стороны. Вы можете использовать 14 из 16 байт в качестве ключа XOR и отбросить последние два.

Инициализация IV выполняется с помощью 14 байтов IV и двух байтов нулей.

Однако здесь есть одна загвоздка. Базовый протокол является трансляцией без сохранения состояния. Единственный способ получить IV — это использовать уникальный идентификатор пакета, которого может и не быть. Без примерно 10 дополнительных байтов мне было бы очень сложно создать уникальный генератор IV.

Вы можете использовать кражу зашифрованного текста на основе ECB (CTS) с блочным шифром, размер блока которого меньше 14 байт. Я не буду вдаваться в подробности, как работает CTS, потому что статья в Википедии делает довольно хорошую работу.

Если вы слышали, что ECB плохой, то вы правы. К сожалению, для любого другого режима требуется какой-то IV, который уничтожит ваше ограничение полезной нагрузки. Поскольку CTS перемещает часть зашифрованного текста в последний блок открытого текста, плохое свойство ECB исчезает.

Блочные шифры с небольшими размерами блоков, такие как 64-разрядные, имеют худшие свойства безопасности, чем, скажем, блочные шифры со 128-битными блоками. Просто посмотрите на атаку Sweet32. В вашем случае я бы предположил, что на самом деле это не проблема, поскольку злоумышленник не может заставить вас генерировать много зашифрованных трансляций, и если бы они попытались, это заняло бы у них действительно много времени.

Популярным блочным шифром с размером блока 64 бита является DES. Возможно, вы слышали, что DES легко поддается грубой обработке из-за небольшого размера ключа, и вы были бы правы. На помощь приходит Triple-DES (EEE или EDE), который имеет размер ключа в три раза больше и обладает гораздо лучшей защитой от атак методом перебора.

К сожалению, вы не можете использовать AES, потому что для работы CTS требуется как минимум два блока, а один блок AES уже нарушает ваше ограничение по размеру.

Оба AES и DES являются алгоритмами блочного шифрования, поэтому вы правы в том, что они имеют минимальные размеры для блоков, которые они могут обрабатывать. НО существует много различных способов использования блочного шифрования, некоторые из которых могут обрабатывать потоки данных произвольной длины. Проверьте «s-битный режим обратной связи с шифрованием», где s — это размер фактических блоков, которые шифруются по отдельности. Здесь вы могли бы использовать s= 2.

Почему бы не создать ваши данные так, чтобы они отображали:

1. заголовок
2. полезная нагрузка
3. заполнение

Заголовок будет содержать длину данных, плюс, возможно, «волшебный» код для проверки синхронизации. Полезная нагрузка — это ваши данные. Затем заполнение представляет собой блок нулей (или случайных чисел, если вы того пожелаете), чтобы соответствовать необходимому кратному blockside для блочного шифрования.

Предполагая, что вы хотите передать в тех же 14 байтах, вы немного застряли. Приведенные выше предложения означают, что вам нужно будет передать 16 байт (или даже больше), а затем игнорировать последние 2 байта.

Насколько безопасными должны быть данные? Одним из ответов может быть использование DES для шифрования всех полных блоков (один блок из 8 байт в вашем случае), затем используйте что-то более слабое для кодирования оставшихся (6 в вашем случае) байтов. Достаточно безопасным способом было бы просто преобразовать предыдущие 6-байтовые декодированные байтовые значения поверх оставшихся 6 байт конечных данных. До тех пор, пока защищенные DES данные не будут декодированы, значение xor не может быть определено.

Конечно, если часть DES состояла из нулей, то ваши конечные коды будут видны. Если это редкое явление, это может не быть проблемой, поскольку хакер не знает, что данные DES являются нулями. У вас не так много данных, поэтому трудно придумать гораздо больше того, что вы могли бы сделать.

В общем, вы могли бы сгенерировать 64-битную (8-байтовую) контрольную сумму из предыдущего 1 КБ исходных данных и использовать это как xor. В общем случае у вас будет число, меньшее 8 байт конечных данных, которые вы бы xor, и передаете только количество байтов. При декодировании оставшиеся байты игнорируются.