Рейтинг:1

Выходные длины AES не всегда кратны 16.

флаг ng

У меня есть решение C#, которое шифрует кучу небольших фрагментов данных с помощью AES.

        //Вот как я настраиваю объект Aes
        var aes = Aes.Create();
        aes.Mode = CipherMode.CBC;
        aes.KeySize = 256;
        aes.Padding = PaddingMode.PKCS7;

Затем я записываю необработанные байты зашифрованного текста в столбцы SQL Server VARBINARY.

Запрашивая длину этих столбцов зашифрованного текста VARBINARY, я ожидал, что они всегда будут кратны 16 байтам. Однако здесь, похоже, это не так.

Я попытался прочитать об этом в Интернете, и единственные вопросы, которые я нашел, - это вопрос, почему зашифрованный текст AES дополняется до 16-байтовых блоков, поэтому я подумал, что задам здесь обратный вопрос.

Примечания:

  • Я протестировал расшифровку одного из этих зашифрованных текстов странного размера, и он работал нормально, поэтому зашифрованный текст не искажен.
  • Я заметил, что это происходит не часто, за один прогон это произошло 19 раз из 5828.
  • Когда это происходит, оно всегда отличается от единицы (31 вместо 32, 767 вместо 768 и т. д.).

У меня возникла мысль, что, возможно, стандарт AES может обрезать байты шифрования, которые равны нулю (или какому-то другому хорошо известному числу) с конца вывода, поскольку это может быть просто восстановлено дешифратором? Но хотелось бы разъяснений.

Рейтинг:4
флаг my

Ты прав; стандартный AES-CBC (скажем, без кражи зашифрованного текста) имеет вывод, длина которого всегда кратна 16 байтам.

Одна возможность, которая приходит мне в голову, заключается в том, что если ваша реализация AES имеет сбой, если последний байт окажется равным 0x00, то он фактически не выведет его (и в направлении дешифрования, если зашифрованный текст был коротким байтом, он бы неявно добавить 0x00).

Если бы эта гипотеза была верна, то в ваших 5828 тестовых примерах мы ожидали бы, что последний байт зашифрованного текста будет равен 0 (и, следовательно, усечен) ожидаемое 22,8 раза; 19 раз в пределах стандартного отклонения, так что это правдоподобно...

Maarten Bodewes avatar
флаг in
Обратите внимание, что в этом случае у вас может быть отклонение на два раза в 65536 (поэтому, скорее всего, вы просто еще не сталкивались с этим), отклонение на 3 раза в ~ 4 миллиарда и т. д. Просто говорю, что добавление одного байта может не исправить проблема (если она нуждается в исправлении). Я также встречал много проблем с проверкой размера двоичного файла, таких как получение двоичного файла и последующая проверка размера с помощью строковой функции (например, `strlen` в C). На самом деле, я думаю, что это более вероятно, чем ошибка в процедурах шифрования/дешифрования, хотя реализации в большинстве БД также ужасны.
флаг ng
Я вытащил одно из значений, которое, по утверждению SQL Server, составляет 31 байт, но возвращаемое значение имеет длину 32 шестнадцатеричных пары, поэтому я думаю, что @MaartenBodewes прав, а SQL Server на самом деле просто неправильно сообщает длину, когда я использую функцию LEN. Что я нахожу БОЛЬШЕ интересным, так это то, что последний байт во всех них не 00, а 20, который, как я полагаю, является символом пробела ASCII? Может быть, LEN рассматривает его как строку и пытается автоматически обрезать строки? В любом случае, я думаю, это уже не криптографический вопрос. РЕДАКТИРОВАТЬ: только что узнал о функции DATALENGTH, которую я должен был использовать.
Рейтинг:0
флаг ng

Хорошо, как указывали другие, стандарт всегда будет создавать зашифрованный текст с длиной, кратной 16 байтам. Проблема заключалась в том, что когда я измерял длину, я использовал функцию T-SQL LEN, которая, кажется, обрезает 0x20 байтов с конца двоичных последовательностей при измерении длины.

Теперь я узнал, что должен использовать функцию DATALENGTH, которая не выполняет эту обрезку, и когда я пробовал, все значения кратны 16.

Приносим извинения за путаницу!

Morrolan avatar
флаг ng
Чтобы уточнить - это даже ** ожидаемое ** (хотя и своеобразное) поведение T-SQL: «LEN исключает конечные пробелы», как, например. [официальная документация](https://docs.microsoft.com/en-us/sql/t-sql/functions/len-transact-sql?view=sql-server-ver15#remarks)
флаг ng
Да, тогда это имеет больше смысла. Спасибо @Morrolan

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.