Почему из-за неверного пароля "Заполнение недействительно и не может быть удалено"?

Да, этого следовало ожидать, или, по крайней мере, это именно то, что происходит, когда наши криптографические подпрограммы получают данные, не поддающиеся расшифровке.

Хотя на этот вопрос уже был дан ответ, я думаю, что было бы неплохо объяснить Почему, этого следовало ожидать.

Схема заполнения обычно применяется, потому что большинство криптографических фильтров не являются семантически безопасными и предотвращают некоторые формы криптоатак. Например, обычно в RSA используется схема заполнения OAEP, которая предотвращает некоторые виды атак (например, атаку по выбранному открытому тексту или ослепляющий).

Схема заполнения добавляет некоторый (обычно) случайный мусор к сообщению m перед отправкой сообщения. В методе OAEP, например, используются два оракула (это упрощенное объяснение):

1. Учитывая размер модуля, вы дополняете k1 битами 0 и k0 битами со случайным числом.
2. Затем, применив некоторое преобразование к сообщению, вы получите сообщение с дополнениями, которое зашифровывается и отправляется.

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

В CryptoStream могут быть непрочитанные байты. Закрытие перед полным чтением потока вызывало ошибку в моей программе.

Если вы хотите, чтобы ваше использование было правильным, вы должны добавить аутентификация в свой зашифрованный текст, чтобы вы могли убедиться, что это правильный пароль или что зашифрованный текст не был изменен. Заполнение, которое вы используете ISO10126, вызовет исключение только в том случае, если последний байт не расшифровывается как одно из 16 допустимых значений для заполнения (0x01-0x10). Таким образом, у вас есть 1/16 шанс, что он НЕ выдаст исключение с неправильным паролем, где, если вы аутентифицируете его, у вас есть детерминированный способ узнать, действительна ли ваша дешифровка.

Хотя использование крипто-API кажется простым, на самом деле довольно легко сделать ошибку. Например, вы используете фиксированную соль для получения ключа и iv, это означает, что каждый зашифрованный текст, зашифрованный одним и тем же паролем, будет повторно использовать его IV с этим ключом, что нарушает семантическую безопасность в режиме CBC, IV должен быть как непредсказуемым, так и уникальным для данный ключ.

По этой причине, чтобы легко сделать ошибки, у меня есть фрагмент кода, который я стараюсь обновлять и обновлять (комментарии, проблемы приветствуются):

Современные примеры симметричного аутентифицированного шифрования строки C#.

Если вы используете его AESThenHMAC.AesSimpleDecryptWithPassword(ciphertext, password), когда используется неправильный пароль, возвращается null, если зашифрованный текст или iv был изменен после шифрования, возвращается null, вы никогда не получите обратно ненужные данные или исключение заполнения.

У меня возникла похожая ошибка «Заполнение недействительно и не может быть удалено». исключение, но в моем случае ключ IV и отступы были правильными.

Оказалось, что промывки криптопотока - это все, чего не хватало.

Так:

            MemoryStream msr3 = new MemoryStream();
            CryptoStream encStream = new CryptoStream(msr3, RijndaelAlg.CreateEncryptor(), CryptoStreamMode.Write);
            encStream.Write(bar2, 0, bar2.Length);
            // unless we flush the stream we would get "Padding is invalid and cannot be removed." exception when decoding
            encStream.FlushFinalBlock();
            byte[] bar3 = msr3.ToArray();

У меня была аналогичная проблема, проблема в методе дешифрования заключалась в инициализации пустого потока памяти. когда он работал, когда я инициализировал его массивом байтов зашифрованного текста следующим образом:

MemoryStream ms = new MemoryStream(cipherText)

У меня сработал ответ, обновленный пользователем "atconway".

Проблема заключалась не в заполнении, а в том, что ключ был другим во время шифрования и дешифрования. Ключ и iv должны быть одинаковыми во время шифрования и дешифрования одного и того же значения.

Другой причиной исключения может быть состояние гонки между несколькими потоками с использованием логики дешифрования - собственные реализации ICryptoTransform - это не потокобезопасный (например, SymmetricAlgorithm), поэтому его следует поместить в эксклюзивный раздел, например используя замок. Пожалуйста, обратитесь сюда для получения более подробной информации: http://www.make-awesome.com/2011/07/system-security-cryptography-and-thread-safety/

Если вы исключили несоответствие клавиш, то, помимо FlushFinalBlock() (см. Ответ Янива), будет достаточно вызова Close() на CryptoStream.

Если вы очищаете ресурсы строго с помощью блоков using, обязательно вложите блок для самого CryptoStream:

using (MemoryStream ms = new MemoryStream())
using (var enc = RijndaelAlg.CreateEncryptor())
{
  using (CryptoStream encStream = new CryptoStream(ms, enc, CryptoStreamMode.Write))
  {
    encStream.Write(bar2, 0, bar2.Length);
  } // implicit close
  byte[] encArray = ms.ToArray();
}

Меня укусило это (или подобное):

using (MemoryStream ms = new MemoryStream())
using (var enc = RijndaelAlg.CreateEncryptor())
using (CryptoStream encStream = new CryptoStream(ms, enc, CryptoStreamMode.Write))
{
  encStream.Write(bar2, 0, bar2.Length);
  byte[] encArray = ms.ToArray();
} // implicit close -- too late!