Ошибка «Padding is invalid and cannot be removed» появляется в приложениях на платформе .NET в момент расшифровки данных, когда криптографический модуль не может корректно снять дополняющие байты (padding) с последнего блока шифротекста. Дословный перевод сообщения — «Заполнение недопустимо и не может быть удалено». Это исключение типа CryptographicException, и оно почти всегда сигнализирует о том, что расшифровка пошла не так: ключ не совпал, данные повреждены или параметры шифрования различаются на стороне шифрования и расшифровки.
Ниже разберём, что именно означает это сообщение, в каких сценариях оно возникает чаще всего и как безопасно диагностировать причину, не ломая зашифрованные данные.
Перевод и смысл сообщения об ошибке
Фраза «Padding is invalid and cannot be removed» переводится на русский как «Дополнение (выравнивание) недопустимо и не может быть удалено». Слово padding здесь — это не «отступ» из CSS, а криптографический термин: дополнительные байты, которыми дополняется последний блок данных перед шифрованием, чтобы его длина соответствовала размеру блока алгоритма (например, 16 байт у AES).
При расшифровке библиотека снимает эти байты и проверяет их корректность. Если значения дополняющих байтов не соответствуют ожидаемой схеме (чаще всего PKCS7), .NET делает вывод, что расшифрованный «открытый текст» — мусор, и выбрасывает исключение. Иными словами, сообщение — это косвенный признак того, что расшифровка дала неверный результат, а не проблема самого padding как такового.
Типичные причины появления ошибки
Чтобы устранить проблему, нужно понять, на каком этапе произошло несоответствие. Наиболее распространённые сценарии:
- 🔑 Несовпадение ключа шифрования — для расшифровки используется ключ, отличный от того, которым данные шифровались.
- 🧊 Неверный вектор инициализации (IV) — в режиме CBC первый блок расшифровывается с использованием IV, и его несовпадение ломает результат.
- ✂️ Повреждение или обрезка шифротекста — данные усечены при передаче, сохранении в базу или конвертации в строку.
- 🔁 Двойное кодирование Base64 или, наоборот, попытка расшифровать строку Base64 без предварительного декодирования в байты.
- ⚙️ Разные параметры алгоритма — отличается режим (CBC/ECB), схема padding или размер ключа на двух сторонах.
Отдельный частый случай — веб-приложения на ASP.NET, где ошибка возникает при расшифровке cookie аутентификации, ViewState или данных, защищённых через Data Protection API. Там причиной обычно становится смена или рассинхронизация ключей machineKey между серверами фермы или после переразвёртывания приложения.
Как диагностировать причину: пошаговая проверка
Начинайте с обратимых проверок, которые не меняют ни код, ни данные. Сначала убедитесь, что шифротекст доходит до расшифровщика в неизменном виде: сравните длину исходного массива байт до передачи и после. Если данные хранятся в базе в виде строки, проверьте, не обрезает ли поле значение и не меняет ли кодировку.
Далее сверьте параметры на обеих сторонах. В коде шифрования и расшифровки должны совпадать Key, IV, Mode и Padding. Минимальный тест — зашифровать и тут же расшифровать короткую строку в одном процессе: если это работает, проблема в передаче или хранении данных, а не в самом алгоритме.
☑️ Диагностика ошибки padding
⚠️ Внимание: не пытайтесь «подавить» исключение пустым блоком
catchили сменой padding наPaddingMode.Noneради того, чтобы ошибка исчезла. Это скроет симптом, но расшифрованные данные останутся некорректными, а в худшем случае вы ослабите защиту.
Типичный код, вызывающий ошибку, и его исправление
Классический проблемный паттерн — генерация нового случайного IV при каждом запуске шифрования без сохранения его вместе с шифротекстом. При расшифровке используется другой IV, и последний блок (или первый, в зависимости от ситуации) превращается в мусор.
// Неправильно: IV генерируется заново и теряется
using (Aes aes = Aes.Create())
{
aes.Key = key;
// aes.GenerateIV() вызван, но IV никуда не сохранён
...
}
Правильный подход — сохранять IV вместе с шифротекстом (IV не является секретом) и извлекать его перед расшифровкой:
// Сохраняем IV в начало массива, при расшифровке читаем первые 16 байт
byte[] iv = aes.IV;
// шифротекст = iv + encryptedData
Ещё одна частая ошибка — работа со строками. Шифротекст нельзя хранить как обычную строку через Encoding.UTF8.GetString: произвольные байты необратимо искажаются. Используйте Convert.ToBase64String для сохранения и Convert.FromBase64String перед расшифровкой — строго по одному разу.
Ошибка в ASP.NET: cookie, ViewState и machineKey
В веб-приложениях сообщение часто всплывает в логах как System.Security.Cryptography.CryptographicException при обработке запросов. Типовой сценарий: приложение работает на нескольких серверах (или контейнерах), а ключи защиты на них различаются. Пользователь получает cookie, зашифрованный одним сервером, а следующий запрос попадает на другой — и расшифровка падает с ошибкой padding.
Проверьте, совпадает ли конфигурация machineKey в web.config на всех узлах, если вы используете классический ASP.NET. Для ASP.NET Core убедитесь, что ключи Data Protection хранятся в общем доступном месте для всех экземпляров приложения. Точные настройки зависят от версии фреймворка и способа развёртывания, поэтому сверяйтесь с официальной документацией Microsoft под вашу конфигурацию.
Сравнение причин и способов устранения
| Причина | Как распознать | Способ устранения |
|---|---|---|
| Неверный ключ | Ошибка стабильна на всех данных | Использовать тот же ключ, что при шифровании |
| Неверный IV | Ошибка после перезапуска/передачи | Хранить IV вместе с шифротекстом |
| Повреждённые данные | Длина массива отличается от исходной | Проверить канал передачи и хранение |
| Ошибка Base64 | Исключение FormatException рядом | Ровно одно кодирование/декодирование |
| Разные ключи серверов | Ошибка плавающая, у части запросов | Синхронизировать machineKey / Data Protection |
⚠️ Внимание: если зашифрованные данные были созданы с ключом, который уже утерян, восстановить их невозможно — это свойство стойкого шифрования, а не неисправность. Ошибка padding в таком случае лишь подтверждает, что ключ не подходит.
Когда ошибка возникает в сторонних приложениях
Иногда пользователь видит это сообщение не в своём коде, а в готовой программе — например, в клиенте базы данных, средстве резервного копирования или приложении, хранящем зашифрованные настройки. Здесь возможные причины иные: повреждённый файл конфигурации, смена учётной записи Windows (если шифрование привязано к пользователю через DPAPI) или перенос данных на другой компьютер.
Безопасная последовательность действий: сделайте резервную копию конфигурационных файлов программы, проверьте, под той ли учётной записью вы работаете, и изучите документацию конкретного приложения на предмет восстановления доступа к зашифрованным данным. Удалять или перезаписывать зашифрованные файлы стоит только после того, как вы убедились, что данные в них не нужны или есть копия.
Почему нельзя просто отключить проверку padding
Схема PKCS7 позволяет расшифровщику убедиться, что данные расшифрованы правильно. Отключение проверки (PaddingMode.None) заставит приложение принимать мусорные данные как валидные, что приведёт к ошибкам логики дальше по коду и потенциальным уязвимостям. Корректное решение — устранить несоответствие ключей, IV или данных.
Часто задаваемые вопросы
Как переводится «Padding is invalid and cannot be removed»?
Дословно: «Дополнение (выравнивание) недопустимо и не может быть удалено». По смыслу это означает, что при расшифровке получены некорректные данные и криптографический модуль не может снять служебные байты с последнего блока.
Ошибка появляется только иногда, у части пользователей. Почему?
Наиболее вероятная причина — несколько серверов или процессов с разными ключами шифрования. Запросы, попадающие на «чужой» сервер, завершаются ошибкой. Проверьте синхронизацию ключей на всех узлах.
Поможет ли смена PaddingMode на Zeros или None?
Нет, это лишь маскирует проблему. Если ключ или данные не совпадают, расшифрованный результат всё равно будет некорректным, просто без исключения. Нужно найти и устранить первопричину.
Можно ли расшифровать данные, если ключ утерян?
Нет. Стойкие алгоритмы вроде AES спроектированы так, чтобы без правильного ключа восстановление было невозможно. Остаётся только восстановить данные из резервной копии или источника.
Ошибка возникла после обновления приложения. Что проверить?
Сравните криптографические настройки старой и новой версий: алгоритм, режим, padding, способ формирования ключа и IV. Также проверьте, не изменилось ли расположение ключей Data Protection или значение machineKey.