OPENSSL: В чем разница команды enc и команды cms enc?

Я обнаружил кое-что странное, проверяя внутреннюю часть конверта с данными.

У меня был простой текст "plaintextplant" - длина $15$ (включать лф(0x0A))`. Я сделал файл .ber, который зашифрован AES256 и закодирован DER через:

openssl cms -encrypt -in plain -aes256 -recip certificate.pem -outform DER -out конвертированные данные.ber

Затем я проверил зашифрованные данные через berReader. Я думал, что зашифрованные данные имеют длину 16 байт, потому что длина обычного текста $15$. Однако длина результата $32$ байт.

Итак, я набрал:

openssl enc -aes-256-cbc -in простой -out enc -k 123 , для получения зашифрованных данных.

Затем я проверил длину зашифрованных данных $16$ байт в выходных данных.

Предоставляю фото результата:

Почему размер зашифрованных данных cms 32 байта?

Плюс прилагаю картинку, что длина открытого текста 13 байт. Размер зашифрованных данных составляет 16 байт.

AES является блочным шифром и требует надлежащего режим работы как CBC, CTR, и так далее.

В то время как потоковые режимы, такие как CFB, OFB и CTR, не требуют заполнения, режимы CBC и ECB требуют заполнения.

В режиме CBC обычным дополнением является ПККС#7 обивка. При шифровании CBC сообщение делится на 128-битные блоки, а заполнение применяется к последнему блоку. Может быть два случая;

1. В сообщении пропущено несколько байтов; в этом случае пусть $n$ это количество пропущенных байтов, тогда число $n$ добавлен $n$ раз как байт.

   [Байты сообщения] [01] // 1 байт отсутствует
   [Байты сообщения] [0202] // 2 байта отсутствуют 
   [Message Bytes][030303] // Не хватает 3 байтов
   ....
   [MB][0F0F0F...0F0F0F0F] // Не хватает 15 байт
   

2. Сообщение кратно 16 байтам, это означает, что последний блок заполнен. В этом случае, чтобы отличить этот случай от первого случая, мы добавляем новый блок, полный 10с. Таким образом, мы можем иметь обратную сторону заполнения. Можно понять причину того, что, если последний блок 01 как последний байт. Это прокладка или нет? Итак, добавление 01 устраняет эту двусмысленность.

Вышеизложенное может объяснить, почему сообщение становится кратным 16 байтам после правильного шифрования CBC.

В случае вопроса 15 байтов могут стать 16 байтами, если добавить 01 как последний байт. А как насчет оставшихся 16 байт?

Для режима работы CBC требуется 16-байтовый случайный и непредсказуемый Вектор инициализации (IV) для достижения безопасности Ind-CPA.

IV является одним из требований для расшифровки первого блока кроме ключа (ключ, IV и $C_0$ требуется);

$$P_0 = \operatorname{AES-DEC}(ключ,C_0) \oplus IV$$

Поэтому IV также необходимо добавить/перенести. Обычно к зашифрованному тексту добавляется IV.

Что делать, если IV не хранится/переносится? Что ж, вы потеряете только первый блок сообщения, остальные можно правильно расшифровать, т.к.

$$P_i = \operatorname{AES-DEC}(key,C_i) \oplus C_{i-1}, \quad i \geq 1$$

CMS

CMS требует

Поле параметров AlgorithmIdentifier ДОЛЖНО присутствовать, и Поле параметров ДОЛЖНО содержать AES-IV:

  AES-IV ::= ОКТЕТНАЯ СТРОКА (РАЗМЕР (16))

IV хранится в Идентификатор алгоритма поле, а не в зашифрованный контент Как Дэйв написал это -двоичный проблема.

• Опция OpenSSL -к

  IV и ключ получаются методом получения ключа с использованием пароля пользователя и 8-байтовой случайной соли. IV не добавляется.

  OpenSSL сначала выводит волшебное слово Соленый__ затем 8-байтовая соль, затем зашифрованный текст в файл. Теперь выходной размер равен вашему магическому размеру + размер соли + размер зашифрованного текста.