Я полагаю, что заполнение всех дополненных байтов случайной ерундой, а последний байт количеством дополненных байтов было бы гораздо более безопасным. Почему этого не происходит в таком широко распространенном стандарте заполнения? Разве приведенный ниже пример не более безопасен?
53 65 63 72 65 74 20 74 65 78 74 2e --> 53 65 63 72 65 74 20 74 65 78 74 2e 5a 2c 12 04
Это в основном известно как Прокладка ISO 10126, совместим с Прокладка ANSI X9.23.
Прежде всего, следует отметить, что атаки оракула заполнения являются лишь частью более широкого набора атак оракула открытого текста.Таким образом, если расшифрованный открытый текст может вызвать какую-либо ошибку, те же проблемы могут возникнуть, когда система пытается применить открытый текст. Например, очень легко создать атака оракула открытым текстом с использованием ошибок декодера XML. Еще проще: если блоки открытого текста состоят из заполнения с левой стороны, то, очевидно, оно также не пройдет атаку оракула заполнения.
Во-вторых, зашифрованный текст теперь будет принят (т. е. не будет генерировать ошибку заполнения) 1 раз из 256/8 = 32 раза (последний байт оценивается 01 к 08) вместо примерно одного раза из 256 (последний байт оценивается 01 или конечные байты оцениваются 02 02 и т.д.). Это исключает использование заполнения для целостности/аутентичности сообщения.
В-третьих, вы смягчили атаку оракула заполнения, но не устранили ее полностью. В конце концов, последний байт все равно должен быть оценен. Мы считаем шифр взломанным, если что-либо можно узнать из исходного открытого текста.
Наконец, вы не устранили накладные расходы.
Если вы все равно берете на себя накладные расходы, вы также можете добавить тег аутентификации, созданный с использованием MAC или аутентифицированного шифра. Именно по этой причине нас не очень интересуют свойства заполнения. Мы можем использовать режим, который не требует заполнения, добавить тег аутентификации и иметь режим шифрования с лучшими свойствами безопасности, сохраняя при этом ограничение расширения сообщения.
