Рейтинг:1

О правильности заполнения примера RFC 5246

флаг in

Заполнение PKCS#7 определено в rfc5652 # раздел-6.3

Некоторые алгоритмы шифрования содержимого предполагают, что входная длина кратно k октетов, где k больше единицы. Для таких алгоритмы, вход должен быть дополнен в конце с помощью k-(lth mod k) октетов, все имеющие значение k-(lth mod k), где lth длина ввода. Другими словами, ввод дополняется в конец с одной из следующих строк:

               01 -- если l-й мод k = k-1
            02 02 -- если l-й мод k = k-2
                 .
                 .
                 .
       k k ... k k -- если l-й мод k = 0

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

Я видел, что они привели пример как;

Второй блок содержит оставшиеся 9 байтов HMAC и 7 байты заполнения 0x06, см. рис. 1. Обратите внимание, что шифратор также может выбрать более длинное заполнение и добавить 23, 39, ... или 247 байтов заполнения (при соответствующей установке значения байтов заполнения).

Это не дополнение PKCS#7. Итак, я посмотрел на TLS 1.2 RFC 5246 и видим почти ту же картину;

Если бы длина отступа была минимально необходимой, 6, то отступ был бы равен 6. байтов, каждый из которых содержит значение 6. Таким образом, последние 8 октетов GenericBlockCipher до блочного шифрования будет xx 06 06 06 06 06 06 06, где xx — последний октет MAC.

Чтобы быть совместимым с дополнением PKCS # 7, вышеприведенное должно быть ( не может видеть опечатки)

Если бы длина отступа была минимально необходимой, 7, отступ был бы равен 7. байтов, каждый из которых содержит значение 7. Таким образом, последние 8 октетов GenericBlockCipher до блочного шифрования будет xx 07 07 07 07 07 07 07, где xx — последний октет MAC.

и в статье тоже ошибка.

Насколько я знаю, эти два ресурса неверны. Есть ли что-то, что я пропустил в различных конструкциях/использовании правил заполнения PKCS#7?

kelalaka avatar
флаг in
Обратите внимание, что я не рассматриваю заполнение SSLv3, где последний байт обозначает количество байтов заполнения, а остальная часть заполнения может принимать любое значение.
dave_thompson_085 avatar
флаг cn
Кроссдуп https://security.stackexchange.com/questions/161153/rfc-5246-tls-1-2-padding-example-mistake и https://security.stackexchange.com/questions/88839/pkcs7-vs-tls -1-2-заполнение
Рейтинг:3
флаг cn

Заполнение, используемое для наборов шифров CBC в версиях от SSLv3 до TLS 1.2, не является дополнением PKCS#5/PKCS#7. Это заполнение, используемое в SSL/TLS, которого я больше нигде не видел.

Дополнение в TLS 1.0, TLS 1.1 и TLS 1.2 может быть от 1 до 256 байт, поэтому он может заполнять несколько блоков. В предшествующем протоколе SSL 3.0, он должен завершить ровно один блок.Во всех версиях последний байт должен быть длиной заполнения, за исключением этого последнего байта. Предыдущие байты могут принимать любое значение в SSL 3.0 и должны быть длиной заполнения в TLS 1.0–1.2. Для блочного шифра с $В$-байтовые блоки:

Спецификация Общая длина Блоки Содержание
ПККС#7 $n \in [1, B]$ байты $1$ $(n, \ldots, n)$
SSL 3.0 $n \in [1, B]$ байты $1$ $(?, \ldots, ?, (n-1))$
TLS 1.0–1.2 $n \in [1, 256]$ байты $1$ к $\lceil 256/B \rceil$ $((n-1), \ldots, (n-1))$

Как видите, PKCS#7 заполняет заполнение общей длиной заполнения, тогда как TLS 1.0–1.2 заполняет заполнение общей длиной заполнения минус единица. Причина этого, казалось бы, странного выбора заключается в том, что это адаптация заполнения SSL 3.0, в котором последний байт является байтом длины, не включающим то, что спецификация SSL называет «заполнением», а « padding» может иметь произвольное содержимое.

Примеры, которые вы цитируете из RFC 5246 и из Merget et al. верны. Если добавление 7 байт приводит к тому, что открытый текст становится кратным размеру блока, то 06 06 06 06 06 06 06 возможное заполнение TLS (как и 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16, и т.д.).

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

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