¿Por qué una contraseña incorrecta causa que "el relleno no es válido y no se puede eliminar"?

Experimenté un "Padding" similar no es válido y no se puede eliminar."excepción, pero en mi caso la clave IV y el relleno eran correctos.

Resultó que el lavado de la corriente crypto es todo lo que faltaba.

Así:

            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();

Si desea que su uso sea correcto, debe agregar authentication a su texto cifrado para que pueda verificar que es la palabra clave correcta o que el texto cifrado no se ha modificado. El relleno que está utilizando ISO10126 solo lanzará una excepción si el último byte no se descifra como uno de los 16 valores válidos para el relleno (0x01-0x10). Así que usted tiene un 1/16 de oportunidad de NO lanzar la excepción con la contraseña incorrecta, donde si autenticar una forma determinista de saber si su descifrado es válido.

El uso de crypto api aunque aparentemente fácil, en realidad es más bien fácil de cometer errores. Por ejemplo, utiliza una sal fija para su clave y derivación iv, eso significa que cada texto cifrado cifrado con la misma contraseña reutilizará su IV con esa clave, que rompe la seguridad semántica con el modo CBC, el IV debe ser impredecible y único para una clave dada.

Por esa razón de fácil cometer errores, tengo un código fragmento, que trato de mantener revisado y actualizado (comentarios, problemas bienvenidos):

Ejemplos Modernos de Cifrado Simétrico Autenticado de una cadena C#.

Si utiliza it's AESThenHMAC.AesSimpleDecryptWithPassword(ciphertext, password) cuando se utiliza la contraseña incorrecta, null se devuelve, si el texto cifrado o iv ha sido modificado post encryption null se devuelve, nunca obtendrá datos no deseados, o una excepción de relleno.

Sí, esto es de esperar, o al menos, es exactamente lo que sucede cuando nuestras rutinas criptográficas obtienen datos no descifrables

Si has descartado la falta de coincidencia de teclas, entonces además de FlushFinalBlock() (ver la respuesta de Yaniv), llamar Close() en el CryptoStream también será suficiente.

Si está limpiando recursos estrictamente con using bloques, asegúrese de anidar el bloque para el propio 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();
}

He sido mordido por esto (o similar):

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!

Otra razón de la excepción podría ser una condición de carrera entre varios subprocesos usando lógica de descifrado - las implementaciones nativas de ICryptoTransform son no thread-safe (por ejemplo, SymmetricAlgorithm), por lo que debe ser puesto a la sección exclusiva, por ejemplo, usando lock. Por favor refiérase aquí para más detalles: http://www.make-awesome.com/2011/07/system-security-cryptography-and-thread-safety /

Puede haber algunos bytes no leídos en el CryptoStream. Cerrar antes de leer la secuencia completamente estaba causando el error en mi programa.

Tuve un problema similar, el problema en el método de descifrado fue inicializar un flujo de memoria vacía. cuando funcionó cuando lo inicialicé con la matriz de bytes de texto cifrado como esta:

MemoryStream ms = new MemoryStream(cipherText)

La respuesta actualizada por el usuario "atconway" funcionó para mí.

El problema no era con el relleno, sino con la clave, que era diferente durante el cifrado y el descifrado. La clave y el iv deben ser los mismos durante la codificación y descifrado del mismo valor.